They create risk because their access may predate the current lifecycle model and still live in persistent metadata rather than the active token state. If the enforcement engine falls back to that metadata, revocation only touches part of the identity record. The device remains authorized even though the operator has completed the expected deprovisioning step.
Why legacy pairing becomes a revocation problem
Legacy paired devices are risky when the pairing relationship outlives the token model that now governs access. If the device still carries authorization in durable metadata, a revocation event can remove the active token while leaving the older pairing record intact. That creates a split-brain state where the operator believes access is gone, but the device can still be accepted on fallback paths.
The practical issue is not just stale data, it is stale authority. In environments that evolved from one pairing scheme to another, revocation may only touch the newest control plane while older records remain trusted for compatibility. That is why “revoked” does not always mean “fully deauthorized” when multiple identity stores or lifecycle states are still in play.
For teams managing paired-device access, the real question is whether the enforcement path is token-centric or record-centric. If the token is treated as the source of truth, revocation is usually effective. If the device can authenticate through persisted pairing metadata, deprovisioning becomes partial unless the legacy association is explicitly removed as well.
Where the revocation gap comes from
This failure usually appears after a lifecycle change: a new token format, a new authorization service, or a migration from device pairing to token tracking. Old pairings are often preserved for compatibility, auditability, or user convenience. Over time, those records become hidden fallback credentials, especially when the platform uses them to infer trust after the modern token has expired or been revoked.
The gap widens when different systems own different pieces of the access state. One service may revoke the token, another may retain the pairing record, and a third may continue to accept either one. Resource Indicators for OAuth 2.0 and OAuth 2.0 DPoP show the broader principle: access decisions are safer when tokens are tightly bound to their intended use and cannot be replayed outside the current trust context.
Legacy pairs also tend to fail revocation in edge cases such as offline devices, cached entitlements, delayed sync, or manual exception handling. The result is an access path that survives the intended lifecycle step because the platform treated revocation as a token event, not an identity record cleanup.
How to tell when revocation is incomplete
The strongest warning sign is when a device remains accepted after the operator has completed the expected deprovisioning workflow. That can happen even without obvious compromise, because the trust problem lives in state consistency rather than in attacker activity. If the device continues to authenticate through an older association, the revocation process has not fully matched the actual enforcement model.
Look for mismatches between token revocation logs, device inventory, and the authorization decisions seen at runtime. If the logs show token removal but the device still reaches protected resources, the paired-device metadata is likely still authoritative somewhere in the path. In that situation, the correct response is to search for every place the legacy association can be accepted, not just the primary token store.
Operationally, this is similar to other lifecycle mismatches seen in secret and token management, where the nominal control was completed but a secondary credential path still remained active. Guide to the Secret Sprawl Challenge and Token and Session Security Guide are useful anchors for the underlying pattern: lifecycle controls only work when every live access path is actually covered.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Revocation risk centers on lifecycle control of device authenticators and fallback access paths. |
| AC-2 — Account Management | Paired-device authorization must be removed across the full identity lifecycle, not only the current token. | |
| Recommendation — Revoke every authenticator and legacy association when a paired device is decommissioned. Synchronize account and device deprovisioning so old pair records cannot preserve access. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Legacy pairing that survives token revocation is an offboarding failure for non-human access. |
| NHI-07 — Long-Lived Secrets | Persistent pairing metadata behaves like durable access material that outlives intended lifecycle bounds. | |
| NHI-09 — NHI Reuse | Fallback acceptance of old pairing state is reuse of prior identity material after a lifecycle change. | |
| Recommendation — Ensure offboarding deletes every device association, not just the active token. Replace persistent access state with short-lived, explicitly revoked credentials. Eliminate legacy reuse paths when a new token-tracking model becomes authoritative. | ||
Practitioner Guidance
What to verify: Confirm which object the platform uses as the source of truth for revocation, then test whether removing the current token also removes any older pairing record. A good validation is simple: after deprovisioning, the device should fail both primary authentication and any legacy fallback path.
Decision rule: If a paired device can still be accepted after token revocation, treat the legacy pair as an active credential path, not as stale history. Revoke or delete the pairing state explicitly before assuming the access has been removed.
What practitioners underestimate: Compatibility logic often survives longer than the token model that replaced it, which means the hidden risk is not only compromise, but false confidence in deprovisioning. The safer operational posture is to require one authoritative revocation action that closes every accepted path, not just the newest one.
Practitioner takeaway: Revocation is only real when it removes every authoritative representation of access, including legacy pairing metadata that an enforcement engine might still trust.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org