They know offboarding is complete when the revocation checklist is built from current entitlements, not from an old spreadsheet or onboarding record. Completion should be confirmed against live access data across apps, directories, and privileged systems. If the workflow cannot prove removal, the account is not fully offboarded.
Why This Matters for Security Teams
offboarding is only real when access is removed everywhere the identity could still be used, not when a ticket is closed or HR marks a departure complete. For NHIs, the risk is often higher than for people because service accounts, API keys, and tokens can remain valid long after the business thinks the owner is gone. That is why current guidance places so much weight on live inventory, not static records, as reflected in the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0.
NHI Management Group research shows how severe this gap can be: 91% of former employee tokens remain active after offboarding in the 2025 State of NHIs and Secrets in Cybersecurity by Entro Security, which is exactly why completion must be proven, not assumed. If the revocation process does not reconcile directories, SaaS apps, privileged platforms, and secret stores against live entitlements, then the “offboarded” identity is still present in practice. In practice, many security teams discover incomplete revocation only after the account has already been reused or abused.
How It Works in Practice
Complete offboarding starts with a current entitlement baseline. That means the revocation checklist should be generated from live identity data, privileged access records, application connectors, and secret inventories, not from onboarding paperwork or a stale spreadsheet. The operational goal is simple: prove that every path to authentication or authorisation has been closed.
For human identities, that typically includes directory disablement, SSO deprovisioning, mailbox and device revocation, PAM session termination, and removal from groups, roles, and shared mailboxes. For NHIs, the workflow must also cover API keys, OAuth tokens, certificates, workload identities, CI/CD variables, and embedded secrets. The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and Top 10 NHI Issues both reinforce that lifecycle control fails when teams treat secrets as a one-time setup problem instead of a continuously managed state.
- Reconcile the identity against all authoritative sources before revocation begins.
- Disable access at the directory or broker layer, then revoke downstream tokens and keys.
- Confirm removal from privileged groups, service bindings, and automation pipelines.
- Validate deletion or expiry of secrets in vaults, code, config, and CI/CD stores.
- Log evidence of each successful removal and keep the proof with the offboarding record.
Completion should be treated as a verification event, not a workflow status. If a system cannot prove that access was removed, the offboarding is incomplete. These controls tend to break down in highly distributed environments where app ownership is fragmented and secret sprawl makes it impossible to verify every credential path quickly.
Common Variations and Edge Cases
Tighter offboarding controls often increase operational overhead, requiring organisations to balance speed of departure against proof of revocation. That tradeoff becomes sharper when the identity spans multiple business units, external vendors, or automated workloads that do not map neatly to a single owner.
Best practice is evolving for agentic and machine-driven identities. There is no universal standard for this yet, but current guidance suggests that organisations should require runtime proof of deactivation for workloads, not just administrative closure. A service account might be disabled in IAM but still hold a valid token in a cache, still appear in a CI/CD variable, or still possess a certificate that survives the original owner’s departure. In those cases, offboarding is not complete until the last usable credential is gone.
Two edge cases matter most. First, shared accounts and overused NHIs can make “complete” revocation risky if another system still depends on them, so replacement identities must be staged before removal. Second, third-party integrations often require coordinated revocation across boundaries, which is why the NHI Lifecycle Management Guide is useful for defining handoff points and evidence requirements. In practice, the hardest offboarding failures are found in legacy systems and shadow automation where nobody can name every place the credential still exists.
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 AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Directly addresses NHI lifecycle revocation and lingering credentials after offboarding. |
| NIST CSF 2.0 | PR.AC-4 | Supports timely access revocation and least-privilege enforcement during offboarding. |
| NIST AI RMF | GOVERN | Autonomous and AI-driven workloads need governed lifecycle accountability and traceability. |
Reconcile live NHI entitlements and revoke every token, key, and certificate before closing the offboarding record.
