Disabling the account is the easy part
When someone leaves, most organisations run a version of the same routine. IT disables the account in Microsoft 365 or Google Workspace, collects the laptop, archives the mailbox, and closes the ticket. That routine handles the access the identity provider knows about. In most businesses the identity provider knows about far less than people assume.
The access that causes trouble later lives outside the routine. It sits in a SaaS product that was never connected to single sign-on, in an API key cut for a project three years ago, in a shared password that four people knew and one of them has just left with. None of it is touched when the directory account is disabled, because none of it depended on the directory account in the first place.
The failure mode is rarely dramatic. A credential stayed valid after its owner left, and at some point somebody used it. Sometimes that somebody is the former employee checking whether the login still works, and sometimes it is an attacker who found the credential in a breach dump and now holds working access attributed to a person nobody is watching.
What the standard leaver process misses
Six categories of access routinely survive offboarding, because each of them authenticates outside the directory or below its line of sight.
- Shared accounts. The domain registrar login, the social media accounts, the router admin password, the generic admin mailbox. A leaver takes the password with them, and because the account belongs to nobody, nobody thinks to rotate it.
- API keys and tokens. Keys issued under a person's account often keep working after they leave, and copies pasted into CI pipelines, scripts and integrations outlive the account they came from. If nobody can list which keys exist, nobody can say which ones died with the leaver.
- OAuth grants. Every app a person connected to their mailbox, calendar or files holds its own grant of access. Disabling the account cleanly kills most of them, but accounts are often kept alive as shared mailboxes or left active while licences are sorted out, and the grants keep running with them. Grants approved on shared accounts survive regardless.
- Third-party SaaS. Tools signed up for with a work email and a company card and never connected to single sign-on. The person's row in that product's own user list stays active until someone opens its admin console and removes it, and often nobody does, because nobody remembers the product exists.
- MFA devices and recovery details. A personal phone registered as the second factor or the recovery number on a shared or privileged account can approve sign-ins and receive reset codes long after its owner has left the building.
- Forwarding rules and delegated access. A mailbox rule that forwards to a personal address, set up for convenience months earlier, keeps forwarding after the mailbox is converted to a shared one. Delegate permissions on other people's mailboxes and calendars are almost never reviewed at exit.
The fix is an access inventory, and it is smaller than it sounds
Leavers keep access because at the moment of departure nobody can enumerate what they had. The durable fix is a register of systems, written at the moment access is granted rather than reconstructed at exit. For each system it records what the system is, who can reach it, how they authenticate, whether it sits behind single sign-on, and who owns the entry.
The directory is the spine of the inventory. Everything federated through it offboards in one action, which is the strongest argument for putting every SaaS product behind single sign-on even where the vendor charges more for the tier that supports it. The register earns its keep on the remainder: the products that cannot federate, the shared credentials, the API keys, the infrastructure logins. Shared credentials belong in a password manager with named access, so that the question of who knew a given password has an answer.
None of this needs new software. A spreadsheet that is honestly maintained beats a tool nobody updates. What it needs is a working rule that access is never granted without a row being written, and an offboarding checklist generated from the register instead of from memory. ISO 27001's Annex A expects access rights to be removed or adjusted when employment ends or changes, and an auditor will pick a recent leaver and ask for evidence. The register is that evidence.
The quarterly orphan hunt
Any inventory maintained by people drifts, so it gets checked by reconciliation. Once a quarter, pull the user list from every system in the register and diff it against the current staff list from payroll or HR. Every row that matches a person who has left is an orphan. So is every account that nobody can attribute to a person at all. In a Microsoft-stack organisation the pass looks like this:
- Export users from each SaaS admin console and diff against the staff list. The products outside single sign-on are the point of the exercise.
- Pull sign-in activity from Entra ID and flag accounts with no interactive sign-in for the quarter, including guest accounts, which accumulate quietly in most tenants.
- Review enterprise applications and their consented permissions in Entra ID, and remove grants for any app nobody can name an owner for.
- List organisation members and outside collaborators in GitHub, and audit personal access tokens and deploy keys by age.
- Sweep mailbox forwarding rules tenant-wide for external destinations.
- Confirm every shared credential a recent leaver knew was rotated, dated from their final day.
Treat every orphan as two findings
The first finding is the access itself, which gets removed. The second is the process gap that let it survive offboarding, which gets traced back and closed, usually by adding the system that held it to the register. Worked this way, the hunt gets more boring every quarter, and boring is the goal. A hunt that keeps finding fresh orphans is telling you the leaver process has a hole in it.
The Essential Eight points the same direction. Its restrict administrative privileges strategy expects privileged access to be revalidated on a schedule, with access that isn't revalidated in time disabled automatically, and the quarterly pass is what produces the evidence that it actually happens.
Service accounts are employees who never leave
Every environment accumulates identities that exist for software. The account the backup job runs as, the integration user in the CRM, the credential the printer uses to scan to email, the service principal a contractor created during a migration. They hold real privileges and authenticate every day, and no leaver process will ever fire for them because they never resign. Nobody owns most of them.
The failure pattern is consistent. The person who created the account leaves. The password lives in a config file, or in the deployment, or in nobody's head at all. Nobody knows what breaks if the account is disabled, so it is never disabled, and its privileges are never questioned. A decade later it still holds domain admin because that was easier at the time.
Run them like staff. Every service account gets a named human owner, a written purpose, the least privilege the job needs, and a credential rotation date. They go through the same quarterly review as people, and when their owner leaves, ownership transfers explicitly as part of that person's offboarding. Where the platform supports it, remove the standing credential entirely: managed identities in Azure and workload identity federation for pipelines mean there is no password to know and nothing for a leaver to take.
A test you can run this week
Pick the most recent person who left after more than a year of tenure, and check five things. Whether any mailbox rule or delegate permission still touches their mail. Whether any OAuth grant they approved is still active. Whether any API key or token attributed to them still works. Whether they still appear in the user list of any SaaS product the company pays for. And whether every shared credential they knew has been rotated since their final day.
If all five come back clean, the leaver process is in better shape than most. If any come back dirty, the gap now has a name, and the register and the quarterly hunt above are how it stays closed. Reviews of exactly this kind are standing work inside our security reviews and vCISO engagements, because the directory is rarely where the gap sits, and finding the systems the directory has never heard of takes deliberate hunting. Close the gaps the test surfaces, add the systems that held them to the register, and the next departure becomes a checklist instead of a search.