Who is accountable when access remains in place after it should have been removed?

Accountability should sit with the identity owner, the system owner, and the governance process that failed to enforce expiry or revocation. NIST Cybersecurity Framework 2.0 is useful here because it treats access control and governance as operational responsibilities, not one-time setup tasks.

Why This Matters for Security Teams

When access lingers after it should have been removed, the failure is rarely just technical. It is a governance break across identity ownership, system ownership, and revocation execution. That matters because stale access expands blast radius, weakens least privilege, and turns routine offboarding or role changes into hidden risk. Guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s broader research on Ultimate Guide to NHIs both point to the same operational reality: identities must be governed continuously, not assumed safe after provisioning. In practice, the organisation that owns the identity, the team that owns the system, and the process that failed to enforce expiry are all part of the accountability chain. NHIMG’s 52 NHI Breaches Analysis shows that identity failures often persist long enough to become incident drivers rather than policy exceptions. In practice, many security teams encounter stale access only after an audit, an incident, or a failed offboarding review has already exposed it.

How It Works in Practice

Accountability should be mapped to the control point where removal is supposed to happen and the control point where it is supposed to be verified. For human and non-human identities alike, that usually means three layers: the identity owner approves and tracks access necessity, the system owner enforces the entitlement model, and the governance process validates that expiry or revocation actually occurred. Current guidance suggests treating this as an operational workflow, not a one-time ticket closure.

A practical control model usually includes:

• Defined ownership for every identity, secret, token, or service account.
• Short-lived access with explicit expiry, especially where secrets or privileged roles are involved.
• Automated revocation checks that confirm removal from the target system, not just the identity source.
• Exception handling for break-glass or service continuity cases, with review timestamps and expiry.
• Evidence collection for audits, including who approved, who executed, and who verified closure.

This aligns with the operating model described in NIST Cybersecurity Framework 2.0 and the identity discipline recommended in the OWASP Non-Human Identity Top 10. It also fits NHIMG’s guidance in the Ultimate Guide to NHIs — Key Challenges and Risks, where unmanaged identity sprawl is treated as a recurring control failure rather than a single misconfiguration. For secrets-heavy environments, NHIMG research notes that organisations maintain an average of 6 distinct secrets manager instances, which fragments ownership and makes revocation harder to prove. These controls tend to break down when multiple platforms manage the same identity lifecycle because no single system can prove that access has been fully removed.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance assurance against service continuity. That tradeoff is most visible in systems that depend on shared service accounts, long-lived integrations, or emergency access paths. Current guidance suggests that accountability should not disappear in those cases, but the verification method may change.

Some edge cases need special handling:

• Shared accounts: ownership must be explicit, or revocation responsibility becomes ambiguous.
• Service accounts: removal may require dependency mapping before credentials can be invalidated safely.
• Break-glass access: temporary elevation is acceptable only if expiry and post-use review are enforced.
• Federated environments: removal may need to be confirmed across multiple directories or SaaS control planes.
• Agentic or automated workloads: if an agent continues to hold access after the task is complete, accountability should include the workflow owner and the policy engine that failed to revoke it.

Where consensus is still forming, the main question is not whether accountability exists, but how much of it can be delegated to automation. Best practice is evolving toward policy-driven expiry, runtime verification, and continuous attestation rather than manual cleanup. The NHIMG research page on DeepSeek breach reinforces why this matters: once credentials or access paths persist longer than intended, exposure can spread well beyond the original owner. In environments with many vendors, many directories, or frequent machine-to-machine access, accountability becomes hardest to prove precisely when it matters most.

Related resources from NHI Mgmt Group

• Who is accountable when vendor access remains active after a banking engagement ends?
• Who is accountable when access remains active after a mass exodus?
• Who is accountable when weak authentication remains in place after a regulatory update?
• Who is accountable when access remains after the business need ends?