What happens when a stolen JWT never expires or is checked too loosely?

A stolen JWT becomes a reusable access pass if the application does not enforce expiration or verify the claim during validation. That allows an attacker to keep using the token long after the original session should have ended. The risk is especially high in stateless systems, because the server has no separate session store to invalidate the token automatically.

Why a Stolen JWT Becomes a Persistent Access Problem

A JWT is meant to be a time-bounded assertion, not a permanent pass. If an application fails to enforce the exp claim, or validates it too loosely, a stolen token can keep authenticating the attacker long after the legitimate session should have ended. That turns a single leak into repeated access, especially where the token also carries broad scopes or high-value roles. OWASP’s Non-Human Identity Top 10 is useful background because the same lifecycle weaknesses that affect machine credentials also apply when tokens are treated as reusable trust artifacts rather than short-lived proof.

The core issue is that jwt validation is entirely application-dependent. The token format does not guarantee revocation, rotation, audience restriction, or expiry enforcement; those checks must be implemented correctly every time the token is accepted. When they are not, a copied token can outlive password resets, user logout, and even some account deprovisioning events.

In practice, many teams discover the weakness only after a token has already been replayed from outside the expected session or network context.

How Loose JWT Validation Works in Practice

JWTs are often attractive because they reduce server-side session state, but that design also removes a convenient control point. If the server only checks that the signature is valid and the token is structurally sound, the token may still be accepted even when it is expired, issued for the wrong audience, or presented from a workflow that should no longer be trusted. A stolen token then behaves like a portable credential.

That risk is amplified in stateless APIs, mobile back ends, service integrations, and distributed systems where token validation is replicated across many services. A single weak verifier can become the weakest link, especially if one service accepts tokens with relaxed clock skew, ignores issuer or audience claims, or treats expiration as advisory rather than mandatory. NHI Management Group’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is relevant here because the practical security difference is the same: short-lived, bounded credentials reduce the window in which theft remains useful.

Verify signature, issuer, audience, subject, and expiration on every request path that accepts the token.
Keep token lifetimes short enough that theft does not translate into durable access.
Use refresh or re-authentication flows for longer sessions instead of extending access tokens indefinitely.
Pair JWT acceptance with compensating controls such as step-up checks for sensitive actions, anomaly detection, and token binding where supported.

Teams should also distinguish between authentication and authorisation: a valid signature only proves the token was issued by someone trusted, not that the current request is still appropriate. That distinction matters most when the token is reused across microservices, because one accepting service can expose data or actions that another service would have blocked. Controls tend to break down when multiple teams implement their own validation logic, because a single permissive parser or skipped claim check creates a durable bypass.

When Expired-Token Assumptions Break Down

Tighter token rules often increase operational friction, so organisations must balance usability against replay resistance. Very short expiries can create more refresh traffic and more re-authentication events, which is manageable in well-designed systems but painful in brittle ones. The tradeoff is acceptable when the token can reach sensitive resources, but less critical for low-impact, low-privilege paths.

Edge cases matter. Clock drift can cause false rejections, so best practice is evolving toward small, clearly bounded skew rather than broad acceptance windows. Revocation is another common gap: JWTs are not inherently revocable once issued, which means teams often need compensating controls such as short TTLs, token versioning, deny lists for exceptional cases, or backend checks for high-risk operations. If a token can be replayed after logout, password reset, or role change, the problem is not the token itself but the surrounding trust model.

For security review, the key question is whether the application treats expiry as a hard stop or merely a hint. The same logic applies to any environment that caches tokens aggressively, shares them across services, or accepts them from untrusted clients without checking whether they remain valid in the current context. NHI Management Group’s NHI Lifecycle Management Guide helps frame the broader lifecycle expectation: credentials and tokens must be issued, bounded, monitored, and retired in a way that makes reuse difficult, not merely inconvenient.

Risk and Threat Considerations

A stolen JWT that never expires, or that is validated too loosely, creates a replay and persistence risk. The attacker does not need to crack the token; they only need to reuse it before the application stops accepting it. That makes token theft materially more valuable than a one-time session hijack, because the access path can remain available across password changes, logout events, or some account recovery actions.

Failure mechanism: Weak claim validation, excessive clock skew, missing audience or issuer checks, and lack of revocation support allow an attacker to replay a captured token as if it were still legitimate. In distributed systems, one permissive service can extend the compromise if downstream services trust the same token without independent revalidation.

Impact: Unauthorized access can persist long enough for data theft, privileged action, lateral movement through APIs, or abuse of business workflows. The longer the token remains valid, the more the compromise shifts from a short incident into an enduring access problem.

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 CIS Controls v8 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-01 — Secrets and Credential Lifecycle	JWTs are reusable credentials that need expiry, rotation, and revocation discipline.
Recommendation — Enforce short token lifetimes and rotate or revoke credentials when trust changes.
CIS Controls v8	5 — Account Management	Stolen JWTs act like active account access and need lifecycle control.
	6 — Access Control Management	Loose validation lets expired tokens continue authorising requests.
Recommendation — Limit token validity and remove access promptly when sessions or roles change. Verify claims strictly and deny any token that no longer matches policy.
NIST CSF 2.0	PR.AC-3 — Remote Access is Managed	JWT replay is a remote-access trust issue requiring enforced validation.
	PR.AC-7 — Users, devices, and other assets are authenticated commensurate with risk	High-risk tokens should require stronger checks than basic signature validation.
Recommendation — Apply consistent token validation across all remote access paths. Increase authentication checks before accepting tokens for sensitive actions.
MITRE ATT&CK	T1528 — Steal Application Access Token	A stolen JWT is an application access token theft and replay scenario.
Recommendation — Detect token theft and hunt for replay from unusual sources or sessions.

Practitioner Guidance

What to verify: Confirm that every token-consuming service enforces exp as a hard requirement and rejects tokens that fail issuer, audience, subject, or signature checks. If any service accepts the token without full validation, treat that service as the real trust boundary.

Decision rule: If the token can reach customer data, administrative functions, or machine-to-machine integration points, prioritise short-lived access tokens and bounded refresh logic over convenience. If the token is used only for low-risk, low-impact reads, the operational burden of tighter expiry may justify a slightly longer TTL, but not unbounded lifetime.

Practitioner takeaway: A JWT is only as safe as the strictest verifier that accepts it; if one path treats expiry as optional, the token becomes a reusable credential instead of a temporary assertion.