A predefined sequence of tasks used to remove access when a user leaves or changes role. A good playbook revokes licenses, removes permissions, and records evidence of completion, because workflow closure alone does not prove the identity has been fully deprovisioned.
Expanded Definition
An offboarding playbook is the repeatable operational sequence used to terminate access, revoke credentials, close dependencies, and capture proof that deprovisioning actually happened. In NHI operations, it applies to service accounts, API keys, tokens, certificates, and agent permissions, not just human users.
Definitions vary across vendors on whether a playbook is merely a checklist or a fully automated workflow. NHI Management Group treats it as a governance control that combines identity lifecycle policy, approval logic, execution steps, and evidence retention. That distinction matters because workflow closure in an ITSM tool does not mean the identity is fully removed from cloud, CI/CD, secrets storage, or downstream integrations. The operational standard is closer to NIST Cybersecurity Framework 2.0 than to simple ticket handling: access must be removed, dependencies resolved, and verification logged.
For NHI programs, the playbook should also define who owns exceptions, what happens when a system cannot immediately revoke access, and how long residual credentials may remain valid. The most common misapplication is treating ticket closure as deprovisioning, which occurs when teams retire the request but leave tokens, keys, or role bindings active in production systems.
Examples and Use Cases
Implementing an offboarding playbook rigorously often introduces coordination overhead, requiring organisations to balance fast employee or application transitions against the risk of leaving live credentials behind.
- A departing engineer’s laptop access is removed, but the playbook also revokes GitHub deploy keys, cloud roles, and CI/CD secrets that the engineer previously administered.
- An application is retired, and the playbook disables its service account, removes vault entries, rotates shared secrets, and confirms no scheduled jobs still depend on the identity.
- A contractor relationship ends, and the playbook records evidence that tokens were invalidated, MFA methods were removed, and downstream integrations were notified.
- A workload is migrated to a new platform, and the playbook ensures the old API client is decommissioned rather than left dormant as an unmonitored backdoor.
- According to the 2025 State of NHIs and Secrets in Cybersecurity, 91% of former employee tokens remain active after offboarding, showing why a documented process must verify actual revocation rather than assume it.
For lifecycle alignment, teams often pair the playbook with the NHI Lifecycle Management Guide so that decommissioning steps are tied to inventory, ownership, and exception handling instead of handled ad hoc. In distributed environments, the same pattern is also reflected in NIST Cybersecurity Framework 2.0 governance and access control expectations.
Why It Matters in NHI Security
Offboarding is one of the highest-risk moments in NHI security because identities often outlive the teams that created them. When access is not fully removed, former users, old integrations, and stale agents can continue to authenticate long after ownership has shifted or the business purpose has ended. That creates a durable attack path through forgotten tokens, overprivileged service accounts, and secrets stored outside controlled systems.
NHI Management Group research shows how common lifecycle failure is: only 20% of organisations have formal processes for offboarding and revoking API keys, and 97% of NHIs carry excessive privileges. Those conditions turn offboarding from an administrative task into a security control for limiting blast radius and proving closure. The Top 10 NHI Issues resource highlights why lifecycle gaps routinely lead to exposure, while the broader Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs ties offboarding to governance, rotation, and visibility.
Organisations typically encounter the consequence only after a departure, migration, or compromise reveals that an identity was never truly deprovisioned, at which point the offboarding playbook becomes operationally unavoidable to address.
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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Covers lifecycle and deprovisioning failures for non-human identities. |
| NIST CSF 2.0 | PR.AA-1 | Addresses identity proofing, access management, and revocation discipline. |
| NIST Zero Trust (SP 800-207) | PA-1 | Zero Trust requires continuous access removal when trust changes or ends. |
Verify every offboarding step removes access, credentials, and residual dependencies.
Related resources from NHI Mgmt Group
- Should organisations include ownership checks in offboarding workflows?
- How should security teams handle SaaS offboarding when non-human identities are involved?
- What is the difference between SSO offboarding and full SaaS lifecycle revocation?
- How should security teams handle SaaS offboarding when users also use AI tools?
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
