Who should own revocation when identity trust changes?

Why This Matters for Security Teams

Revocation ownership is not a paperwork issue. It is a control point that determines whether trust decisions can be reversed before an identity is abused. When an organisation accepts an identity from an internal directory, a partner, a workforce platform, or an external verifier, it also inherits responsibility for deciding who can invalidate that trust and how quickly dependent systems must respond. That aligns with the governance and recovery expectations in the NIST Cybersecurity Framework 2.0.

The practical risk is that revocation is often assumed to be automatic when it is actually distributed across identity providers, application caches, tokens, session stores, and downstream authorisation layers. If ownership is not explicit, each system tends to treat the change as someone else’s job. That creates a gap between the moment trust is withdrawn and the moment enforcement actually changes. For NHI, agent identities, and high-risk human identities, that gap can expose privileged actions, automated transactions, or sensitive data flows long after the original assurance has expired.

In practice, many security teams discover revocation failures only after a deprovisioning event, compromise, or assurance downgrade has already been exploited, rather than through intentional testing of the revocation path.

How It Works in Practice

Effective revocation starts with a clear ownership model. The relying organisation should define the trust policy, the revocation authority, the required evidence for invalidation, and the maximum time allowed for enforcement. That means distinguishing between who can request revocation, who approves it, who executes it, and who verifies that downstream systems have processed it. In many environments, those are separate roles.

Operationally, revocation should cover more than account disablement. It may include certificate revocation, token invalidation, session termination, key rotation, removal from access groups, and suppression of API credentials or service accounts. For digital identity and assurance-heavy flows, NIST SP 800-63 Digital Identity Guidelines is useful for thinking about assurance, proofing, and identity lifecycle effects, while implementations often rely on event-driven signals rather than a single universal switch.

• Define a single system of record for revocation decisions, even if enforcement is distributed.
• Set revocation time objectives for critical identity types, especially privileged users, partners, and NHI.
• Ensure downstream systems can consume revocation events, not just periodic recertification reports.
• Test whether cached tokens, long-lived sessions, and offline trust stores actually honour the decision.
• Log who revoked, what evidence triggered it, when it propagated, and which systems confirmed receipt.

For machine-to-machine access, the ownership question becomes sharper because secrets, certificates, and workload identities often outlive the human process that created them. The Zero Trust Architecture model reinforces the need to continuously re-evaluate trust instead of assuming a one-time approval remains valid. These controls tend to break down when identity data is replicated into unmanaged SaaS apps, partner-managed directories, or offline edge environments because revocation signals cannot reach every relying system fast enough.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance rapid trust withdrawal against availability, integration cost, and business continuity.

There is no universal standard for this yet across every trust model. In federated identity, the identity provider may execute the technical change, but the relying party still owns the decision to accept or reject the identity. In delegated admin models, the business owner may approve revocation while a platform team performs the technical action. For NHI, ownership can sit with the application team, the platform engineering function, or a central IAM team, depending on who controls the secret or certificate lifecycle.

Edge cases matter. Emergency revocation for suspected compromise should be faster and broader than routine offboarding. Shared accounts and service principals need special handling because one revocation decision can affect multiple workloads. In partner or customer identity scenarios, organisations should document whether revocation means immediate denial, graceful expiry, or step-up verification on the next transaction. Guidance suggests that the most defensible model is the one that can prove both the decision and the propagation path, not just the original approval.

For regulated environments, mapping revocation ownership into access governance and monitoring is essential. The question is not only who can act, but also who is accountable when a revoked identity continues to function. That distinction becomes critical when trust changes occur under incident response pressure.

Related resources from NHI Mgmt Group

• Who should own microsegmentation decisions in a zero trust programme?
• How should security teams govern access changes across hybrid identity environments?
• Who should own digital identity governance in customer onboarding?
• Why do identity configuration changes need more governance than standard infrastructure changes?