Contractor access
External access is granted for a project and outlives it by quarters. Why contractor accounts escape every review, and how end dates fix what memory can't.
of breaches involve a third party
2026
•
Verizon DBIR
of leaders saw harm from a former employee's access
2022
•
Beyond Identity
of employees still have access to a previous employer's account
2022
•
Beyond Identity
Contractor accounts are provisioned for a defined project and reviewed by nobody once the project ends.
what 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.
why 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.
what 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 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.
practical guides you might find useful
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there

+48 783 762 997
julian@unshadowit.com



.svg.png)


