How should security teams handle leaked JWTs that cannot be centrally revoked?

Why This Matters for Security Teams

A leaked JWT is not just a credential leak. It is a bearer token that may remain valid until expiry across every service that trusts the issuer, which makes response slower and more conditional than with centrally revocable secrets. Security teams have to determine whether the token is a session artifact, an API access token, or a workload credential, then map which applications validate it and which ones only check signature and expiry. That distinction drives the containment plan.

This is why NHI lifecycle discipline matters, as described in the NHI Lifecycle Management Guide and the Ultimate Guide to NHIs — Static vs Dynamic Secrets. Current guidance also aligns with the OWASP Non-Human Identity Top 10, which treats token handling, trust boundaries, and lifecycle controls as core security concerns. In practice, many teams only discover the blast radius after the token has already been replayed inside multiple services.

How It Works in Practice

The first step is to identify what the JWT actually does. Decode it, confirm the issuer, audience, claims, and expiration, then trace every API gateway, service mesh, and application that accepts it. If the token is signed with a shared issuer key, then rotating that signing key may invalidate the token everywhere, but it can also break unrelated services if their trust model is broad. If the token is validated only by the application, application-level denylisting or server-side session invalidation may be the safer containment path.

For leaked bearer tokens, runtime control matters more than static policy. Best practice is evolving toward short-lived tokens, token exchange, and tighter trust boundaries so that access is bounded by context rather than by the mere possession of a string. NHI programs that reduce blast radius through lifecycle controls are less exposed to this problem, as discussed in NHIMG’s Guide to the Secret Sprawl Challenge. Security teams should also prefer patterns that let applications enforce re-authentication, revocation lists, or introspection for high-risk actions.

• Confirm whether the JWT is an access token, refresh token, or workload assertion.
• Check token TTL and whether the issuer supports key rotation without service outage.
• Identify all downstream services that validate the same signing keys or issuer metadata.
• Use application-side revocation or denylisting when central revocation is not available.
• Shorten future token lifetimes and reduce the scope of claims to limit replay value.

For identity-bound services, the OWASP NHI guidance and lifecycle controls in NHIMG research reinforce the same point: leaked tokens should be treated as live access until their trust path is explicitly closed. These controls tend to break down when multiple business-critical services share one issuer and cannot tolerate synchronized key rollover because revocation becomes a dependency management problem, not a token problem.

Common Variations and Edge Cases

Tighter revocation often increases operational risk, requiring organisations to balance containment against service availability. That tradeoff is most visible when one JWT issuer supports many applications, or when legacy systems cannot consume token introspection. In those environments, rotating keys may be too disruptive, while waiting for expiry may be too slow. The right answer is often the least disruptive control that actually cuts off replay.

Edge cases are common. If the JWT is only a short-lived access token, forcing expiry may be enough. If it is a refresh token or a long-lived service token, the issue is more severe because the attacker may mint fresh access after the initial leak. Where there is no universal standard for central JWT revocation, current guidance suggests pairing shorter TTLs with stronger issuer controls and explicit application session invalidation. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because it frames revocation as a lifecycle event, not a one-time incident response task.

For broader context on how quickly leaked credentials create operational burden, The 2024 State of Secrets Management Survey Report found the average time to mitigate a leaked secret is 36 hours, which underscores how slow manual containment can be. That gap becomes more dangerous with JWTs because every valid token remains usable until the trust chain is broken.

Related resources from NHI Mgmt Group

• How should security teams authenticate AI agents in enterprise environments?
• How should security teams implement Client ID Metadata Documents?
• How should security teams handle leaked secrets across developer workflows?
• How should security teams handle leaked credentials reported outside bug bounty scope?