Security teams should treat JWTs as short-lived credentials, not reusable trust objects. Scope them tightly to a specific service, action, and session, and validate signature, issuer, audience, and expiry on every request. Limit token exposure in logs, tickets, and code, because a stolen token can often be replayed until it expires or is revoked.
Why JWTs become risky in machine-to-machine systems
In machine-to-machine environments, a JWT is often acting as a bearer credential, so whoever holds it can use it until it expires. That makes the token itself a high-value secret, not just a convenient assertion. The security problem is usually not the format, but the combination of long lifetimes, broad scopes, weak audience binding, and accidental reuse across services.
Teams usually get into trouble when they treat JWTs as reusable proof of identity instead of a narrowly bound authorization artifact. If one token can reach multiple services, or if downstream services accept tokens without checking issuer, audience, and expiry, compromise of a single integration path can become broad access. That is exactly why workload identity guidance emphasises tight scoping and token lifecycle control, as reflected in Guide to SPIFFE and SPIRE and the OWASP Non-Human Identity Top 10.
Where JWTs are used for service-to-service calls, the main control question is whether the token is bound to a single trust path and a single purpose. If the answer is no, the same credential can drift into logs, tickets, CI systems, or code samples and still remain useful to an attacker. That is why token handling should be designed around the smallest viable blast radius, not around convenience for integration teams.
Controls that reduce token replay and privilege spread
The practical defense is to make every JWT hard to reuse outside its intended context. Short expiry windows, precise audience claims, strict issuer validation, and service-specific scopes all reduce the value of a stolen token. For machine-to-machine traffic, the best pattern is often to issue tokens that are only valid for one service, one action class, and one narrow time window, then require fresh issuance for the next trust step.
Validation should happen on every request, not only at token creation. A service that skips signature verification, accepts multiple issuers, or tolerates stale tokens is effectively widening access after the fact. Teams should also keep JWTs out of places where they are easy to copy, including application logs, debug traces, support tickets, pasted snippets, and client-side telemetry. These handling rules are central to the broader NHI control model described in Ultimate Guide to NHIs, Key Challenges and Risks.
When the architecture supports it, pair JWTs with stronger workload identity controls instead of letting the token carry all trust on its own. Proof-of-possession style binding, mTLS between services, or workload identity frameworks such as SPIFFE make replay materially harder because the token alone is no longer enough. For readers comparing implementation paths, the token issue should be framed as part of a broader service identity and trust-boundary design, not as a standalone authentication trick. Ultimate Guide to NHIs, What are Non-Human Identities is a useful companion when teams need the bigger identity picture.
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 Zero Trust (SP 800-207), 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 Management | JWTs function as bearer credentials in machine-to-machine flows. |
| NHI-02 — Identity Lifecycle | Short-lived machine credentials need tightly controlled issuance and expiry. | |
| NHI-03 — Least Privilege | Broad JWT scopes create excessive machine access and replay blast radius. | |
| Recommendation — Bind JWTs to a single service, action, and lifetime, then rotate or revoke on exposure. Issue JWTs with the shortest practical TTL and enforce automatic expiration and reissuance. Restrict each token to the minimum audience and claims needed for one action path. | ||
| NIST Zero Trust (SP 800-207) | 3e — Continuous Authentication and Authorization | Every request must revalidate token trust conditions in zero trust designs. |
| Recommendation — Reevaluate JWT validity and context on every request before granting service access. | ||
| CIS Controls v8 | 6.3 — Access Management | Machine-to-machine JWTs should be governed as access credentials with limited scope. |
| 8.2 — Audit Log Management | JWTs must not be exposed in logs or support records where they can be replayed. | |
| Recommendation — Enforce least-privilege access and remove any token grants that exceed the required business purpose. Prevent secret-like tokens from appearing in logs, traces, tickets, and other retained records. | ||
| NIST CSF 2.0 | PR.AC-1 — Identity and Access Management | JWT handling determines which services can authenticate and access protected resources. |
| PR.DS-1 — Data-at-Rest Protection | JWTs are sensitive credentials that can be exposed in storage and observability systems. | |
| DE.CM-8 — Vulnerability Scans and Assessments | Misuse of JWTs often appears as overbroad trust or weak validation in service integrations. | |
| Recommendation — Limit token acceptance to explicitly authorized services and verified trust relationships. Protect stored tokens and token-bearing records so they cannot be copied and replayed. Assess service-to-service token handling for weak validation, broad scope, and replay exposure. | ||
| MITRE ATT&CK | T1552 — Unsecured Credentials | Stolen JWTs are credentials that attackers can harvest from logs, code, or traffic. |
| Recommendation — Hunt for exposed tokens in repositories, logs, tickets, and telemetry, then remove the exposure path. | ||
Practitioner Guidance
What to verify: Before approving a JWT pattern, confirm that every consuming service checks signature, issuer, audience, and expiry independently. Also verify that scopes map to one business action, not an entire integration domain, because “service access” is usually too broad for machine-to-machine use.
What to measure: Track token lifetime, scope breadth, and the number of services that will accept the same token. If a token is valid for too long or across too many receivers, the design is already carrying broad access risk even if no abuse has been observed.
Common mistake: Teams often secure issuance but ignore replay exposure after issuance. A token that appears safe in the auth service can still be dangerous if it is copied from logs, forwarded in support workflows, or accepted by downstream services with loose validation.
Practitioner takeaway: Treat JWTs as disposable, narrowly bound credentials, and design every validation and routing decision around the assumption that a stolen token will be replayed before it expires.
Related resources from NHI Mgmt Group
- How should security teams handle temporary access for contractors and seasonal workers without creating standing privilege risk?
- How should security teams secure machine-to-machine access without creating standing privilege risk?
- How should security teams restrict third-party access in supply chain environments without creating broad network trust?
- How should security teams handle machine-to-machine SSH access without creating hidden access paths?
