in one lineContractor access is any credential granted to an external person for a defined engagement; it should expire when the contract ends.
the numbers
- 83%of employees still have access to a previous employer's account (self-reported)Beyond Identity, 2022
- 74%of leaders saw harm from a former employee's lingering accessBeyond Identity, 2022
- 48%of breaches involve a third partyVerizon DBIR, 2026
1what it is
Contractor access refers to any login, permission, or credential granted to an external person or organization for a defined period of work. This includes independent consultants, agency staff, software vendors given access to configure or maintain a system, and temporary workers on fixed-term contracts.
External people often need to access your systems to do their work, and granting that access is reasonable. The problem is what happens to it when the work ends. In environments without a process that explicitly ties access to a contract end date, the answer is often: nothing.
2why it accumulates
Contractor access is typically created at the start of an engagement by whoever is managing the project. IT may or may not be formally involved. The project manager knows the contractor needs access; the contractor gets it. The method of provisioning depends on the system.
When the project ends, the trigger for removing access is often informal. A project manager closes their work items but doesn't file a deprovisioning request. An agency finishes a piece of work but is expected back for follow-up, so IT leaves the account active. The contractor's own organization doesn't flag the end because they're still hoping for more work.
The result is that access removal depends on someone specifically deciding to remove it. There's no automatic expiry. Nobody is watching a calendar of contract end dates and acting on them. The access stays until a review or an incident surfaces it.
3what it costs you
Contractor access that outlives the contract is active access in your environment held by someone with no current obligation to your organization. The relationship that created a level of trust around that access has ended. The access hasn't.
In terms of compliance, this creates a clear gap. The expectation in frameworks like SOC 2, ISO 27001, and DORA is that third-party access is managed on a defined basis and revoked when no longer needed. "We forgot to remove it" doesn't satisfy an auditor.
There's also a data protection dimension. Contractors may have had access to personal data, financial records, or proprietary systems. Access continuing after the engagement ends extends the data exposure window beyond the agreed scope. Under GDPR, this can constitute processing on a basis that no longer applies.
According to IBM's Cost of a Data Breach report (2025), it takes an average of 241 days to identify and contain a breach. Former contractors whose access was never revoked fall into the same category as former employees: they're an open door in your environment with no active monitoring to notice.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedCash App / Block, 2022howThe person logs back in from home, weeks after leaving.what leavescustomer lists and reportswho ends up with itthe former employee and whoever they work for next
- it happenedColonial Pipeline, 2021howThe forgotten account's password turns up in a breach dump.what leavesa working way into the networkwho ends up with ita ransomware crew
- it happenedCloudflare, 2023howA key or token set up for old work keeps working after everyone forgets it.what leavesinternal systems and documentswho ends up with itwhoever tries the key first
4what works
The starting point is an inventory of every external account, and the directory usually gives them away: accounts on external email addresses, accounts whose domain differs from the standard company one, and accounts explicitly flagged as contractor or vendor. The main IdP is only half the picture; individual SaaS applications hold external accounts of their own that never touched the directory.
Each external account then gets tested against one question: is there a current, active contract behind it? Cross-referencing the account list against engagement records separates live access from leftover access, and anything without a corresponding engagement is a candidate for immediate review. Access paths beyond the directory deserve a separate pass, because contractors often hold VPN credentials, direct logins to infrastructure, and code repository access that no application user list will show.
What prevents the problem from rebuilding is time-bound provisioning: every new external account created with an expiry or review date tied to the contract end. Some IdP platforms support account expiry natively; for systems that don't, a calendar reminder with an assigned owner is a workable substitute, and far better than no trigger at all. The companion control is internal ownership, every external account mapped to a current employee who is accountable for requesting removal when the engagement closes. With those two in place, contractor access stops depending on anyone remembering to act, which was exactly the dependency that let it accumulate.
on the record
your turn
what you can do about it
this week
List every active contractor account and the end date of each contract.
Any account without an end date is the first to review.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →