How can organisations prove that revoked access is really gone?

Why This Matters for Security Teams

Proving that revoked access is actually gone is not the same as marking a review complete. The real risk sits in downstream systems, cached entitlements, replicated directories, API keys, and service accounts that remain effective after a ticket is closed. That gap is especially dangerous for non-human identities, where access is often distributed across apps, pipelines, and secrets stores rather than one central directory. 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 closure without verification is a weak control.

Security teams usually get this wrong when they treat revocation as a paperwork event instead of an observable state change. A reviewer may remove access in IAM, but the entitlement can still persist in a vault, SaaS app, CI/CD secret, or delegated token chain. Current guidance suggests the control must confirm the post-change state, not just the request outcome. That is also consistent with the OWASP Non-Human Identity Top 10 and NIST SP 800-53 Rev. 5 emphasis on access enforcement and verification. In practice, many security teams discover residual access only after a service account has already been used again, rather than through intentional closure checks.

How It Works in Practice

The strongest pattern is a closed-loop revocation control: remove the entitlement, query the authoritative inventory or graph, and compare the expected state to the observed state before closure is allowed. For NHIs, that means checking more than one location because the identity may have active access through credentials, tokens, certificates, role bindings, or inherited group membership. NHI Mgmt Group’s NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both reinforce that lifecycle state must be measurable, not assumed.

A practical implementation usually includes:

• an authoritative entitlement source, such as an access graph or identity inventory
• revocation actions for each downstream system that can enforce access independently
• a validation step that confirms the privilege is no longer effective
• exception handling for asynchronous systems that may need polling or delayed verification
• closure gates that block ticket completion until the control evidence is attached

This is particularly important when secrets are involved. A deleted role does not matter if the token, API key, or certificate is still valid elsewhere. For that reason, the “revoked” state should be checked against the actual enforcement point, not only against the workflow that initiated the change. Guidance from Static vs Dynamic Secrets and the OWASP Non-Human Identity Top 10 aligns with this approach because long-lived credentials are harder to validate and easier to miss.

These controls tend to break down in federated environments with delayed sync, unmanaged SaaS permissions, or shadow secret stores because the enforcement point is not under the same administrative control as the review system.

Common Variations and Edge Cases

Tighter revocation verification often increases operational overhead, requiring organisations to balance stronger assurance against system latency and integration cost. That tradeoff is real, especially where dozens of downstream systems must confirm removal independently. Best practice is evolving, but there is no universal standard for how many confirmation layers are enough.

Some environments can rely on near-real-time validation, while others need batch checks, delayed re-querying, or compensating controls for systems that do not expose usable APIs. Privileged and non-human identities are the hardest cases because access can persist through nested groups, cached sessions, or externally managed secrets. The NHI Mgmt Group Guide to the Secret Sprawl Challenge highlights why scattered credentials make this verification problem worse, not better.

In practice, organisations should treat edge cases as control design inputs: define which systems are authoritative, which are evidence-only, and which require manual attestation when automation cannot prove removal. Where revocation touches critical services, a second-party check or short observation window can be justified. That said, this should not become a loophole for permanent exceptions. A revoked entitlement that cannot be proven absent is still an open access path, even if the review record says otherwise.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• How should security teams decide whether JIT access is safe for non-human identities?
• What is the difference between JIT access and Zero Trust for NHIs?
• How can organisations reduce secret leakage in ServiceNow at scale?