Contractor and Third-Party Access and Classification Enforcement Failures

Contractor access failures and data classification failures look like separate problems on an org chart, but they come from one structural defect: enterprise controls verify a credential at the door and then impose almost no constraint on what that credential does once it's inside. Access control checks whether a persona is authenticated. Classification control checks whether a piece of content matches a static sensitivity rule. Neither one checks what an authenticated person is actually doing with the data in front of them, over time, in context.

A contractor who holds broader access than their role requires, and whose data interactions are governed only by fixed content rules, sits in a detection blind spot that neither control was built to close on its own. The access system assumes that once a credential clears onboarding, its holder can be trusted to act within scope. The classification system assumes that sensitive data carries a label that will trip an alarm no matter how it moves. Both assumptions fail for the same reason: they are fixed at a point in time, while contractor behavior keeps changing after that point.

The Cyber Strategy Institute's 2026 Insider Threat Report gives this failure a name. Increasingly, "insider" describes outsiders operating through insider identities: compromised workers, fraudulent hires, and infostealer victims, not malicious employees caught by behavioral monitoring. That shift in who the "insider" actually is matters because it means the controls built to catch a disgruntled employee are being asked to catch something structurally different: a credential that was never supposed to belong to the person using it, or a legitimate credential being used for purposes its holder was never screened for.

Practitioners who treat access failures and classification failures as two separate tickets, owned by two separate teams, running on two separate tools, will keep missing the cases that live in the space between them. The rest of this piece treats them as one architectural gap, because that is the only framing the evidence supports.

Trust in the identity as the default access model for third parties

Enterprise identity infrastructure was built for employees, and it shows. Single sign-on, VPN access, and multi-factor authentication onboarding all answer one question: is this credential valid? None of them answer a second, more important question: does the behavior of the person using this credential match what they should be doing with their role, right now? Once a credential clears the door, the infrastructure that let it in has almost nothing left to say about what happens next.

Contractor onboarding takes this employee-shaped model and applies it to a population it was never designed for. Contractors typically have shorter tenures than employees, narrower legitimate reasons to touch most of what they can technically reach, weaker background verification at the point of hire, and access that sprawls across multiple SaaS platforms and cloud accounts, often with no single team holding a complete picture of what any given contractor can actually do. The mismatch between the control and the population it governs is the default state, not an oversight corrected over time.

That mismatch produces entitlement sprawl as a structural outcome rather than an accident. Access gets granted project by project, across a productivity suite, cloud consoles, and SaaS admin panels, and it rarely gets trimmed when a project ends or a contractor's scope narrows. Roles accumulate because granting access is a one-time event tied to a request, while revoking it requires someone to notice that the original reason no longer applies. Few organizations have a process built to notice that.

The Cyber Strategy Institute's 2026 Insider Threat Report states the mechanism directly: controls around identity proofing, contractor onboarding, and cloud and SaaS entitlements lagged badly in 2025, and once a persona was trusted, runtime constraints on its actions were weak or absent. Offboarding is where this becomes hardest to ignore. Third-party credentials routinely stay active long after a contract ends, and you get far less scrutiny on these accounts than on employee accounts, because the monitoring infrastructure assumes someone is tracking contractor lifecycle events closely enough to catch the gap. That assumption rarely holds.

Three execution paths that exploit the authenticated-but-unconstrained gap

Adversaries do not need to break enterprise identity systems. They use those systems exactly as designed, because the design itself is the opening. Three execution paths account for most of the recent incidents that fit this pattern.

The first is infostealer-to-SaaS. If an attacker steals a session cookie, they can skip multi-factor authentication, because the session is already authenticated. The attacker walks into a cloud console holding a valid session and, from that point forward, operates as the trusted persona with no further challenge from any system in the stack.

The second is the fraudulent hire. If someone fakes a hire with fabricated or stolen identity documents, background verification was never built to catch a determined, well-resourced effort like that. The organization then issues real credentials to someone who was never who they claimed to be, and that person begins work with full authorized access to code repositories, CI/CD pipelines, or production-adjacent SaaS systems, exactly as any legitimate new hire would.

