They should verify three outcomes: the account cannot authenticate, no privileged role assignments remain, and all tokens and device trust have been invalidated. If any one of those persists, the identity is not fully offboarded.
How to prove offboarding was not just requested, but completed
The check should be outcome-based, not ticket-based. A valid offboarding result means the former identity can no longer authenticate, no longer holds any active privilege path, and no longer has reusable trust material such as tokens, keys, sessions, or device trust. If any one of those remains, access still exists somewhere.
That distinction matters because revocation often fails in one layer while succeeding in another. Teams need to test the environment the way an attacker or a stale integration would: by trying to authenticate, by checking entitlements, and by confirming that trusted credentials and devices no longer work.
What “no access” actually means across accounts, roles, and trust material
Offboarding is complete only when the identity is removed from the practical paths that could still be used to act. An account that is disabled but still mapped to a privileged role, a token that remains valid after the user left, or a device that still satisfies trust checks can all preserve real access even if the HR or workflow record says the person is gone.
The right verification set is therefore layered. First, confirm the account cannot authenticate. Second, confirm there are no remaining privileged assignments, group memberships, app roles, or delegated permissions. Third, confirm sessions, refresh tokens, API keys, certificates, and managed device trust have been invalidated or expired as intended.
This is where lifecycle controls and access governance converge. NHIMG’s Joiner-Mover-Leaver (JML) Guide is useful because offboarding should close the same pathways that provisioning opened, including token and key revocation. For a broader lifecycle view, the NHI Lifecycle Management Guide covers the same end-state from provisioning through decommissioning.
Why offboarding often looks complete when it is not
The most common failure is partial revocation. An organisation disables interactive login, but a refresh token, certificate, SSH key, OAuth grant, or application role still works. Another common miss is privilege residue, where the identity is removed from the primary account but remains in nested groups, break-glass paths, or indirect authorization chains.
Teams also overlook trust persistence. Devices, single sign-on sessions, federated assertions, and application-specific credentials can continue to operate after the human-facing account is gone. That is why a “disabled” status is not proof of removal unless it is paired with an explicit check of active entitlements and all token-bearing or device-bound access paths.
For a concrete example of what can happen when revocation is incomplete, the Coupang Signing Key Breach shows how unrevoked signing credentials can remain a real access path after offboarding. The same lesson appears in broader governance guidance such as IAM and IGA Basics, where entitlement review and access governance are part of the control, not an afterthought.
How teams should validate offboarding in practice
Validation should be explicit and repeatable, not inferred from system status. The most reliable pattern is to verify the three end states separately and record evidence for each one: authentication failure, privilege removal, and trust invalidation. If the environment uses federated login or delegated access, validate the upstream and downstream systems too, not only the primary directory.
When access is machine-mediated, teams should also check that any remaining credential material cannot be reused in automation, scripts, or integrated services. That includes API tokens, service credentials, certificates, and any device-bound trust that could let a stale identity reappear through a back door.
The practical standard is simple: offboarding is not done when a request closes, it is done when the identity has no remaining usable path to act. In addition to the JML guidance above, the Workforce Identity Security Guide is helpful when the offboarding path also involves session theft, SSO, or recovery flows that can outlive the account record. The broader Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is relevant whenever leaver cleanup includes service credentials or other non-human access paths.
Risk and Threat Considerations
Incomplete offboarding leaves a live access path behind, which creates both insider-risk and external-abuse exposure. If an attacker discovers stale credentials, inherited roles, or still-valid tokens, they can often use them without triggering the normal “user is disabled” assumption.
Failure mechanism: Revocation succeeds in one control plane but not in another, so authentication, authorization, or trust still works somewhere in the stack.
Impact: Former users, compromised accounts, or third parties can retain access to systems, data, and administrative functions after the supposed offboarding event.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Offboarding depends on revoking and expiring authenticators, tokens, and keys. |
| AC-2 — Account Management | Offboarding is an account lifecycle control that must remove active access paths. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Leaver cleanup often includes service, device, or other non-human access paths. | |
| Recommendation — Revoke and expire authenticators, tokens, and keys when access should end. Disable, remove, and review accounts until no active access path remains. Verify non-organizational authenticators are revoked and no longer usable. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The question is specifically about proving access removal after offboarding. |
| NHI-07 — Long-Lived Secrets | Persisting tokens or keys after offboarding keeps access alive. | |
| Recommendation — Confirm offboarding removes every remaining access path, not just the primary account. Eliminate long-lived secrets and replace them with bounded, revocable credentials. | ||
Practitioner Guidance
What to verify: Treat offboarding as incomplete until you can show three separate checks: the account no longer authenticates, no privileged assignments remain, and every token, key, session, and device trust path has been invalidated.
Common mistake: Teams often stop after disabling the primary login or closing the HR ticket. That misses delegated access, indirect roles, and long-lived credentials that continue to function after the visible account is gone.
Practitioner takeaway: The right question is not whether offboarding happened, but whether any surviving credential, trust, or entitlement can still be used to act.
Related resources from NHI Mgmt Group
- How can teams tell whether access governance is actually working?
- How can teams tell whether AI access is actually under control?
- How can security teams tell whether agent access is actually under control?
- How can security teams tell whether virtual entitlements are actually helping access governance?