What should be done with inactive NHIs?

Why Inactive NHIs Need a Formal Retirement Process

Inactive non-human identities are rarely harmless leftovers. In practice, dormant service accounts, API keys, and automation identities often retain broad access, linger in code and CI/CD, and become easy targets for reuse or compromise. NHI Management Group research shows that only 20% of organisations have formal processes for offboarding and revoking API keys, while 91.6% of secrets remain valid five days after notification, which is a clear sign that deletion without verification is not enough. See the Ultimate Guide to NHIs and the Top 10 NHI Issues for the lifecycle context behind that risk.

The goal is not just to remove access, but to retire identity safely so that teams can verify nothing still depends on it. That matters because every inactive NHI is still an identity object, and identity objects can be reactivated, impersonated, or discovered in overlooked integrations. NIST guidance on access governance reinforces the broader principle that access must be reviewed, reduced, and traceable over time, not assumed safe because it is quiet. For that reason, the cleanest answer is staged retirement, not instant deletion.

In practice, many security teams discover the risk only after a dormant identity has already been reused, rather than through a planned lifecycle review.

How to Retire an Inactive NHI Safely

The most reliable approach is to treat inactivity as a trigger for review, then move through disable, observe, and delete. Disable first so the identity cannot authenticate, but preserve the record, ownership history, and dependency context. That gives the team a rollback path if an application still relies on the account and helps preserve evidence for audit and incident review. When the question is how to handle inactive NHIs, this staged model is preferable to immediate deletion because hidden integrations are common and not always documented.

A practical workflow usually looks like this:

• Confirm the NHI owner, system, and purpose before any action.
• Disable credentials and revoke live tokens, but keep the identity object intact.
• Monitor for authentication attempts, API calls, pipeline failures, and unexpected job errors during a validation window.
• Resolve any dependency before deciding whether the NHI should be replaced, reissued, or permanently removed.
• Delete the identity only after validating that no service, job, or integration still needs it.

For implementation, use governance controls in NIST Cybersecurity Framework 2.0 to support access review, asset accountability, and recovery planning. Pair that with lifecycle and offboarding patterns described in the 52 NHI Breaches Analysis, which shows how often neglected identities persist in real environments. If the NHI is tied to automation, also ensure any linked secrets are revoked or rotated wherever they are stored, including vaults, config files, and CI/CD systems. These controls tend to break down in distributed microservice estates because ownership is fragmented and dependency mapping is incomplete.

When Deletion, Exceptions, and Recovery Windows Become Complicated

Tighter decommissioning often increases operational overhead, requiring organisations to balance security assurance against service continuity. That tradeoff is especially visible in environments with shared service accounts, legacy batch jobs, or vendor-managed integrations, where one identity may support multiple systems. Best practice is evolving here: there is no universal standard for the exact inactivity threshold, and 90 days is a reasonable review trigger rather than an automatic deletion rule for every case.

Some NHIs should be retained longer for evidence, audit, or incident reconstruction, especially when they are part of regulated workflows. Others should be replaced before retirement if the identity has become a brittle dependency. When an account has broad privileges, the risk of leaving it dormant is high, and NHI Management Group notes that 97% of NHIs carry excessive privileges, which makes inactive identities especially dangerous if they are later rediscovered or reactivated. In those cases, retirement should include credential revocation, permission removal, and documentation of the final decision so that the identity cannot be quietly restored.

Recovery windows are also important. If a disabled NHI still triggers alerts or breaks jobs, that is a signal to inspect the dependency chain, not to leave the identity enabled indefinitely. The right end state is a fully decommissioned identity with no standing permissions, no usable secrets, and a clear record of why it was removed. In practice, the hardest cases are not the identities that can be deleted immediately, but the ones embedded deeply enough that no one can yet prove what will fail.

Related resources from NHI Mgmt Group

• How do NHIs typically authenticate compared to human identities?
• Why are NHIs harder to govern than human identities?
• How many NHIs does a typical enterprise have?
• Where do NHIs typically exist in an enterprise environment?