in one lineOffboarding access means removing every credential, permission, and integration a leaver held, not just their directory account.
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
- 65%of manual offboarding misses SaaS applicationsReco, 2026
1what it is
Offboarding access is the process of removing every system credential, permission, and integration belonging to someone who has left your organization. Not just their main directory account. Every application, every OAuth grant, every API token, every shared login they held.
In most organizations, offboarding consists of closing the account in Active Directory or the primary IdP. That's the part IT owns and can reliably execute. Everything below it depends on how well other systems are connected to that directory.
If an application authenticates through SSO, disabling the directory account disables access there too. If an application has a direct login that was never connected to SSO, the directory being closed means nothing to it.
2why it accumulates
Employees accumulate informal access continuously. A new SaaS tool adopted by one department. A direct login to an analytics platform created before SSO was configured. An API token generated to get something done over a weekend that nobody noted down.
By the time someone leaves, their access footprint is typically larger than any documented list. Offboarding relies on that list being complete. When it isn't, access outlives the employment.
The JML process has three phases: joiner, mover, leaver. Each one can introduce errors. New hires sometimes receive a prior employee's access profile rather than a clean role-based set. Role changes add new permissions without removing the old ones. Departures close the visible account while leaving everything that ran alongside it.
In environments without automation, each of these steps relies on a person to remember the right things at the right time. That's where offboarding breaks.
3what it costs you
The access that survives an offboarding process is live access to real systems. The person it belongs to may never use it. The risk is that they can.
IBM's Cost of a Data Breach report (2025) puts the average time to identify and contain a breach at 241 days. An account left open after departure can be used across that entire window without triggering any alert that would normally surface a breach.
The second implication is audit. Every compliance framework that touches access control asks how you handle leavers. SOC 2, ISO 27001, NIS2, and DORA all include requirements that translate directly to leavers being handled completely and within a defined time window. Partial offboarding is a finding.
There's also the case where nothing hostile happens at all. A former employee resets a password out of habit or contacts support to regain access. The problem doesn't require malice; access standing open after departure is the finding, whatever gets done with it.
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
A departure handled well starts from a map rather than from memory. The question that opens the process is where this person has access, and the answer comes from several sources at once: the IdP, user exports from the major SaaS applications, the OAuth grant log, and whatever direct logins are known. Without dedicated tooling the map won't be perfect, but an imperfect map still beats a checklist written from recollection.
Sequence matters, because removal takes time and risk is unevenly distributed. Admin rights, customer data systems, financial tools, and code repositories close first, whatever the state of the rest of the list.
OAuth grants are the step most processes miss. An application authorized via OAuth holds its own token, independent of the user's directory status, and disabling the account in the IdP doesn't reliably revoke the grants that user approved for third-party apps. Those grants need checking and revoking in their own right. The same logic covers API tokens and service accounts the departing person created: they typically have no transfer-of-ownership process, so they need to be found, assigned a new owner, and re-credentialed wherever the leaver was the sole holder.
The processes that stay reliable add a closing loop, a check around 30 days after departure confirming access actually ended everywhere. Systems that weren't wired into the main process reveal themselves there, and each one found is a permanent improvement to the next offboarding.
on the record
your turn
what you can do about it
this week
Put last quarter's leavers next to the active accounts in your five most important systems.
Any match is a door that stayed open.
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 →