Decommissioning is the controlled retirement of an identity and its access when it is no longer needed. For non-human identities, it requires proof of ownership, usage, and dependency so removal does not disrupt production or leave hidden accounts active longer than intended.
Expanded Definition
Decommissioning is the lifecycle control that formally retires an NHI, its secrets, and any dependent automation once the identity no longer serves a business purpose. In practice, it is more than deleting an account; it includes confirming ownership, identifying downstream dependencies, revoking access, rotating or invalidating secrets, and preserving records for audit and incident response. The NIST NIST Cybersecurity Framework 2.0 treats this as part of disciplined asset and access management, while NHI governance frameworks extend that logic to machine identities that can be embedded in code, CI/CD pipelines, and cloud workloads.
Definitions vary across vendors on whether decommissioning begins at approval to retire or only after all tokens are disabled, so teams should state the trigger condition in policy. For agentic systems, the term also extends to disabling tool access and any delegated execution authority held by an AI Agent. The most common misapplication is treating decommissioning as a ticket to delete a username, which occurs when hidden service dependencies and long-lived secrets are not mapped first.
Examples and Use Cases
Implementing decommissioning rigorously often introduces coordination overhead, requiring organisations to balance fast shutdown of unused access against the risk of breaking production jobs, integrations, or audit evidence.
- A legacy API key is retired after a payment microservice is replaced, but only after the team confirms the key is not still referenced by a scheduled batch process and then validates the change against the guidance in the Ultimate Guide to NHIs.
- A CI/CD service account is decommissioned when a deployment pipeline is migrated, with secrets revoked first and rollback tested to avoid build failures in release windows.
- An abandoned cloud workload identity is removed after ownership is reassigned and logs are preserved for forensics, aligning with NIST Cybersecurity Framework 2.0 practices for controlled access termination.
- An AI Agent used for customer support is taken out of service, and its tool permissions are disabled before the model endpoint is shut down so no residual access remains.
- A third-party integration is sunset after contract end, with dependent secrets rotated because NHIMG research shows 91.6% of secrets remain valid five days after notification, exposing a dangerous delay in remediation.
Why It Matters in NHI Security
Decommissioning is a security control because inactive identities are still identities if they can authenticate, authorize, or expose secrets. Weak retirement practices leave shadow access behind, especially where ownership is unclear or identities were created for automation rather than people. NHIMG research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which helps explain why dormant access so often survives long after the workload has changed. The Ultimate Guide to NHIs also highlights how common secret sprawl and poor visibility make retirement difficult to verify.
For governance, decommissioning supports Zero Trust Architecture by removing unnecessary standing access rather than merely trusting that an old credential will not be used. It also reduces the blast radius of compromised accounts and improves incident containment when a forgotten integration is found during review. NHI management programs should treat retirement evidence as seriously as provisioning evidence, because the absence of an account record does not prove the absence of access. Organisations typically encounter the full consequence of poor decommissioning only after a breach review or failed audit exposes an inactive identity that was still valid, at which point the retirement process becomes operationally unavoidable.
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 Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-08 | Covers lifecycle cleanup and offboarding of non-human identities and their secrets. |
| NIST Zero Trust (SP 800-207) | 5.1 | Zero Trust requires removal of unnecessary standing access and continuous access reassessment. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access control practices include timely termination of access when no longer needed. |
Eliminate stale machine access as part of least-privilege, continuously verified access control.
