Contractor fraud is abuse of third-party access when a legitimate contractor shares credentials, outsources work, or lets another person log in on their behalf. The core issue is identity mismatch. Systems think they are serving one approved worker, while the actual user may be an unvetted subcontractor or impersonator.
Expanded Definition
Contractor fraud is a third-party access failure in which a legitimate contractor account is used by someone other than the approved worker. The risk is not just unauthorized sharing, but identity mismatch: the organisation believes it is interacting with one vetted individual while the session is actually controlled by an unvetted proxy. In NHI security, that makes contractor access a governance problem as much as an authentication problem, because the identity proof at login no longer matches the person performing the work.
Definitions vary across vendors when contractor fraud is grouped with credential sharing, subcontractor abuse, or business process fraud, but the operational concern is the same. Access should be tied to the specific human performing the task, not merely to a contractor company or email address. Controls commonly discussed in NIST SP 800-53 Rev 5 Security and Privacy Controls become relevant here because third-party access must be accountable, bounded, and reviewable across the full lifecycle.
The most common misapplication is treating a contractor account as safe because the login belongs to a known vendor, which occurs when organisations verify the company relationship but do not verify who is actually using the session.
Examples and Use Cases
Implementing contractor controls rigorously often introduces friction for external teams, requiring organisations to weigh speed of delivery against stronger identity assurance and session accountability.
- A contractor is hired for a short migration project and shares a password with a colleague after hours so the work can continue. The account remains approved, but the actual operator is no longer the vetted individual.
- A vendor assigns work to an offshore subcontractor who signs into the customer environment using the original contractor’s MFA-backed session. The customer sees a valid login, not the substitution behind it.
- Access is granted for a support engagement, but the contractor later uses the same account for unrelated administrative tasks, creating a mismatch between approved scope and actual behaviour.
- An organisation with strong onboarding but weak offboarding leaves contractor credentials active after the engagement ends, so the account is reused by a replacement worker without fresh review. The Ultimate Guide to NHIs shows how persistent credentials and poor revocation discipline create lasting exposure.
- Session logging shows a legitimate contractor identity, but device location, working hours, and action patterns suggest a different operator. This is where behavioural evidence and identity governance need to be correlated, not treated separately.
For third-party identity governance, the core lesson mirrors access control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls: approvals are only meaningful if the approved identity remains the one actually exercising the privilege.
Why It Matters in NHI Security
Contractor fraud matters because it turns legitimate third-party access into an invisible privilege escalation path. Once a contractor account is shared, the organisation loses assurance over who is making changes, reading sensitive data, or approving transactions. That weakens auditability, incident response, and segregation of duties, especially where contractors touch systems that also rely on secrets, tokens, certificates, or service accounts. The NHI problem is often broader than human access alone: Ultimate Guide to NHIs reports that 92% of organisations expose NHIs to third parties, raising supply chain risk, and that 79% have experienced secrets leaks, with 77% causing tangible damage.
When contractor fraud is misunderstood, teams may focus on password strength while ignoring credential sharing, unmanaged subcontractors, and weak offboarding. That creates blind spots in access reviews and breaks the trust model behind least privilege. NIST-style control environments expect accountable identities, while modern third-party operations often rely on temporary access that is not continuously revalidated. Organisations typically encounter the consequences only after an audit failure, data exposure, or unexplained production change, at which point contractor fraud becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Contractor fraud is an identity assurance failure tied to shared access and impersonation. |
| NIST CSF 2.0 | PR.AC-1 | Third-party access must be managed so identities are authorized, traceable, and revocable. |
| NIST SP 800-63 | IAL2 | Identity proofing strength matters when contractor access must be tied to a real person. |
| NIST Zero Trust (SP 800-207) | SP 3 | Zero Trust requires continuous verification rather than trusting a one-time contractor login. |
| OWASP Agentic AI Top 10 | A-02 | Human proxy abuse parallels delegated authority risks seen in agentic access patterns. |
Grant contractor access through named accounts, review it regularly, and revoke it immediately when scope changes.
Related resources from NHI Mgmt Group
- How should organisations reduce risk from North Korean IT worker fraud in hiring and contractor onboarding?
- How should security teams reduce contractor fraud when third parties need remote access to internal systems?
- What is the difference between account takeover and new account fraud?
- Who is accountable when contractor-held credentials expose cloud and internal systems?
