Who is accountable when revocation is incomplete across systems?

Why This Matters for Security Teams

When revocation is incomplete, accountability is not a narrow IAM question. It is a control ownership problem that cuts across identity providers, directories, apps, APIs, vaults, CI/CD, and downstream service accounts. Security teams often assume that a successful disable action in one system equals effective offboarding everywhere, but residual access is what attackers exploit after the “official” revocation is done. NHI Mgmt Group’s Ultimate Guide to NHIs notes that only 20% of organisations have formal processes for offboarding and revoking API keys, which is a strong indicator that ownership is usually fragmented.

The practical issue is that revocation spans multiple control planes, so the accountable party must define what “complete” means, which systems are in scope, and how success is validated. That expectation aligns with the governance intent in the NIST Cybersecurity Framework 2.0, where identity lifecycle outcomes must be measurable rather than assumed.

In practice, many security teams encounter stale access only after an incident review reveals that one system was cleaned up while another quietly retained privilege.

How It Works in Practice

Accountability should be assigned to the governance owner who controls lifecycle policy, not only to the operator who clicks revoke. That owner is responsible for defining the revocation scope, the systems that must be checked, and the validation evidence required before closure. In mature programs, this is documented as an offboarding standard that covers identity providers, application entitlements, secrets stores, CI/CD variables, delegated tokens, certificates, and any service accounts created by automation.

The operational model usually has three parts:

• Trigger: an event such as termination, workflow completion, key compromise, or workload decommissioning.
• Propagation: revocation or rotation requests sent to every connected system that can issue or cache credentials.
• Verification: a post-revocation check that proves no usable access remains, rather than assuming the first system succeeded.

This is where NHI governance becomes essential. NHI Mgmt Group’s Ultimate Guide to NHIs highlights how widespread weak offboarding is, which is why validation should be built into the control itself. The NIST Cybersecurity Framework 2.0 is helpful here because it treats identity and access as an operational discipline, not a one-time administrative task.

Practically, teams should require an owner for each credential domain, a system inventory for every place access may persist, and an evidence trail showing what was revoked, when, and where confirmation was obtained. These controls tend to break down in SaaS-heavy environments with shadow integrations and vendor-managed accounts because no single team can see every place access is cached or replicated.

Common Variations and Edge Cases

Tighter revocation controls often increase coordination overhead, requiring organisations to balance speed against certainty. In some environments, especially M&A integrations or heavily automated platform stacks, complete revocation may lag because inherited directories, legacy apps, and third-party connectors do not respond to the same control plane.

There is no universal standard for this yet, but current guidance suggests the accountability model should change with the risk surface. For human joiner-mover-leaver events, HR-triggered workflows may be enough for basic accounts. For NHIs, privileged service accounts, and API keys, governance owners need stricter closure criteria because residual access can survive in code, secrets managers, and CI/CD systems long after the primary identity is disabled.

This is also where accountability becomes shared but not diluted. Operators execute the revocation task, platform owners maintain the connected systems, and governance owners define the rule that the task is not complete until verification succeeds everywhere in scope. If that final validation step is missing, the organisation has not completed revocation, only initiated it. That distinction matters most when a secret is copied into a pipeline or external integration that the main identity system cannot automatically inspect.

Related resources from NHI Mgmt Group

• How should retail organisations govern access across stores, devices, and POS systems?
• Who should be accountable for sensitive retail systems and audit trails?
• How should security teams make NHI best practices usable across the business?
• How can organizations manage unauthorized agents in their systems?