Who is accountable when an inactive non-human identity is still present after business use has ended?

Why This Matters for Security Teams

An inactive NHI that still exists after business use has ended is not just a cleanup issue. It is a live access path, an audit failure, and a governance gap that can persist across applications, pipelines, and vendors. Accountability should sit with the identity owner and the operating team, but security leadership is accountable for proving that lifecycle controls actually work. NIST Cybersecurity Framework 2.0 treats identity governance as an ongoing discipline, not a one-time configuration, and the operational risk is well documented in NHI research from Ultimate Guide to NHIs and Top 10 NHI Issues.

This matters because inactive does not mean harmless. A dormant service account, API key, or workload token can still carry excessive privilege, and NHIs outnumber human identities by 25x to 50x in many enterprises, which makes manual cleanup unreliable. In practice, the question of accountability becomes urgent only after a missed offboarding event, an audit finding, or an incident trace reveals that the identity was never revoked.

How It Works in Practice

Accountability should be assigned through the identity lifecycle, not left to a vague security catch-all. The business owner or product owner decides when an NHI is no longer needed. The operating team, platform team, or DevOps owner enforces revocation, rotation, and removal from secrets stores, CI/CD systems, and vaults. Security, IAM, and governance functions set policy, define evidence requirements, and verify completion. Under NIST Cybersecurity Framework 2.0, that means aligning asset, access, and governance processes so decommissioning is measurable rather than assumed.

In practice, effective ownership usually includes:

• an explicit identity owner recorded at creation time
• an expiry or review date tied to the business purpose
• automated revocation when the workload, integration, or agent is retired
• evidence that secrets, certificates, and tokens were removed from all known stores
• periodic recertification for any NHI that remains active beyond its original purpose

For broader NHI lifecycle control, the guidance in the Ultimate Guide to NHIs and the breach patterns discussed in 52 NHI Breaches Analysis show that failed offboarding is usually not a single technical mistake. It is a handoff failure between the team that created the identity, the team that operated it, and the team that was supposed to prove it was retired. These controls tend to break down when identities are created inside automation pipelines without a named owner because no one feels responsible for their removal.

Common Variations and Edge Cases

Tighter lifecycle control often increases operational overhead, requiring organisations to balance revocation speed against release cadence, vendor dependency, and evidence collection. That tradeoff is real, especially when identities support long-running jobs, scheduled integrations, or third-party connections that cannot be shut down instantly.

Current guidance suggests a few common exceptions need special handling. Shared service accounts can blur accountability, but they still need a named business owner and a technical custodian. Third-party NHIs are especially risky because the external provider may keep credentials active after the internal use case ends. Break-glass accounts are different again: they should be tightly governed, documented, and reviewed separately rather than treated as ordinary operational identities. The JetBrains GitHub plugin token exposure and the Cisco DevHub NHI breach both reinforce how long-lived tokens and missed lifecycle controls can turn a forgotten identity into a material exposure.

There is no universal standard for every exception, but the safest pattern is to force an owner, an expiry condition, and a revocation path for every NHI. Where that cannot be done, the exception should be time-bound, approved, and reviewed as a formal risk decision, not an informal operational shortcut.

Related resources from NHI Mgmt Group

• Who is accountable when a non-human identity is over-privileged?
• Why do non-human identities complicate identity governance programmes?
• Who should own non-human identity lifecycle governance in practice?
• Who is accountable when a third-party integration keeps an NHI active after the business need ends?