Who is accountable when a device still has access after administrators believe it has been revoked?

Accountability sits with the owner of the authorisation model, because the control failed to define one authoritative source of effective access. In practice, that means IAM, platform, and engineering teams all need to verify which system is allowed to decide entitlement. If more than one state can grant access, ownership is already blurred.

Why This Matters for Security Teams

When a device still has access after administrators believe it has been revoked, the failure is usually not the revocation click itself. The real issue is that multiple systems may still treat different entitlement states as authoritative. That creates a blind spot in offboarding, incident response, and audit evidence, especially when service accounts, API keys, or device-bound credentials are involved. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them in the Ultimate Guide to NHIs.

This matters because access that appears revoked in one console can remain valid in another token issuer, cache, agent, or downstream platform. That is exactly the kind of control gap highlighted by the OWASP Non-Human Identity Top 10 and the NIST Cybersecurity Framework 2.0, both of which push teams toward traceable identity governance and clear ownership. In practice, many security teams encounter persistent access only after a compromise, a contractor exit, or a failed decommissioning audit has already exposed the mismatch between policy and reality.

How It Works in Practice

The accountable party is the owner of the authorisation model, because that owner must ensure there is one authoritative source of effective access. If IAM says the device is revoked but a platform cache, broker, certificate, or application still trusts a surviving token, then revocation was never fully enforced. Security teams should map the full access path: who issues the credential, where it is stored, what systems validate it, and what event actually terminates it.

For devices and non-human identities, best practice is to treat revocation as a lifecycle workflow rather than a single administrative action. The NHI Lifecycle Management Guide and the lifecycle processes for managing NHIs emphasise discovery, inventory, rotation, and offboarding as linked controls. In operational terms, teams should verify:

• which system is the source of truth for entitlement decisions
• whether cached sessions, tokens, or certificates outlive the revocation event
• who owns revocation confirmation across IAM, platform, and application layers
• whether logs prove effective access ended, not just that a ticket was closed

For higher-risk environments, current guidance suggests pairing revocation with short-lived credentials, policy checks at request time, and explicit post-revocation validation. That aligns with how the Static vs Dynamic Secrets guidance and the NIST AI 600-1 GenAI Profile both stress runtime control over static assumptions. These controls tend to break down when long-lived tokens are embedded in devices or automation because revocation cannot reliably reach every verifier before reuse.

Common Variations and Edge Cases

Tighter revocation control often increases operational overhead, requiring organisations to balance security assurance against uptime, device autonomy, and recovery speed. That tradeoff becomes visible in edge cases such as offline devices, cached credentials, and third-party managed endpoints, where immediate invalidation is not always technically possible. In those environments, the owner of the authorisation model still remains accountable, but the implementation may need compensating controls and clearer service-level expectations.

There is no universal standard for this yet, but current guidance suggests treating certificate revocation, token expiry, and local cache invalidation as separate problems. A device might be removed from IAM while still holding a valid session in a broker or MDM-managed application. That is why the Top 10 NHI Issues and the Guide to the Secret Sprawl Challenge are so relevant: the problem is usually not a missing revoke action, but hidden copies of authority. For regulated environments, teams should also align evidence capture with the control intent in the NIST Cybersecurity Framework 2.0.

When multiple teams can independently grant or preserve access, accountability is already diluted even if the incident is still being investigated.

Related resources from NHI Mgmt Group

• Who is accountable when a contractor still has privileged cloud access after departure?
• Who is accountable when third-party access remains active after the task is complete?
• Who is accountable when revoked sessions keep working after access should end?
• Who is accountable when a leaver still has SaaS access after offboarding?