Should organisations use short-lived JWTs for machine access?

Yes, short-lived JWTs are safer than long-lived ones for machine access, but only if validation and audience restrictions are equally strict. Short expiry limits replay value, yet it does not fix poor storage or missing signature checks. Organisations should pair short TTLs with revocation paths and consistent verification.

Why This Matters for Security Teams

Short-lived JWTs are attractive because they shrink the replay window, but expiry alone does not make machine access safe. The real risk is that JWTs are often treated as if they were self-protecting, when in practice they still depend on strong signature validation, precise audience checks, issuer trust, and secure storage. For NHI programs, that matters because machine identities scale quickly and are frequently over-permissioned, a pattern highlighted in the Ultimate Guide to NHIs and the Ultimate Guide to NHIs — Key Challenges and Risks. If a short-lived token is stolen from logs, memory, or a misconfigured cache, the attacker still has a usable credential, just for a shorter period. That is why OWASP’s OWASP Non-Human Identity Top 10 treats token handling, validation, and lifecycle discipline as core control issues, not optional hardening. The issue is not whether JWTs can be used, but whether the surrounding identity controls are mature enough to make short TTL meaningful. In practice, many security teams discover this only after a token leak or lateral movement event, rather than through intentional design review.

How It Works in Practice

A short-lived JWT can be a sound control for service-to-service access when it is issued for one workload, one audience, and one narrowly defined action. The best pattern is to pair it with workload identity, such as SPIFFE-style identity or an OIDC-backed assertion, so the token proves what the workload is before it is allowed to act. That keeps the JWT as a short-lived proof token rather than a reusable bearer secret. It also supports Zero Trust thinking because every request is evaluated against context instead of assumed trust. This aligns with the broader NHI lifecycle guidance in the 52 NHI Breaches Analysis, where weak lifecycle handling repeatedly turns valid credentials into incident pathways.

• Issue JWTs only from a trusted issuer with strict audience and issuer validation on every request.
• Bind tokens to the workload and task scope, not to a broad service role that outlives the job.
• Set expiry as short as the operational path allows, then automate renewal and revocation.
• Keep signing keys protected, rotate them predictably, and reject tokens that fail signature checks or drift outside policy.
• Log token issuance and use, but avoid exposing bearer material in observability pipelines.

For governance, current guidance suggests combining short TTLs with revocation paths, policy-as-code, and periodic access reviews, rather than using expiry as a substitute for authorization design. The OWASP Non-Human Identity Top 10 is useful here because it frames token misuse, weak secret handling, and excessive trust as separate failure modes that need separate controls. These controls tend to break down in distributed CI/CD and event-driven systems because token issuance, validation, and revocation often happen across different platforms with inconsistent policy enforcement.

Common Variations and Edge Cases

Tighter JWT expiry often increases operational overhead, requiring organisations to balance lower replay risk against more frequent token refresh, more automation, and stricter clock synchronisation. That tradeoff is acceptable for many workloads, but it is not universal. Current guidance suggests that short-lived JWTs are strongest when the workload is stable, the trust boundary is clear, and the issuer can enforce revocation or rapid key rollover. They are weaker when tokens must cross many hops, survive offline processing, or support legacy systems that cannot validate claims consistently.

There is no universal standard for this yet in every environment. For example, a batch pipeline that runs for hours may need token refresh or delegated exchange, while an interactive control plane can often use very short TTLs without disruption. The same caution applies to agents and other autonomous workloads, where access should be tied to intent and runtime context rather than static role assumptions. The Ultimate Guide to NHIs — Key Challenges and Risks is relevant because token age is only one part of the problem; storage, rotation, and visibility failures can still defeat a well-meaning TTL policy. In practice, short-lived JWTs are a control, not a guarantee, and they work best when paired with OWASP Non-Human Identity Top 10 guidance, strong audience restrictions, and a revocation process that security teams actually test.

Related resources from NHI Mgmt Group

• Should organisations use API keys or OAuth 2.0 for machine access?
• Should organisations use FIDO2 for privileged access first?
• Why do ephemeral credentials still leave risk in machine access models?
• When do short-lived access tokens still leave organisations exposed?