Prioritise decommissioning first when identities are clearly dormant or no longer needed, because removing unnecessary access reduces exposure immediately. Prioritise rotation first when the identity is still active but the secret is old, privileged, or poorly controlled. The right order depends on whether the bigger issue is unnecessary existence or unsafe persistence.
How to decide whether decommissioning or rotation comes first
The sequence is driven by the state of the identity itself. If an NHI is no longer needed, decommissioning is the cleaner first move because it eliminates standing access, unused trust paths, and future maintenance burden in one step. If the identity is still required, rotation is the faster way to reduce secret exposure without breaking the underlying dependency.
The practical question is whether you are dealing with an unnecessary identity or an unsafe one. A dormant or ownerless account can often be removed with less operational risk than trying to preserve it through a rotation exercise, while a live integration may need credential refresh first so the service keeps working during the cleanup window.
For teams managing lifecycle at scale, NHI Lifecycle Management Guide is the clearest starting point because it treats provisioning, rotation, offboarding, and decommissioning as one governed lifecycle rather than isolated tasks.
Why decommissioning usually wins when the identity is dormant
Decommissioning first is usually the right answer when the NHI is stale, orphaned, duplicated, or attached to a process that no longer exists. In that state, rotation only preserves an access path that should be removed. The security gain from decommissioning is immediate: there is no credential left to steal, no secret to expire badly, and no future need to revisit the same identity.
This is also where ownership matters. If nobody can explain what the identity still supports, the risk is not just the secret, it is the unresolved business dependency behind it. That is why lifecycle cleanup should include confirmation that the identity has no hidden integrations before any attempt is made to keep it alive.
The broader NHI governance view is captured well in Top 10 NHI Issues and NHI Ownership and Accountability Guide, both of which reinforce that orphaned or unowned identities should be removed rather than left to persist.
When the identity is genuinely obsolete, decommissioning also avoids the common trap of “temporary” retention. Temporary access tends to become permanent when teams delay cleanup for operational convenience, which leaves stale secrets, overlooked permissions, and incomplete inventory records behind.
When rotation should happen before decommissioning
Rotation comes first when the identity is still in active use and the immediate concern is secret quality, not existence. That includes long-lived credentials, poorly controlled keys, suspected exposure, or privileged secrets with weak governance. In those cases, removing the identity first may create outage risk before the security exposure has been neutralised.
Rotation is also the safer bridge when you need time to map dependencies. A credential refresh can buy time to determine whether the integration is business-critical, whether it can be replaced, and whether decommissioning is truly safe. That is especially useful where the identity touches production systems, third-party services, or automation that is hard to repoint quickly.
Guide to NHI Rotation Challenges and Service Account Security Guide are useful references here because they focus on the operational friction that often makes active identities harder to rotate than teams expect.
For identities that authenticate through keys, certificates, or tokens, NIST SP 800-57 Key Management is the most relevant external reference because key lifecycle and cryptoperiod discipline drive the rotation decision when the secret itself is the problem.
Risk and Threat Considerations
The main risk is choosing the wrong order for the wrong condition. If you decommission a live identity too early, you can trigger outages, break downstream jobs, or lose visibility into a dependency that should have been remediated first. If you rotate a dead identity instead of removing it, you preserve unnecessary exposure and leave an exploitable access path in place.
Failure mechanism: Attackers and internal misuse alike benefit from stale, long-lived, or overprivileged secrets. A dormant identity that is never decommissioned can remain a persistent foothold, while an active identity with weak secret hygiene can be abused until rotation closes the window.
Impact: The result can be unauthorized access, privilege abuse, lateral movement, or avoidable operational disruption. In practice, the question is not just lifecycle hygiene, it is whether exposure comes from unnecessary existence or unsafe persistence.
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 and risk surface, while NIST SP 800-57, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | Key Management Recommendations | Covers secret lifecycle and cryptoperiod decisions that determine rotation timing. |
| Recommendation — Apply key lifecycle discipline to rotate live credentials before exposure grows. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Directly addresses management, rotation, and retirement of authenticators and secrets. |
| AC-2 — Account Management | Supports decommissioning and disabling identities that should no longer exist. | |
| Recommendation — Rotate compromised or aged authenticators and revoke those no longer needed. Disable and remove inactive accounts or service identities as soon as they are retired. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account lifecycle control covers removing dormant identities and reducing standing access. |
| Recommendation — Remove dormant accounts and periodically validate account necessity and ownership. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Directly maps to deciding when an NHI should be decommissioned rather than rotated. |
| NHI-07 — Long-Lived Secrets | Directly addresses when rotation is needed to reduce exposure from persistent secrets. | |
| Recommendation — Offboard unused NHIs promptly and verify their access paths are fully removed. Replace long-lived secrets with shorter-lived credentials and enforce timely rotation. | ||
Practitioner Guidance
Decision rule: If the identity has no current business purpose, remove it first and then confirm that the cleanup did not expose an undocumented dependency. If the identity is still needed, rotate first, then schedule decommissioning only after the dependency has been proven removable or replaced.
What to verify: Before decommissioning, verify ownership, last use, dependent systems, and rollback options. Before rotation, verify that the new secret can be deployed everywhere the old one is trusted, otherwise you risk partial failure that looks like a security fix but functions like an outage.
What good looks like: Mature teams treat decommissioning and rotation as linked lifecycle controls, not competing actions. They remove identities that no longer serve a purpose, rotate the ones that must stay live, and keep enough inventory fidelity to distinguish the two quickly.
Practitioner takeaway: The deciding factor is whether the identity should exist at all. If it should not, decommission it; if it should, make the existing secret safer first.