Who is accountable when stale access is not revoked?

Why This Matters for Security Teams

Stale access is not just an administrative gap. It is a control failure that turns “temporary” access into standing privilege, often long after the original business need has ended. In NHI programs, the same problem appears with service accounts, API keys, certificates, and agent credentials that keep working because nobody owns the revocation step. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why stale access persists in production.

The accountability question matters because revocation failures rarely come from a single technical defect. They come from ambiguous ownership across identity governance, application teams, approvers, and platform administrators. Security teams often assume a ticketing workflow will close the loop, but if no one is measured on removal, access remains active by default. Current guidance from the OWASP Non-Human Identity Top 10 treats unmanaged NHI lifecycle controls as a core risk area, not a paperwork issue. In practice, many security teams encounter stale access only after a breach review, rather than through intentional recertification or offboarding.

How It Works in Practice

Accountability for stale access should be assigned at the point where access is granted and again where it is removed. That usually means the identity governance owner defines the policy, the application owner confirms whether access is still needed, and the access approver validates business justification. For NHIs, this also requires a named technical owner who can revoke keys, rotate secrets, disable certificates, or retire workload identities when the service is decommissioned.

Operationally, the most reliable pattern is to connect joiner-mover-leaver processes to non-human identity lifecycle management. A mature workflow usually includes:

• time-bound access reviews for service accounts, API keys, and agent credentials;
• JIT or short-lived credentials instead of long-lived static secrets where possible;
• automated revocation triggers tied to app deprecation, vendor offboarding, or account inactivity;
• evidence capture showing who approved, who owned, and who executed removal.

This aligns with the lifecycle focus described in NHI Lifecycle Management Guide and the control emphasis in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs. It also matches the OWASP principle that access must be continuously validated, not assumed valid after issuance. Where teams need a broader control model, CISA Zero Trust Maturity Model supports this by pushing organisations toward continuous verification and reduced standing access. These controls tend to break down in federated SaaS environments because revocation dependencies span multiple admins, tenants, and token stores.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance faster removal against the risk of interrupting legitimate automation. That tradeoff is especially visible when the “owner” is a shared platform team rather than a single application team. Best practice is evolving, but there is no universal standard for this yet: some organisations assign revocation to the system owner, while others treat identity governance as the final accountable function when the app team cannot act.

Edge cases usually appear when access is embedded in CI/CD pipelines, third-party integrations, or unmanaged scripts. In those environments, a human approver may sign off on access, but the actual removal path sits elsewhere in code, infrastructure, or vendor tooling. That is why stale access must be tracked as both a governance issue and a technical dependency issue. The Guide to the Secret Sprawl Challenge is useful here because it shows how credentials persist outside normal review cycles. For measurement, NHIMG’s 52 NHI Breaches Analysis is a practical reminder that compromise often follows weak lifecycle discipline rather than a single missed approval.

Where ownership is still unclear, current guidance suggests treating revocation as an accountable control, not a courtesy task. If no named owner can prove removal, the access should be considered unresolved.

Related resources from NHI Mgmt Group

• Who is accountable when orphaned accounts or stale access contribute to a breach?
• Who is accountable when third-party access stays active too long?
• How should teams handle stale Active Directory objects before access reviews?
• Who should be accountable when sensitive data exposure is found through privileged access?