The expiration claim sets the time after which a JWT must no longer be accepted. It limits how long a compromised or intercepted token can be replayed. When expiration is missing or ignored, access can persist indefinitely, which turns a temporary credential into a long-lived security exposure.
Expanded Definition
The expiration claim, usually represented as exp in a JWT, is a time-based validity limit that tells a verifier when the token is no longer acceptable. It is a basic but essential control in token lifecycle management because it constrains replay risk, reduces the window for misuse after leakage, and supports predictable re-authentication or token refresh flows. In identity and API security, expiration works alongside issuance time, audience, issuer, and signature validation, but it is distinct because it governs temporal acceptance rather than identity proof or cryptographic integrity. Definitions are stable at the protocol level, but implementation guidance varies across vendors and platforms, especially when applications mix access tokens, refresh tokens, service tokens, and agent-issued credentials. For NHI and agentic AI environments, expiration is especially important because machine identities and autonomous agents often exchange secrets or tokens at high frequency, increasing the chance that a stale token is later reused. The most common misapplication is treating expiration as optional or merely informational, which occurs when applications decode a token without enforcing the time check during authorization.
Examples and Use Cases
Implementing expiration rigorously often introduces operational friction, requiring organisations to balance shorter replay windows against more frequent renewal, re-authentication, or token rotation.
- Access tokens for web or API sessions may carry a short expiration so that a stolen token has limited utility before the session must renew through a trusted flow.
- Service-to-service authentication in NHI-heavy environments can use brief-lived JWTs to reduce blast radius when a workload secret is exposed, aligning with the OWASP Non-Human Identity Top 10.
- Agentic AI tools that call downstream APIs may receive time-bounded tokens, ensuring the agent cannot continue acting with old authority after a policy change or incident response action.
- Session tokens in customer-facing applications often expire sooner than refresh tokens, separating active use from longer-lived renewal authority.
- Security teams testing JWT handling should verify that expired tokens are rejected even if the signature is valid, because cryptographic validity alone does not make a token current.
In practice, the claim is most useful when paired with clear renewal logic and logging so teams can distinguish normal expiry from suspicious reuse attempts. For token design, the JWT specification and related identity guidance from NIST SP 800-63 help teams align lifetime choices with assurance and session handling expectations.
Why It Matters for Security Teams
Expiration is one of the simplest controls with the biggest consequences when omitted, because it turns a momentary token theft into persistent access. Security teams need to treat expiry enforcement as a mandatory verification step at every trust boundary, including APIs, gateways, agent toolchains, and workload identity brokers. In identity-beyond-IAM environments, the issue often surfaces where machine identities, automation scripts, or AI agents are granted reusable access and then left running with stale authority after credential rotation or policy tightening. A valid signature does not compensate for an expired token, and a missed expiry check can undermine revocation, incident response, and conditional access decisions. The operational lesson is that token lifetimes are not just a configuration detail, they are a core part of blast-radius containment and recovery design. Organisaties typically encounter persistent unauthorized API access only after a leaked or cached token is reused beyond its intended window, at which point expiration becomes operationally unavoidable to address.
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 address the attack and risk surface, while NIST SP 800-63, NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | Session and authenticator assurance depend on enforcing bounded token lifetime and reauthentication. |
| NIST CSF 2.0 | PR.AC-1 | Identity and access controls rely on time-bounded credentials to limit ongoing access. |
| OWASP Non-Human Identity Top 10 | NHI guidance highlights short-lived secrets and tokens for machine identity risk reduction. | |
| NIST AI RMF | AI RMF governance applies where agents use time-limited credentials to act in systems. |
Set token expiry to match required assurance and force renewal when the session outlives its trust window.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