The third is helpdesk social engineering. Support staff get talked into resetting multi-factor authentication or passwords for high-value accounts, and that single social engineering event converts directly into a fully authenticated session. No malware touches the environment at any point.

What links all three paths is a living-off-the-land character. Each one relies on legitimate credentials, native admin consoles, and workflows the organization authorized. The telemetry these actions generate looks like ordinary contractor activity to any control that inspects the action without understanding the person performing it. That is the gap the next section tests against named incidents.

Where controls broke down in recent cases

The incidents below are not isolated misconfigurations. Each one shows a variation of the same failure: controls that worked exactly as designed right up to the moment a credential was issued or stolen, and then had nothing left to say about what that credential did next.

The DPRK fraudulent contractor campaign, running from 2018 to the present, is the clearest illustration of the fraudulent-hire path operating at scale. Federal case reporting states that the defendants' schemes impacted more than 136 U.S. victim companies, generated more than $2.2 million in revenue for the DPRK regime, and compromised the identities of more than 18 U.S. persons. Workers inside these schemes copied source code repositories to personal accounts, and they harvested credentials and session cookies for later use. FBI documentation shows operatives who had already secured employment then threatened to release sensitive company data unless paid more, so a hiring fraud turned into ongoing extortion. During a tracking operation run by Nisos, one cell applied for positions at massive scale and landed only a small fraction of them, a ratio that, as reported by Dark Reading, shows the industrial scale at which this identity-layer exploitation operates. The failure point sits entirely at the credential boundary: every control worked as designed up through the moment of hire, and nothing in the stack was built to constrain what those credentials could do once issued.

In May 2025, Coinbase showed that the same gap can hit customer data, not just source code. Contractor accounts held access to customer data, but there was no runtime constraint on bulk data interaction and no behavioral signal to distinguish legitimate support activity from staged exfiltration. The access was authorized; the volume and pattern of its use went unevaluated.

The Salesloft and Drift supply-chain breach, in August 2025, moved the same failure into the OAuth layer. The threat actor UNC6395 used stolen OAuth tokens to access Salesforce environments connected to Drift between August 8 and August 18, exporting large volumes of corporate data from a large number of organizations. Mandiant's investigation found that the attackers had already accessed Salesloft's GitHub account between March and June 2025, downloading repository content and conducting reconnaissance before pivoting into Drift's AWS environment. The control boundary in this case was the OAuth token itself. Once that token was stolen, nothing constrained what it could export.

Bright Defense's breach tracker traced Adobe's 2026 breach through a business process outsourcing vendor to an Indian BPO vendor, where a phishing email delivered a remote access tool to a contractor machine, with access then expanding through a manager account. Lateral movement conducted through the contractor's own authenticated session caused the failure, and no behavioral signal could distinguish the compromised manager account from its ordinary, legitimate use pattern.

The UK Ministry of Defence's exposure through Dodd Group, a property maintenance and mechanical and electrical services contractor, followed a different mechanism, but the architecture was the same. Bright Defense reports that a ransomware attack on Dodd Group gave an unauthorized third party temporary access to part of its internal systems, and that earlier in 2025, a separate subcontractor had already exposed the personal data of Afghans evacuated to the UK. The contractor's network perimeter had been treated as an extension of the MoD's own trust boundary, without independent runtime controls governing what could be accessed or moved from that perimeter.

Ericsson's third-party breach, disclosed in April 2025, shows what this gap costs in time rather than scale. Ericsson's U.S. subsidiary traced the breach to unauthorized access at a third-party service provider, and Ncontracts reports it took nearly a year to finish the investigation, with thousands of individuals' personal information potentially exposed. The third-party provider sat inside the trust boundary from the start, and the length of the investigation shows how the absence of runtime telemetry from contractor environments extends dwell time well past what any perimeter-focused model accounts for.

Static classification policies and the failure to track contractor data movement

Static classification assumes that data carries a fixed sensitivity label wherever it goes. Contractor workflows do not respect that assumption. The same file, query result, or API response can pass through a personal GenAI prompt, a personal cloud drive, a screenshot, or an email chain without ever triggering a label-based rule, because none of those paths involve the labeled file moving in a way the rule was built to detect.

