Treat that as a governance failure, not an administrative delay. The priority is to identify which systems sit outside the central offboarding path, then bring them into the same lifecycle model so access is revoked across all relevant platforms and not only in the primary IAM system.
Why leaver workflows fail when access is left behind
When offboarding only works in the primary IAM platform, the organisation has not actually completed deprovisioning. The practical failure is usually not the leaver process itself, but the presence of downstream applications, integrations, shared credentials, or manually managed accounts that never receive the same lifecycle event. That creates inconsistent revocation and leaves access active where the business still depends on it.
In practice, the first question is whether the leaver path is authoritative for every system that can grant access. If a platform is outside that path, the process is not closed, even if the HR record and core directory were updated correctly. Resources such as Joiner-Mover-Leaver (JML) Guide and SCIM and Automated Provisioning Guide are useful because they show how lifecycle control depends on connectors, authoritative sources, and deprovisioning coverage beyond a single directory.
That also means organisations should distinguish between a completed administrative task and a completed security outcome. A removed account in one system does not matter if an active token, service credential, or local application account still grants access elsewhere. The same principle is reflected in the IAM and IGA Basics resource, which frames provisioning, access governance, and entitlement review as connected controls rather than isolated events.
How to close the offboarding gap across systems
The answer is to map the full access path, not just the identity source. Organisations need an inventory of every system that can authenticate a user, accept a token, or keep a local entitlement alive after central deprovisioning. Once those dependencies are known, they should be brought into the same leaver model through automation, owner assignment, or explicit exception handling so access removal becomes repeatable and testable.
Where lifecycle coverage is uneven, the fix is usually to standardise the control plane around common offboarding triggers and to remove hidden manual steps. That is especially important for applications that use local accounts, API credentials, or delayed sync. The NHI Lifecycle Management Guide is relevant here because it treats offboarding, visibility, and governance as part of the same lifecycle discipline, and the Workforce Identity Security Guide shows how provisioning and deprovisioning need to be aligned with federation, account recovery, and session control.
For high-friction integrations, the operational decision is whether to automate, replace, or formally contain the gap. If a system cannot consume the central leaver event, it should either be integrated, placed under compensating control, or flagged as a higher-risk exception with named ownership and review cadence. That approach is consistent with the Top 10 NHI Issues perspective, because stale access and orphaned credentials are governance problems, not just workflow defects.
What good leaver governance looks like in practice
Good practice is to define offboarding as a complete lifecycle outcome with measurable coverage. That means every relevant application, connector, local account, token, key, and exception path has an owner, a revocation trigger, and an evidence trail. Organisations should also test leaver flows with real system samples, because the weakest point is often the platform nobody remembers to include.
At scale, the useful measure is not how quickly one directory entry changes, but how completely access disappears across the estate. Teams should verify that the leaver event reaches all systems with standing access, that orphaned accounts are discovered and removed, and that exceptions are short-lived and visible. The most useful operational question is whether a departing user can still authenticate anywhere after the official offboarding event has completed.
A second useful check is whether ownership is explicit enough to survive staff changes and application sprawl. If no one can say who owns the downstream revocation step, that system will eventually become a blind spot. The best outcome is a lifecycle model where revocation is automatic for normal cases, reviewed for edge cases, and escalated when a system cannot prove it has honoured the leaver event.
Risk and Threat Considerations
Leaver workflow gaps create lingering access, which can be abused by the former employee, a compromised account, or anyone who finds an unrevoked credential. The risk is highest where access persists in secondary systems, shared accounts, or service integrations that are not checked by the primary IAM platform.
Failure mechanism: The organisation removes access in one control plane but leaves alternate paths active, such as local application accounts, cached sessions, tokens, API keys, or manually managed entitlements. That breaks the assumption that offboarding equals revocation.
Impact: Attackers or insiders can continue to read data, reuse permissions, impersonate the departed user, or move laterally through systems that still trust the old access path. The longer the gap persists, the harder it becomes to distinguish legitimate use from abuse.
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 and CIS Controls v8 set 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 gaps often persist through unrevised tokens, keys, and credentials. |
| AC-2 — Account Management | Offboarding is fundamentally account lifecycle control across all connected systems. | |
| Recommendation — Revoke and rotate authenticators when offboarding removes a user or account. Ensure account disablement and removal are enforced across every system that grants access. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Leaver workflows must remove access consistently, including exceptions and stale accounts. |
| Recommendation — Harden deprovisioning and remove unused or orphaned access paths promptly. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | The question is about managing identities through their full lifecycle, including leavers. |
| A.5.18 — Access rights | Leaver workflows are about withdrawing access rights, not just closing one account. | |
| Recommendation — Maintain identity lifecycle procedures that revoke access everywhere a user is authorised. Remove access rights from all relevant assets and record the revocation evidence. | ||
Practitioner Guidance
What to prioritise: Start with the systems that can grant direct business access outside the primary IAM path, especially applications with local users, manually issued tokens, or separate admin consoles. Those are the places where leaver failures most often become real exposure.
What to verify: Confirm that offboarding removes access in the source directory, the downstream application, and any bearer material that can outlive the account, such as tokens or keys. If the process does not produce evidence for each of those steps, it is not reliable enough for audit or incident response.
Common mistake: Treating HR closure or directory disablement as proof that access is gone. In practice, the strongest control is a closed loop that proves revocation across all relevant systems, not just the system of record.
Practitioner takeaway: The right control objective is complete access disappearance, not successful completion of a single workflow step.
Related resources from NHI Mgmt Group
- How can organisations use access profiles in joiner-mover-leaver workflows?
- What is the difference between rotating a secret and revoking access?
- How can organisations reduce the risk of stale API keys and machine tokens?
- How can organisations reduce over-privileged OAuth access without breaking business workflows?