Who is accountable when access is approved for removal but not actually revoked?

Why This Matters for Security Teams

When approval says “remove access” but the target system still permits it, the control has failed at the point that matters most: enforcement. Security teams often treat certification, ticket closure, and deprovisioning as the same event, but they are separate steps with separate failure modes. That gap is where excessive privilege persists, audit evidence becomes misleading, and attackers retain a live path even after a formal decision.

This is especially important for non-human identities, where access sprawl is common and offboarding is often incomplete. NHIMG’s Ultimate Guide to NHIs reports that only 20% of organisations have formal processes for offboarding and revoking API keys, which explains why “approved” removals frequently do not translate into actual revocation. The control problem is not the decision to remove access, but the closed-loop workflow that confirms removal in the destination system. Current guidance from the OWASP Non-Human Identity Top 10 aligns with this view: governance must include lifecycle enforcement, not just administrative approval.

In practice, many security teams discover the gap only after an audit exception, a failed offboarding check, or an incident investigation, rather than through intentional verification.

How It Works in Practice

Accountability should sit with the owner of the workflow that is supposed to produce the final state change, because that owner is the only party positioned to prove the revocation actually happened. In a healthy process, approval triggers a change event, the target system executes it, and the result is verified before the workflow is marked complete. If any of those steps are manual, the system should treat the task as open until evidence shows the credential, token, role, or service account is no longer usable.

For human access, this usually means tying certification outputs to IAM or PAM enforcement. For NHIs, it often means revoking API keys, disabling service accounts, rotating shared secrets, and confirming downstream integrations no longer authenticate. NHIMG’s NHI Lifecycle Management Guide is useful here because lifecycle control only works when provisioning, rotation, and offboarding are linked. The operational standard should be “closed loop,” not “ticket closed.”

• Approval owner: confirms the decision to remove access.
• Workflow owner: ensures the revocation action is executed.
• Target-system owner: exposes a verifiable API, event, or log showing the change.
• Control owner: checks that evidence matches the approved intent.

Best practice is evolving toward automated reconciliation, where access reviews are compared against actual entitlements and stale permissions are flagged when the target state does not match the approved state. This aligns with the OWASP Non-Human Identity Top 10 and NHI governance guidance from NHIMG, because both emphasise that exposure exists until credentials are actually invalidated. These controls tend to break down when revocation depends on manual tickets across multiple SaaS and cloud systems because no single owner can reliably verify the final state.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance speed against assurance. That tradeoff becomes visible when access is embedded in third-party platforms, delegated admin consoles, or legacy systems that cannot provide immediate proof of removal. Current guidance suggests treating those exceptions as higher risk, not as acceptable completion criteria.

One common edge case is shared or inherited access, where removing one approval does not actually revoke the underlying credential. Another is delayed propagation: a workflow may disable access in the identity provider, but cached sessions, tokens, or downstream replicas remain valid for a period of time. The Guide to the Secret Sprawl Challenge is relevant because scattered credentials and inconsistent ownership make closure hard to prove. The same issue appears in organisations that still rely on batch jobs or informal follow-up to complete revocation.

Where controls are strongest, the accountable owner must be able to answer three questions: what was approved, what was changed, and what evidence proves the target system now denies access. When that evidence is missing, the approval record is not a completed control, only an intention. In high-volume NHI environments, that distinction matters because stale credentials are often discovered only after exposure has already been exploited.

Related resources from NHI Mgmt Group

• How do security teams know whether cloud access policy is actually working?
• How do IAM teams know if privileged access controls are actually working?
• Who is accountable when offboarding leaves access behind?
• Who is accountable when access workflows sit in ITSM but enforcement sits elsewhere?