What breaks when access revocation is handled in separate systems?

Why This Matters for Security Teams

When revocation lives in separate systems, the security problem is not just latency. It is state divergence. Identity governance may mark access as removed while an application, SaaS tenant, API gateway, or group cache still honors the old entitlement. That gap turns offboarding into a partial control, especially for NHIs where service accounts, tokens, and keys often outlive the workflow that created them. NHI Mgmt Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which helps explain why revocation failures remain a recurring audit and breach theme in the Ultimate Guide to NHIs.

Security teams also underestimate how often the “source of truth” problem becomes an evidence problem. If one system says access ended but another still shows active rights, auditors cannot reliably verify when privilege actually disappeared. The OWASP Non-Human Identity Top 10 treats lifecycle control as a core risk area because the blast radius of stale access grows quickly once credentials, secrets, and group memberships drift out of sync. In practice, many security teams encounter the failure only after an incident review exposes that revocation was “completed” in one console but never propagated everywhere else.

How It Works in Practice

Revocation works best when it is treated as a single lifecycle event, not a set of disconnected tickets. The practical goal is to make one authoritative decision trigger every dependent control: directory removal, token invalidation, secret rotation, session termination, group membership updates, and downstream entitlement cleanup. For human access this may involve SCIM, IdP workflows, and PAM. For NHIs it often requires stronger automation because machines do not self-correct and often continue using cached credentials until expiry.

Current guidance suggests four design principles:

• Use one source of truth for entitlement state, then push changes outward through governed connectors.
• Prefer short-lived credentials and explicit TTLs so revocation is reinforced by expiration, not dependent on perfect propagation.
• Invalidate sessions and rotate secrets where immediate revocation is not technically supported.
• Log the full chain of revocation actions so audit evidence shows when access ended in each system.

This is especially important for environments with service accounts, CI/CD runners, SaaS app roles, and federated trust relationships. NHI governance guidance from 52 NHI Breaches Analysis shows that compromised or stale machine access often persists because one dependency was missed during offboarding. The operational lesson aligns with broader identity guidance in the OWASP Non-Human Identity Top 10: revocation is only real when the last effective path to access is closed. These controls tend to break down when legacy applications cache entitlements locally because there is no reliable event listener or API to force immediate enforcement.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance security certainty against integration complexity. There is no universal standard for this yet, especially in mixed estates where some systems support instant revocation and others only support delayed expiry or manual cleanup.

One common edge case is delegated administration. A directory may revoke access correctly, but a platform-specific admin role can still recreate entitlements or reissue tokens unless that privilege path is also removed. Another is third-party SaaS, where SCIM or API revocation may be available, but only for a subset of roles or tenants. In those cases, best practice is evolving toward layered controls: revoke centrally, rotate immediately, then verify downstream state with reconciliation jobs. The NHI Mgmt Group guidance in the Ultimate Guide to NHIs — Key Challenges and Risks is clear that visibility gaps make these exceptions harder to detect than to prevent.

Another subtle failure mode appears with agentic or automated workloads that keep operating after a policy change because they have cached credentials or queued tasks. That is why revocation must be paired with short-lived secrets and runtime enforcement, not treated as a one-time administrative action. In environments with offline clients, asynchronous jobs, or disconnected SaaS tenants, revocation can degrade into eventual consistency rather than immediate access removal.

Related resources from NHI Mgmt Group

• What breaks when discovery tools only report assets and not access?
• What breaks when unmanaged devices can still access business apps?
• When should teams prioritise access revocation over device lockdown?
• Why do ticketing systems fail as access governance controls?