TL;DR: Truffle Security reports that a new JWT detector found hundreds of live tokens within hours, while shared-secret JWTs appeared 28 times more often than public-key JWTs in a large GitHub sample, underscoring the difficulty of revocation and exposure validation for stateless credentials. Stateless access simplifies authentication, but it pushes governance burden into detection, issuer controls, and downstream remediation.
At a glance
What this is: Truffle Security shows that live JWT exposure can be detected quickly, but revocation and liveness validation remain hard because JWTs are stateless credentials.
Why it matters: IAM and NHI teams need to treat JWTs as governed credentials, not just tokens, because exposure, validation, and revocation all behave differently from traditional session-based access.
👉 Read Truffle Security's analysis of JWT liveness verification and stateless access
Context
JWTs are stateless credentials used for authentication and authorization in web-facing applications, which means their trust is embedded in the token itself rather than checked against a central session store. That design makes exposure harder to govern because revocation, validation, and discovery all depend on how the issuer and consuming application are configured.
This article is about what happens when secret scanning starts verifying JWT liveness instead of only detecting token-shaped strings. For identity governance, the important issue is not token syntax alone but whether exposed credentials can still be used, whether they can be revoked cleanly, and whether the surrounding process can prove which application they unlock.
Key questions
Q: What breaks when a JWT cannot be revoked after permissions change?
A: When a JWT cannot be revoked, access control becomes stale the moment a user’s rights change. A token issued earlier can still authorize actions that the server no longer intends to allow, creating the New Enemy Problem. That gap is especially dangerous for backend services, where revoked users may still reach sensitive data until the token expires.
Q: When should teams prioritise JWT expiry policy over broader secret scanning?
A: Prioritise expiry policy when the token family has no dependable revocation path and is used in high-value integrations. Secret scanning still matters, but short-lived tokens reduce the time an exposed credential remains usable, which directly lowers the operational window for abuse.
Q: What are the signs that JWT exposure detection is missing real risk?
A: A common sign is a scanner that reports only a narrow token subtype while the environment relies heavily on other JWT formats, especially shared-secret tokens. Another warning is when teams can identify leaks but cannot quickly name the issuer, application, or revocation method.
Q: How should IAM teams govern stateless credentials in SaaS environments?
A: They should assign ownership, expiry policy, and revocation method to every token family, then verify that the application can actually honour those controls. Stateless credentials need lifecycle governance as much as discovery, because the risk lives in how long they remain trusted.
Technical breakdown
How JWT liveness verification works
JWT liveness verification is different from ordinary secret checking because the detector first parses the token, validates claims such as expiration and not-before time locally, and then verifies the signature against public keys discovered through OIDC Discovery. That ordering matters because signature validation is what proves the token was actually issued by a trusted source. In practice, this approach avoids unnecessary network calls and filters out many expired or malformed tokens before they become findings. The limitation is that local liveness is only a proxy for real application behaviour, because the consuming service may use different validation logic or key material.
Practical implication: Treat liveness verification as a triage signal, not a full proof of application acceptance.
Why stateless JWTs are hard to revoke
JWTs are stateless, so the application typically does not consult a central revocation list on every request. Instead, the token remains valid until its expiry or until the issuer changes the signing key, which can invalidate many tokens at once. A third option is to add a revocation database to the application, but that removes the stateless property and adds engineering overhead. This is why leaked JWTs create a governance problem that traditional session-token thinking does not solve: the credential can remain usable even after discovery unless the issuer or application model changes.
Practical implication: Map JWT revocation paths before exposure happens, especially where long-lived tokens are still in use.
Why shared-secret JWTs are a different exposure problem
Shared-secret JWTs, usually based on HMAC algorithms, are harder to assess because the same secret is needed to verify and create tokens. Truffle Security notes they are far more common than public-key JWTs in its GitHub sample, but the detector does not currently report them because liveness cannot be established as cleanly. That means the exposure surface can be larger than the live findings suggest. For IAM teams, this is a reminder that token format and signing model drive both detection quality and remediation complexity.
Practical implication: Prioritise token types that can be validated and revoked deterministically, then reassess shared-secret JWT governance.
Threat narrative
Attacker objective: Use a live JWT to access the underlying application or SaaS service without triggering traditional account-based controls.
- Entry occurs when a JWT is exposed in logs, files, repositories, or other shared content that secret scanning can reach.
- Credential access follows when the leaked token is still within its validity window and can be verified as live against issuer keys.
- Impact occurs when the token is used to authenticate to the target application or service without needing a password reset or interactive session takeover.
Breaches seen in the wild
- Microsoft Storm-0558 key breach 2023: China-based Storm-0558 used a stolen, never-retired Microsoft signing key to forge tokens and read email at 22 organisations in 2023.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
JWT liveness verification turns secret scanning into an IAM control, not just a detection feature. The important change is that exposed tokens are no longer just strings to catalogue, but credentials whose runtime validity matters to the governance outcome. That shifts the practitioner question from "was a token found?" to "can it still be used, and what does that mean for revocation design?" The implication is that token exposure management now belongs in identity governance and not only in developer tooling.
Stateless access creates a revocation gap that traditional session thinking cannot close. JWTs were designed for decoupled verification, but that same property removes the central checkpoint that makes ordinary session invalidation straightforward. When a token can remain accepted until expiry, exposure response becomes a matter of issuer control, signing-key governance, or application redesign. Practitioners need to recognise that the control assumption has shifted from central invalidation to distributed trust enforcement.
Shared-secret JWTs expose the limits of exposure detection itself. If the credential cannot be cleanly verified for liveness, the scanner may under-report real risk in exchange for avoiding noisy false positives. That creates a visibility problem, not just a technical one, because governance teams may assume the visible findings represent the full estate when they do not. The implication is that detection policy must be aligned to signing model, not applied uniformly across token types.
Identity programmes need a named concept for this problem: token liveness debt. That is the governance gap created when a stateless credential can remain operationally valid long after exposure, but the organisation lacks a clean way to prove, revoke, and account for it. This is not merely secret sprawl in another form; it is a lifecycle failure in which the credential outlives the control model built around it. The practical conclusion is to treat token liveness as an inventory and lifecycle attribute, not just a detection outcome.
What this signals
Token liveness is now part of exposure governance. If a JWT can be found and verified as live, the programme has moved beyond secret discovery into credential lifecycle control. That means scanning outputs should feed ownership, expiry, and revocation workflows, not just ticket queues.
Stateless access changes the control boundary. Traditional session controls assume a server-side record can be revoked or challenged; JWTs push that burden into issuer design and downstream application logic. Security teams should watch for places where the control boundary has shifted without an explicit governance decision.
For practitioners
- Define JWT revocation paths before exposure Document whether each token family expires naturally, rotates by signing key, or depends on an application revocation database, then map those paths to owners and response steps.
- Separate public-key and shared-secret token handling Classify token types by signing model so the scanning, validation, and response workflow reflects what can be verified locally and what cannot.
- Shorten token lifetime where revocation is weak Use shorter expiry windows for stateless credentials that cannot be reliably revoked without wider service disruption, especially in SaaS integrations.
- Scan surrounding storage for exposed JWT context Check logs, collaboration stores, and build artefacts around each token finding to determine which application or service it can unlock.
- Review issuer discovery assumptions Confirm that each issuer exposes keys and metadata in a way your scanners and consuming applications can actually validate, including non-standard deployments.
Key takeaways
- JWTs are not just another secret type because their stateless design changes how exposure, validation, and revocation work in practice.
- The article shows that live JWTs can be found quickly, but that finding is only useful if the organisation has a clear revocation path.
- Security teams should govern JWT lifetime and issuer behaviour as part of identity lifecycle management, not treat token scanning as the whole control.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | JWT liveness and validation failures create insecure authentication conditions for exposed tokens. |
| NHI-07 — Long-Lived Secrets | The article centres on stateless credentials that remain usable until expiry or key rotation. | |
| Recommendation — Review JWT validation paths for insecure authentication and remove any trust on tokens that cannot be verified. Shorten JWT lifetimes and track any token family that behaves like a long-lived secret. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JWT issuance, expiration, and revocation map directly to authenticator lifecycle management. |
| Recommendation — Apply IA-5 to govern token issuance, expiry, rotation, and revocation for JWT-based access. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern is exposed credentials being reused before they expire or are revoked. |
| Recommendation — Map exposed JWTs to credential access risk and prioritise the tokens with the widest blast radius. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | JWT claims encode authorisation state, so access governance depends on how those entitlements are controlled. |
| Recommendation — Validate JWT-derived entitlements against PR.AA-05 and remove standing access that cannot be revoked cleanly. | ||
Key terms
- Json Web Token: A JSON Web Token is a compact, signed token that carries claims between systems so they can verify identity or authorization without consulting a central session store. In practice, its safety depends on strict validation of the signature, issuer, audience, expiry, and algorithm before any trust decision is made.
- Liveness Assurance: Liveness assurance is a biometric control that checks whether a presented face comes from a real, live person rather than a photograph, video, or other replayed image. It is used to reduce spoofing risk during online authentication and to help confirm that the user is physically present at the point of verification.
- OIDC Discovery Document: An OIDC Discovery Document is a machine-readable file that tells clients how to use an OpenID Connect identity provider. It publishes endpoints, supported features, signing keys, and issuer details in a standard JSON format, usually at a well-known URL. This enables automated configuration and reduces manual integration errors.
- Stateless Credential: A stateless credential is a token that can be validated without consulting a server-side session store on every request. That design improves scalability, but it also makes revocation, exposure response, and lifecycle governance harder because trust is embedded in the token itself.
What's in the full article
Truffle Security's full article covers the detector mechanics this post intentionally leaves for the source:
- The exact JWT parsing and OIDC Discovery workflow used to verify liveness
- Why public-key JWTs can be validated while shared-secret JWTs remain harder to score
- The practical limits of verifying tokens issued from non-routing IPs or non-standard key locations
- The remediation trade-offs between waiting for expiry, rotating signing keys, and adding revocation logic
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org