Accountability sits with the identity governance process owner, not the departing employee. Organisations need a clear offboarding control owner, a complete view of app entitlements, and evidence that revocation reached every downstream system.
Why This Matters for Security Teams
When a departing user still has access, the immediate issue is not just residual access. It is control failure across identity governance, application ownership, and downstream entitlement propagation. Offboarding often looks complete in the HR system while access remains active in SaaS apps, legacy directories, shared mailboxes, or custom integrations. The real accountability sits with the process owner who is meant to ensure revocation, not with the departing employee who no longer controls the workflow.
That distinction matters because access removal is only as strong as the weakest connected system. NHI Management Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a useful signal of how often revocation discipline is incomplete even when policy exists. OWASP’s Non-Human Identity Top 10 reinforces the same pattern for machine access: identity lifecycle failure is a governance problem, not a user-behaviour problem. In practice, many security teams discover lingering access only after audit evidence is requested or an account is abused.
How It Works in Practice
Effective accountability starts with a named control owner for joiner-mover-leaver events and a defined revocation path that reaches every application, directory, token store, and privileged workflow. HR may trigger the event, but identity governance must confirm completion. That means the process owner needs three things: a complete entitlement inventory, authoritative source-of-truth mapping, and evidence that deprovisioning succeeded in each downstream system.
Practically, the workflow should include:
- Immediate disablement of the primary directory account and any active sessions.
- Removal from RBAC groups, application roles, and privileged access pathways.
- Revocation of API tokens, SSH keys, refresh tokens, certificates, and delegated grants.
- Verification checks against each target system, not just the identity platform.
- Exception handling for shared accounts, service accounts, and break-glass access.
This is where guidance from the 52 NHI Breaches Analysis becomes operationally relevant: missed revocation is rarely a single error, but a chain of partial control failures across systems. NIST’s Zero Trust Architecture supports the principle that access should be continuously evaluated rather than assumed durable. Applied to offboarding, that means the organisation must treat every app and token as independently revocable and independently verify the result. These controls tend to break down in federated SaaS estates with unmanaged local admins because the identity team cannot see or enforce the final removal step.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of revocation against application complexity and business continuity. That tradeoff becomes visible when contractors, temporary staff, and third-party users share workflows with employees, because the correct access state depends on contract terms, not just employment status.
There is no universal standard for this yet, but current guidance suggests treating the process owner as accountable for evidence of revocation, while application owners remain accountable for making their systems revocable. In environments with SCIM, SSO, and automated lifecycle tooling, the process can be mostly machine-driven. In older environments, manual sign-off, screenshots, and ticket closure may still be necessary, though they are weaker evidence.
Special cases need explicit handling:
- Shared accounts: accountability shifts to the account steward, because no single departing user can be the control point.
- Privileged users: PAM and JIT access should reduce standing access before departure, not after.
- Service-linked access: a human departure may leave automation credentials behind, so secret rotation may be required.
For broader lifecycle control, the Ultimate Guide to NHIs is useful because it frames revocation as part of ongoing identity governance, not a one-time HR task. This guidance breaks down most often in organisations with shadow IT and locally managed SaaS admin roles, because there is no reliable downstream owner to confirm access removal.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access removal and least privilege map directly to lifecycle revocation. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Revocation failures mirror NHI lifecycle and secret management gaps. |
| NIST Zero Trust (SP 800-207) | Zero Trust requires re-evaluating access instead of assuming it ends cleanly. |
Automate entitlement and secret revocation, then verify downstream removal for every dependent system.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
