Offboarding access
Closing the directory account is step one of twenty. Where leaver access survives, and what complete offboarding actually covers.
of manual offboarding misses SaaS applications
2026
•
Reco
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
The OAuth grants, direct logins, and tokens a leaver collected keep working after the directory account closes.
what 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.
why 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.
what 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 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.
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)


