Who is accountable when an incident is caused by delayed access revocation?

Why This Matters for Security Teams

Delayed access revocation turns a routine offboarding or privilege change into a control failure with real blast radius. The issue is not only who clicked to remove access, but who owned the policy, who operated the system, and who had evidence that removal happened on time. For identity-led environments, this often touches PAM, IAM, application ownership, and in modern estates, Non-Human Identity governance as well. NIST control guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control is not a single action, but a managed process that needs defined responsibility and auditability.

Security teams often miss that accountability is a governance question before it becomes an incident question. If revocation is delayed, the operational owner may be the first to detect the gap, but the root cause usually sits in weak ownership boundaries, manual handoffs, or unclear service-level expectations. In practice, many security teams encounter delayed revocation only after an insider misuse event, a terminated user login, or an exposed service credential has already been abused.

How It Works in Practice

Accountability should be split, but not diluted. The party that owns the access path is accountable for timely removal mechanics, while the governance function is accountable for defining revocation policy, escalation thresholds, and evidence requirements. Incident response can confirm exposure and contain it, but it should not be the default owner of the revocation lifecycle. That lifecycle is usually executed through IAM, PAM, HR-driven joiner-mover-leaver workflows, or application-specific administration.

In a mature operating model, the following responsibilities are usually distinguished:

• Policy ownership: defines when access must be removed, by whom, and within what time window.
• System ownership: implements revocation in the directory, vault, application, or cloud control plane.
• Exception handling: approves temporary continuation only with documented risk acceptance.
• Assurance: verifies that logs, tickets, and control evidence show the revocation actually occurred.

This becomes even more important for Non-Human Identities, where credentials, tokens, and service accounts may not be tied to a person. The OWASP Non-Human Identity Top 10 is useful here because it highlights how unmanaged secrets and weak lifecycle governance can leave access active long after the original business need has ended.

For organisations with autonomous tooling or agentic workflows, delayed revocation may also involve AI-enabled actions that continue after trust should have been withdrawn. Emerging guidance suggests that access revocation should be tested not only for human users, but also for API keys, delegated tokens, bot accounts, and agent permissions. These controls tend to break down when revocation depends on manual ticket closure across disconnected systems because the delay is created by the handoff, not the policy.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance speed against change risk and service continuity. That tradeoff matters because immediate removal is not always possible in critical production environments, especially where break-glass access, vendor support accounts, or regulated batch processes are involved.

Current guidance suggests three common edge cases need explicit treatment. First, emergency access may remain temporarily active after an incident, but only under a time-bound exception with retrospective review. Second, shared accounts complicate accountability because no single user can be cleanly revoked; in that case, governance should treat the account itself as the asset requiring enhanced monitoring and replacement. Third, non-human credentials often outlive the person or team that created them, so the revocation owner may be a platform team even when the business sponsor has already changed.

There is no universal standard for this yet across every environment, but the practical rule is consistent: if a team can delay revocation, it must also own the evidence, escalation path, and remediation deadline. The Anthropic first AI-orchestrated cyber espionage campaign report is a reminder that automated systems can be abused quickly when access is not withdrawn promptly, which raises the stakes for both human and machine identities.

Related resources from NHI Mgmt Group

• Who is accountable when privilege escalation in an application changes group membership or admin access?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?
• When do NHI access reviews create more value than a one-time cleanup?