Because disabling the directory account does not necessarily end active sessions, revoke tokens, or remove access from every connected application. A leaver process has to eliminate residual access across the whole stack, otherwise the user remains reachable through channels the directory no longer sees. That is a governance failure, not just an IT cleanup issue.
Why account disablement is only the first offboarding step
Directory disablement is a control on one access path, not a complete end state. The real offboarding problem is that a person may still hold valid sessions, refresh tokens, app-specific tokens, cached credentials, delegated access, or direct entitlements in connected systems after the main account is switched off. Joiner-Mover-Leaver (JML) Guide and IAM and IGA Basics both frame offboarding as lifecycle governance, not a single technical action.
That distinction matters because connected applications often maintain their own authentication state and entitlement records. If those records are not removed, the former user can remain active through SSO sessions, API tokens, shared accounts, or role grants that never depended on the directory in the first place. Workforce Identity Security Guide is useful here because it ties offboarding to session theft, federation, and account recovery paths that outlive a disabled login.
A mature leaver process therefore has to treat disablement, token revocation, entitlement removal, and application deprovisioning as separate checks. If one of those layers remains open, the organisation has not removed access, it has only hidden part of it from the directory. Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues both reinforce the broader point that lifecycle control is only complete when access is removed everywhere it exists.
Risk and Threat Considerations
The main risk is residual access after employment ends or after a role change, especially where the user has accumulated tokens, federated sessions, or app-local permissions that the directory does not automatically touch. That creates a window for misuse, accidental retention, or delayed detection because the identity source says the account is gone while other systems still honour the user.
Failure mechanism: Offboarding stops at directory disablement, but downstream systems continue to trust active sessions, cached credentials, refresh tokens, or independently managed entitlements. The former user can then keep accessing business systems until those credentials are explicitly revoked or expire.
Impact: The organisation keeps an access path alive after the leaver event, which can lead to unauthorised data access, fraud, privilege abuse, and audit findings. In higher-risk environments, the same gap can also preserve machine or application access that was tied to the departing person’s approvals, creating a wider governance failure than a simple account cleanup issue.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Leaver offboarding must revoke and retire authenticators, tokens, and keys. |
| AC-2 — Account Management | Offboarding is account lifecycle control, including disabling and removing accounts. | |
| AC-6 — Least Privilege | Residual access often persists through excess standing entitlements after disablement. | |
| Recommendation — Revoke and retire authenticators, tokens, and keys during offboarding. Remove or disable accounts and enforce timely account termination. Remove unnecessary entitlements and keep access to least privilege. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity lifecycle governance must ensure leavers lose access across systems. |
| A.5.18 — Access rights | Access rights must be removed when a user leaves or changes role. | |
| Recommendation — Maintain identity records so offboarding can remove every active access path. Revoke access rights promptly when offboarding a user. | ||
Practitioner Guidance
What to verify: Treat offboarding as complete only when you can show three things: the directory account is disabled, all active sessions and tokens are revoked or expired, and every application-specific entitlement has been removed or confirmed dead. If any one of those is missing, the leaver process is not finished.
What to prioritise: Start with the access paths that can remain valid independently of the primary directory, such as SSO sessions, refresh tokens, API credentials, and direct app roles. Those are the most common reasons a disabled account still functions somewhere else.
Practitioner takeaway: The right control objective is not “did we disable the account?” but “is there any remaining way for that person to authenticate, reuse a token, or act through another system?” That is the difference between a tidy admin action and defensible offboarding governance.