A contractor who pastes proprietary source code into a GenAI prompt triggers no file-movement rule, no policy violation, and no alert. The organization's intellectual property has left the building in that moment, but the classification system has no record of the event, because no labeled file moved in any sense the system was built to watch for. This is the same structural failure described in the access section, applied to content instead of credentials: a control built around a fixed definition of what to watch, failing against behavior that was never going to match that definition.

Fortinet's 2025 Insider Risk Report found that nearly three-quarters of security professionals lack visibility into how users interact with sensitive data across endpoints, cloud apps, and GenAI platforms, with only a minority reporting effective data discovery and classification in place. That finding confirms the visibility gap is standard across the industry, not an exception found at poorly resourced organizations. GenAI adoption makes the gap worse by giving contractors a channel classification tools were never built to inspect: a survey cited in that research found that a majority of employees use personal GenAI accounts for work, with a significant share admitting to entering sensitive information into unapproved tools.

The classification gap and the access gap are the same failure described from two different angles. Both assume the control boundary can be defined in advance and held fixed. Actual contractor data movement, like actual contractor access behavior, is shaped by context that changes constantly, and no boundary fixed at one point in time stays accurate for long.

Why Legacy DLP Makes Both Gaps Worse

Legacy data loss prevention tools were built as perimeter controls. They see a data action and check it against a static rule, but they cannot see the user behind the action, the origin of the file, who actually owns the account performing the action, or the broader behavioral pattern the action belongs to. That blindness is tolerable when the population being monitored is stable and well understood. It is not tolerable against a contractor population defined by short tenure, broad access, and workflows that move across platforms the tool was never built to watch.

The limitation is acute precisely where contractors are concerned, because a static rule cannot distinguish between a contractor legitimately downloading a project file and that same contractor staging an exfiltration. Both actions look identical to a rule built to inspect content without any sense of the context surrounding it. Spin.ai's analysis of AI-native DLP found that legacy regex-based detection achieves only a fraction of the detection accuracy that context-aware approaches reach, a gap rooted in how the two approaches are built rather than in how well either one is tuned.

The operational cost of that gap lands on the analyst team. Instead of investigating actual exfiltration events, analysts spend the day bulk-closing tickets generated by business-as-usual activity, a pattern described in analysis of the broader DLP market shift as turning the security operations center into a ticket factory. Fortinet's 2025 Insider Risk Report found that fewer than half of security professionals strongly agree their existing DLP tools are effective at keeping sensitive data from leaving the organization, and that those tools lack the visibility to explain who is behind a risky data event and why it happened.

The false-positive burden this creates does more than waste analyst hours. It trains security teams to treat contractor-generated alerts as noise. When a genuine exfiltration event does occur through a contractor account, it is most likely to land in front of an analyst who has already learned, ticket after ticket, that alerts tied to contractors rarely mean anything. The tool built to catch the exfiltration has conditioned the person watching it to dismiss the signal.

Runtime constraint and behavioral context in practice

Closing the access gap requires runtime constraint, not better onboarding alone. The assumption that an authenticated persona is a safe persona has to give way to ongoing evaluation of what that persona is doing, measured against what someone in that role, at that tenure, with that prior behavior, should reasonably be doing.

Closing the classification gap requires understanding data by its meaning and context rather than by a label alone. A contractor query that exports a customer list from a SaaS admin panel has to be identifiable as sensitive even when no classification label was ever applied to the underlying records, because the records themselves were never going to carry a label that survives being queried out of their original system.

Both requirements point toward the same architectural answer: a platform that holds the data signal and the person signal in a single decision, rather than splitting them across separate, unconnected tools. Content, destination, identity, role, account ownership, and the surrounding behavioral pattern all need to be evaluated together, because any one of them alone tells an incomplete story. A credential without behavioral context cannot distinguish a legitimate contractor from a fraudulent hire using real access. Content without identity context cannot distinguish a routine file transfer from a staged exfiltration. Only a decision that weighs both together, continuously, catches the cases where access failure and classification failure were always the same event wearing two names.