Revocation becomes incomplete, because the platform can report success while persistent roles still grant access from a fallback record. That leaves administrators with a false assurance that the device is disabled. The practical failure is not the revoke action itself, but the existence of another authorisation source that remains in effect after the control has run.
Why This Matters for Security Teams
When revocation only touches token state, the control can appear to work while a second authorisation path still exists in a legacy device record, directory object, or fallback entitlement. That creates a dangerous gap between incident response intent and actual access removal. NHI teams see this most often in hybrid estates where old device registrations, cached trust relationships, or synchronised identity records were never designed to be the last word on access.
The result is not just delayed cleanup. It is a false negative from the security platform, because the revoke action completes but the identity remains viable elsewhere. The same pattern shows up in long-lived credentials and stale NHIs, which is why lifecycle discipline matters as much as detection. NIST Cybersecurity Framework 2.0 emphasises continuous identity and access management rather than one-time state changes, and NHIMG research on the Guide to the Secret Sprawl Challenge shows how duplicated trust material persists after teams believe it has been removed.
In practice, many security teams discover the second authorisation source only after a supposedly revoked device is used again from a fallback record, rather than through intentional validation.
How It Works in Practice
Effective revocation has to be identity-wide, not token-only. A device or NHI may be represented by several objects: an access token, a device registration, a certificate, a local cache entry, and an administrative record in an MDM, IAM, or directory service. If the platform clears only the token state, the remaining record can still satisfy a trust check and reissue access or permit session renewal.
That is why practitioners increasingly treat revocation as a coordinated workflow: identify every authoritative source, revoke each one, invalidate cached sessions, and confirm that no secondary path can mint fresh credentials. The operational model is similar to the lessons in the Cisco Active Directory credentials breach and the Salesloft OAuth token breach, where exposed or stale trust material mattered because the surrounding identity state was still usable.
Current guidance suggests four practical steps:
- Map every control plane that can assert identity, including device records, token services, certificates, and synchronised directories.
- Revoke at the source of authority, not just at the presentation layer.
- Use short-lived credentials and explicit TTLs so old state expires quickly even if cleanup fails.
- Verify revocation with a negative test: confirm that no token refresh, login, or device assertion still succeeds.
This is especially important for NHI environments where the same workload identity may be reused across automation, CI/CD, or managed endpoints. NHIMG’s 2025 State of NHIs and Secrets in Cybersecurity found that 91% of former employee tokens remain active after offboarding, which is a strong signal that token lifecycle controls alone are not enough. These controls tend to break down when legacy device records are replicated across multiple identity systems because one system can continue to authorise what another has already revoked.
Common Variations and Edge Cases
Tighter revocation often increases operational overhead, requiring organisations to balance rapid access removal against the risk of breaking legitimate automation or service continuity. That tradeoff is real in federated estates, where a device record might be owned by one team, a token service by another, and session enforcement by a third.
There is no universal standard for this yet, but best practice is evolving toward explicit authorisation source inventories and revocation orchestration. In some environments, a legacy directory still acts as the hidden source of truth even after modern token systems are deployed, so revocation must include both modern and inherited trust paths. In others, mobile device management, endpoint certificates, or SSO session stores can re-establish trust after a token is revoked unless they are separately invalidated.
For security teams, the key question is not whether a revoke call returned success, but whether any remaining record can still authenticate, refresh, or rehydrate access. This is where stale mappings, duplicated secrets, and overused NHIs become material risk. NHIMG’s research on the State of Secrets Sprawl 2026 reinforces the point: detection without full lifecycle revocation leaves exploitable material in place long after teams believe it is gone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers stale or unrevoed non-human credentials that remain usable after cleanup. |
| NIST CSF 2.0 | PR.AC-4 | Access removal must cover all authoritative identity sources, not just tokens. |
| NIST AI RMF | Governance requires end-to-end lifecycle accountability across identity and access state. |
Define accountable owners for each auth source and test revocation across the full lifecycle.
