Contractor Identity Chaos: Why Your Joiner-Mover-Leaver Process Breaks for Non-Employees

Picture this: your SOC 2 audit is underway, and the auditor asks a simple question - "Can you show us who had access to your GitHub organization over the past 12 months, and confirm that everyone currently in there is still active?"

You pull the list. One name jumps out. A developer who did a three-month engagement that ended nine months ago. Their GitHub access - repos, internal tools, the works - is still live.

That's not a hypothetical. It's the kind of finding that shows up in real audits, triggers real remediation plans, and occasionally ends careers. And almost every time, the root cause is the same: the organization's identity governance was built around employees. The contractor slipped through the gap.

The Scale of the Problem Nobody Talks About

Here's the uncomfortable reality: a significant chunk of your workforce isn't in your HR system.

Contingent workers - contractors, freelancers, consultants, agency staff - now make up roughly 30-40% of the U.S. workforce, according to a U.S. Government Accountability Office report, and that number is expected to climb toward 50% by 2050^{1and that number is expected to climb toward 50% by 2050}. Meanwhile, about 48% of companies are aware that former workers still retain access to company systems, according to research cited by TechRepublic.

These two facts together are the problem. Contingent workers are everywhere - touching your code repositories, your cloud environments, your project tools, your customer data - and most identity governance programs still assume the workforce is made of employees with HRIS records.

It isn't. And that mismatch has real consequences.

The JML Blindspot: Why the System Was Never Built for Contractors

Most organizations run some version of joiner-mover-leaver (JML) automation. An employee is hired -> HR creates a record -> a workflow fires -> accounts get provisioned. An employee is terminated -> HR closes the record -> SSO gets disabled -> (ideally) connected apps get deprovisioned via SCIM.

The automation works when the HR system is the source of truth. The problem: contractors, in most organizations, aren't in the HRIS.

They're tracked in a spreadsheet. A vendor management portal. Someone's email thread. They get onboarded because a manager sent IT a request ticket - not because HR triggered a lifecycle event.

So when a contractor's engagement ends, nothing automated fires. No termination event propagates through the system. Nobody's workflow gets triggered. The IT team might get a Slack message weeks later - or never hear about it at all. The contractor's Jira account, Slack workspace, GitHub membership, and Notion access stay exactly as they were on day one.

This isn't a failure of the IT team. It's an architectural gap. The JML process was designed for employees. Contractors were an afterthought - and the tooling reflects that.

What Happens After the Contract Ends

The downstream consequences are predictable but underestimated.

Orphaned accounts pile up silently. A December 2025 Veza report found 824,000 active identities with no associated owner in HR systems - approximately 8% of all identity provider users - with orphaned identities increasing roughly 40% year over year, according to Help Net Security^{2according to Help Net Security}. Even more striking: when HR systems flagged accounts as inactive, 38% of those identities still held live entitlements in core business applications.

A contractor's account being "gone" in one system means nothing if it's still active in twelve others.

Overprovisioning is the rule, not the exception. When contractors are onboarded fast - because there's a deadline and no time for a proper access review - they get broad access. "Give them the same setup as the dev team for now." That broad access never gets right-sized, and it certainly doesn't get cleaned up when the contract ends.

The audit gap is immediate. When a compliance framework asks you to prove who had access to a sensitive system at a given point in time, orphaned contractor accounts become a formal finding. Verizon's 2024 Data Breach Investigations Report found that over 22% of data breaches involve insiders, with access mismanagement as a recurring root cause, as noted across multiple security sources^{3as noted across multiple security sources}. Contractor access that was never properly deprovisioned sits squarely in that category.

And practically: 43% of businesses may have former employees or contractors who can still access organizational code repositories on GitHub or GitLab, according to Wing Security research^{4according to Wing Security research}. Code repositories. Where your proprietary software lives.

Why SSO Doesn't Save You Here

The common response when this gap comes up: "But we use Okta. If we disable someone in Okta, they lose access."

True - for apps connected to Okta via SSO, and only for authentication through that path.

Contractors frequently exist entirely outside the corporate identity perimeter. They might be onboarded with a personal Gmail address to a project management tool. A shared team account for a client portal. A direct login to GitHub that someone set up because the contractor wasn't in the directory. A production database credential passed over Slack.

None of those accounts are governed by your SSO provider. Disabling the corporate Okta account accomplishes nothing for them. And the contractor probably never had a corporate Okta account to begin with.

This is the SSO perimeter problem: your SSO covers the apps you connected it to, for the users who are in it. Contractors are often in neither category.

The Vertical Reality: It's Worse in Some Industries Than Others

The generic framing of "contractor access is messy" understates how acute the problem is in specific sectors.

Logistics and Maritime

Crew members, port workers, and seasonal staff rotate constantly - often without ever appearing in a central directory. They get temporary access to dispatch systems, vessel tracking software, or communication tools for a voyage or contract period. When they leave, access revocation depends entirely on someone manually remembering to do it. In organizations where the IT team is small and the workforce is highly transient, orphaned accounts accumulate by default.

