Key takeaway: Provisioning errors get reported within an hour because someone cannot work. Deprovisioning errors get reported never, because nobody notices access that still functions.
The Asymmetry
An account that fails to create generates an immediate complaint. Someone cannot log in on their first day and the problem is fixed within the hour.
An account that fails to delete generates nothing. The person left, their access remains, and no process examines it. The only way this surfaces is a deliberate audit, and the results are consistently uncomfortable — accounts active for people who departed a year earlier.
That access is exactly what an attacker wants. It belongs to no one, so nobody monitors its use, and its activity cannot be verified against a real person’s expected behaviour.
Where the Gaps Are
Directory-integrated applications deprovision correctly. Everything else does not.
| Access type | Deprovisioned automatically |
|---|---|
| SSO-integrated SaaS | Yes, if SCIM is configured |
| SSO without SCIM | Session ends, local account persists |
| Local application accounts | No |
| Database users | No |
| SSH keys on servers | No |
| API tokens the person created | No |
| Personal access tokens in repositories | No |
| Shared credentials they knew | No |
The distinction between SSO and SCIM matters and is widely misunderstood. Single sign-on controls authentication, so disabling the directory account prevents new logins. It does not delete the account in the application, and if that application also permits local password authentication, the account remains usable.
API tokens are the largest practical gap. A departing engineer may have created a dozen tokens across services, each valid indefinitely and each authenticating as them. Disabling their directory account does not revoke any of them.
Building Reliable Offboarding
Enumerate access rather than assuming. The offboarding checklist should be generated from an inventory of systems, not from memory. Anything not in the inventory will be missed.
Prefer SCIM over SSO alone. Provisioning integration means the account is actually deactivated in the application rather than merely unreachable through the directory.
Revoke tokens explicitly. Every token an individual created must be enumerable and revocable. If your platforms cannot report tokens by creator, that is a gap to close before it matters.
Rotate shared credentials. Anything the person knew and cannot be individually revoked needs changing. This is the argument against shared credentials existing at all.
Verify rather than trust. Run a reconciliation comparing active accounts in every system against current employees. Differences are findings, and the first run always produces several.
The Mover Problem
Role changes are handled worse than departures. Someone moving from support to engineering gains engineering access and keeps support access, because addition is requested and removal is not.
Over several years an internal transfer accumulates the union of every role they have held. That accumulation is invisible in any individual approval and substantial in aggregate.
Handle transfers as a departure followed by an onboarding: remove all access, then grant what the new role requires. It is more disruptive and it is the only approach that prevents accumulation.
The Bottom Line
Generate offboarding from a system inventory rather than memory, use SCIM rather than relying on SSO alone, revoke individually created tokens explicitly, and reconcile active accounts against current employees on a schedule. Treat internal transfers as departure plus onboarding.
