The governed retirement of a non-human identity, including revocation of access, removal of dependencies, and confirmation that the identity is no longer needed. It is a lifecycle control, not a cleanup task, because the goal is to end access safely and accountably.
What NHI Decommissioning Includes
NHI decommissioning is more than disabling an account, it is the controlled end of a non-human identity’s authority. It typically includes confirming the identity is no longer needed, revoking active access, and retiring the credential material tied to it.
The key distinction is that decommissioning is a lifecycle decision, not a cleanup activity. A proper decommissioning process treats the identity as an asset with dependencies, owners, and downstream services that may still rely on it.
Why Decommissioning Matters to Access Governance
Non-human identities often accumulate long-lived access, embedded credentials, and undocumented integrations. Without a deliberate retirement process, those identities can outlive their business purpose and remain able to authenticate even after the service they supported has changed or disappeared.
That is why decommissioning sits alongside ownership, inventory, and lifecycle control in identity governance. NHIMG’s NHI Lifecycle Management Guide and NHI Ownership and Accountability Guide both reinforce that retirement should be handled as a governed state change, not an informal cleanup task.
For broader context on how lifecycle, governance, and offboarding fit together across machine identities, see the Lifecycle Processes for Managing NHIs section and the overview of non-human identities.
Common Failure Modes During Retirement
Decommissioning fails when teams remove the obvious login but miss the less visible dependencies. Examples include service tokens still stored in pipelines, certificates still trusted by downstream systems, shared credentials reused elsewhere, or orphaned automation that continues to call the retired identity.
Another failure mode is partial retirement, where access is revoked but the identity remains discoverable, owned, or reactivated later. That creates ambiguity about whether the identity is truly dead or merely dormant, which weakens auditability and increases the chance of accidental reuse.
NHIMG’s Top 10 NHI Issues and Key Challenges and Risks sections both highlight the broader pattern: incomplete inventory, excess privilege, and unmanaged credentials are usually what make decommissioning unreliable.
What Good Decommissioning Proves
A complete decommissioning outcome proves three things: the identity is no longer required, its access has been revoked, and its dependencies have been removed or safely transferred. In practice, that means the organisation can explain who approved the retirement, what was turned off, and what evidence shows the identity cannot be used again.
This makes decommissioning a control point for both security and accountability. It closes the loop on the identity lifecycle by tying ownership, authorization, and credential retirement into one governed event rather than treating each step separately.
For teams managing service accounts and automation at scale, the Service Account Security Guide is a useful companion for understanding how retirement should line up with least privilege and governance.
Risk and Threat Considerations
Undecommissioned non-human identities are a durable source of exposure because they preserve valid access after the business need has ended. Attackers and opportunistic insiders both benefit from forgotten identities, especially where credentials are long-lived, reuse is common, or downstream dependencies are poorly tracked.
Failure mechanism: Access remains active because the retirement process did not fully revoke credentials, remove trust relationships, or identify every system still able to use the identity.
Impact: The organisation retains an unnecessary attack path that can enable unauthorized access, persistence, lateral movement, or unexpected service interactions long after the identity should have been gone.
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 surface, NIST SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Decommissioning ends the lifecycle of authenticators and secrets tied to the identity. |
| AC-2 — Account Management | Decommissioning is the account retirement step that removes an identity from active use. | |
| IA-9 — Service Identification and Authentication | NHI retirement often requires ending machine-to-machine trust and service authentication paths. | |
| Recommendation — Retire authenticators and invalidate credentials when the NHI is decommissioned. Disable or remove the account and confirm the retirement is fully recorded. Revoke service authentication paths and trusted relationships tied to the retired NHI. | ||
| NIST CSF 2.0 | PR.AA-05 — Managed Access Control | Decommissioning materially depends on removing access paths and privileges. |
| Recommendation — Remove access rights and confirm the retired identity no longer has operational access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The term directly describes safe offboarding and retirement of a non-human identity. |
| NHI-07 — Long-Lived Secrets | Decommissioning must eliminate credentials that would otherwise remain usable after retirement. | |
| NHI-05 — Overprivileged NHI | Retirement reduces standing access that would otherwise persist beyond need. | |
| Recommendation — Use formal offboarding to revoke access, retire secrets, and close dependencies. Eliminate long-lived secrets and replace them with credentials that can be retired cleanly. Remove excess privileges before retirement so the identity cannot continue to access beyond purpose. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud identity lifecycle governance includes timely offboarding and access removal. |
| Recommendation — Apply IAM lifecycle controls to retire cloud identities and their access dependencies. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity retirement is part of managed identity lifecycle and ownership control. |
| Recommendation — Maintain identity records so retirement actions can be authorised and verified. | ||
Practitioner Guidance
Governance implication: Treat decommissioning as a formal lifecycle event with an owner, an approval trail, and a verification step. The practical test is not whether the account was disabled, but whether the identity, its secrets, and its dependencies were fully retired without breaking legitimate services.
Practitioner takeaway: If you cannot prove the identity cannot still authenticate or be called by another system, it has not really been decommissioned.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org