Healthcare

External providers - radiologists, locum physicians, specialist consultants - routinely need access to EHR systems and patient data for a specific period. They're onboarded for clinical reasons, not through standard IT processes. When their engagement ends, their credentials to those systems often don't. The HIPAA Security Rule^{5The HIPAA Security Rule} explicitly requires covered entities to control access to PHI, including for external parties. Orphaned provider portal accounts are a direct compliance gap - and an auditable one.

Manufacturing and M&A

Subcontractors during plant expansions or acquisitions frequently get access to production systems, OT environments, and operational tools with no SCIM support and limited API capabilities. In an M&A context - where multiple tenants and fragmented systems are the norm - contractor access from the acquired entity may not even appear in the acquirer's identity systems. It just floats there, attached to a system nobody owns anymore.

Tech and SaaS Companies

Fast-growing tech teams routinely bring in contractors for engineering sprints, security reviews, or product work. The stack is typically modern - GitHub, Linear, Notion, Figma, Jira - but access is granted informally and often via personal accounts because the contractor isn't in the directory. These apps frequently require enterprise plan upgrades to unlock SCIM support (the SCIM tax), meaning the SCIM-based deprovisioning that works for employees doesn't apply to tools the company actually uses day-to-day.

The Audit Finding That Changes Everything

There's usually a moment that transforms this from "known problem, low priority" to "we need to fix this now." It looks like one of these:

• An auditor discovers a terminated contractor's account still active in a system containing regulated data. The finding goes in the report. The company gets a remediation requirement.
• A security incident traces back to credentials belonging to someone whose engagement ended months ago. The question becomes: how many other stale accounts exist?
• A routine access review, done manually via spreadsheet, reveals that nobody can actually answer "who has access to this system?" for contractor identities. The answer is "we think these people, but we're not certain."

A September 2025 case at FinWise Bank saw a former employee access sensitive customer information for nearly 700,000 individuals after their employment ended - not through a sophisticated hack, but simply through an account that was never disabled, as documented publicly^{3as noted across multiple security sources}. Contractor scenarios follow exactly the same pattern, with one added complication: there's often no termination event to even prompt someone to check.

The buying trigger for modern identity governance is almost always one of these moments. The organization discovers the gap viscerally, not theoretically. Then they realize the tools they have - SSO, SCIM-connected apps, manual offboarding checklists - weren't built to solve this.

What Actually Fixes This

No single policy change closes the contractor identity gap. But the organizations that handle it well share a few things in common.

They govern contractor identities separately from employee JML flows. Contractor access is tracked in a system that doesn't depend on HRIS events. Engagement start and end dates drive automated provisioning and deprovisioning, independent of Workday or BambooHR.

They use time-bound access, not open-ended access. Access granted to a contractor has an expiry date baked in at provisioning time. When that date arrives, access is revoked automatically - without anyone having to remember. This is the single most effective control for the orphaned-contractor-account problem.

They cover the full app stack, not just SCIM apps. The tools contractors typically access - project management tools, code repos, communication platforms, client portals, internal wikis - are often the exact apps that don't support SCIM at standard pricing tiers. Identity governance that stops at SCIM leaves contractor access ungoverned where it matters most. (For a deeper look at what JML automation across non-SCIM apps actually involves, see our guide on automating JML for apps without APIs.)

They have a single view across all identities - employees, contractors, service accounts. The audit question "who has access to this system right now?" should be answerable in seconds, not weeks of spreadsheet archaeology.

Platforms that address this directly - rather than bolting contractor management onto an employee-first IGA model - look for things like: universal app coverage (SCIM, API, or neither), policy-driven lifecycle automation triggered by contract dates rather than HR events, time-bound access controls, and automated offboarding that doesn't require a manual handoff.

The contrast with legacy IGA or SCIM-only tooling is worth understanding directly:

Iden was built to address exactly this gap - universal connectors that reach every app in the stack, time-bound access that expires automatically, and lifecycle automation that doesn't require a contractor to exist in your HRIS first. If contractor identity governance is the gap you're trying to close, see what complete coverage actually looks like.

Takeaways

The contractor identity problem isn't new. What's changed is the scale. As contingent work becomes a standard part of how organizations operate - not a fringe arrangement - the identity governance gap grows proportionally.

The summary:

• Contractors don't generate HR events. Your JML automation was built on HR events. That's the root cause.
• SSO doesn't cover what it can't see. Contractors often exist outside the SSO perimeter from day one.
• Orphaned accounts are a statistical certainty without a system specifically designed to prevent them.
• The audit finding is a matter of when, not if - especially in regulated industries.
• The fix requires covering the full stack - not just SCIM apps - with time-bound access and automation that works independently of HRIS triggers.

The organizations that get ahead of this do so before the auditor asks the question they can't answer. The ones that don't learn the lesson the hard way.

Stop contractor access from going stale - book a demo to see how Iden handles the full contractor lifecycle^{6Stop contractor access from going stale — book a demo to see how Iden handles the full contractor lifecycle}

Frequently Asked Questions