Who should own refresh-token revocation when access changes?

Why This Matters for Security Teams

Refresh-token revocation sits at the boundary between identity governance and application runtime control, which is why ownership disputes create real exposure. If the identity team only manages issuance, and the application team treats revocation as someone else’s problem, stale sessions can survive offboarding, policy changes, and consent withdrawal. That gap is especially dangerous for long-lived refresh token, because they quietly preserve access long after an access review says otherwise. The OWASP Non-Human Identity Top 10 treats lifecycle control as a core weakness, not an edge case.

NHIMG research shows how often lifecycle failures become incidents after the fact: the 2025 State of NHIs and Secrets in Cybersecurity reports that 91% of former employee tokens remain active after offboarding. That is a strong indicator that revocation is not reliably executed as part of authorization change management. In practice, many security teams encounter token persistence only after a user, service account, or integration has already kept working with permissions that should have been removed.

Ownership should therefore be shared, but not blurred: identity owners define the policy and trigger conditions, while application owners implement the actual revocation path and session enforcement. In practice, many security teams encounter refresh-token drift only after access has already been revoked on paper.

How It Works in Practice

Best practice is to treat refresh-token revocation as an authorization lifecycle event, not a cleanup task. When access changes, the system should invalidate the refresh token, block renewal, and force re-authentication or re-consent depending on the scenario. The identity plane owns the policy signal, while the application or authorization server owns enforcement. This is consistent with the broader lifecycle view in Ultimate Guide to NHIs, where credential validity must track the current trust state, not the last successful login.

In mature environments, this usually means:

• Offboarding events trigger immediate token revocation and session invalidation.
• Consent changes or scope reductions force token reissue under the new policy.
• Policy engines notify the authorization server when risk, role, or device context changes.
• Refresh tokens are short-lived enough that revocation gaps do not become durable access.
• Audit logs link the revocation decision to a clear owner and change ticket.

For implementations, current guidance suggests using standards-based token handling where possible, with RFC 7009 token revocation as a baseline for OAuth environments and OAuth 2.0 Security Best Current Practice for reducing token lifetime and replay risk. Revocation should be event-driven, not batch-driven, because access changes are usually immediate even if the underlying business process is not. These controls tend to break down when legacy applications cache sessions locally and do not call the authorization server on each renewal, because stale refresh tokens keep working outside central policy.

Common Variations and Edge Cases

Tighter revocation usually increases operational overhead, so organisations must balance fast invalidation against integration complexity and user friction. That tradeoff is most visible in federated systems, multi-tenant SaaS, and agentic workloads where a single identity may span several applications or toolchains. There is no universal standard for ownership in these cases yet, but the safest pattern is still shared accountability with one clearly named control owner.

Edge cases matter. Some platforms support immediate server-side revocation; others rely on short TTLs and introspection, which means revocation is only as fast as the next token check. For highly automated environments, especially where AI agents or service integrations operate continuously, the risk is higher because a compromised refresh token can be used to obtain new access silently until expiry. That is why token lifecycle control should be aligned with the Guide to the Secret Sprawl Challenge, which shows how unreclaimed credentials persist across systems and teams.

Where external identity providers, consent frameworks, or delegated admin models are involved, the revocation owner may differ from the system that physically deletes the token. The practical test is simple: the team responsible for changing access must also ensure the token can no longer mint new access, or the change is incomplete.

Related resources from NHI Mgmt Group

• What is the difference between rotating a secret and revoking access?
• What is the difference between access token abuse and refresh token abuse?
• When does a refresh token become a privileged access problem?
• What breaks when token refresh and revocation are treated as background plumbing?