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.
Expanded Definition
A JSON Web Token, or JWT, is a compact way to package claims so one system can trust information asserted by another without maintaining a shared session state. In NHI and machine-to-machine environments, JWTs often carry issuer, audience, subject, expiry, and scope data that must be validated before access is granted.
The important distinction is that a JWT is not automatically safe because it is signed. The signature only proves integrity from the issuing party; it does not prove the token is intended for the current service, still within its lifetime, or mapped to an acceptable privilege set. Usage in the industry is still evolving because some teams treat JWTs as a generic login artifact while others use them as short-lived bearer assertions inside broader federation designs. For implementation guidance, NIST Cybersecurity Framework 2.0 reinforces the need to verify identity and access conditions before trust decisions, and JWT handling should be read through that lens.
The most common misapplication is accepting any syntactically valid token, which occurs when teams skip issuer, audience, and algorithm checks during rapid service integration.
Examples and Use Cases
Implementing JWTs rigorously often introduces validation and key-rotation overhead, requiring organisations to weigh stateless scalability against the operational cost of stronger verification.
- API gateways issue signed JWTs to microservices so each request can be authorised without a central session lookup, but the gateway must enforce strict expiry and audience validation.
- Workload identity systems use JWTs for short-lived service authentication, especially when paired with federated trust and automated key rotation; this pattern is often discussed alongside NIST Cybersecurity Framework 2.0 and identity assurance planning.
- Agentic systems can present JWTs when an Salesloft OAuth token breach-style event shows how token theft converts one exposed credential into broad downstream access.
- Teams building event-driven integrations may use JWT claims to carry scope and tenant context, but they must avoid overloading the token with sensitive data that should remain server-side.
- Designs that follow zero trust principles often pair JWTs with continuous policy checks rather than assuming a bearer token alone establishes durable trust.
For standards-backed implementation, the token format itself is defined in the IETF JSON Web Token specification, while operational trust should align with the NIST Cybersecurity Framework 2.0. A practical comparison point is the Guide to the Secret Sprawl Challenge, which shows how credentials spread when organisations fail to control where tokens are stored and reused.
Why It Matters in NHI Security
JWTs matter because they are often the trust carrier for NHIs, service accounts, and automation paths that no human watches in real time. If validation is weak, a stolen or forged token can impersonate an application, bypass role boundaries, or outlive the event that created it. That is especially dangerous in environments where tokens are copied into tickets, chat tools, config files, and CI/CD logs.
NHIMG research shows that 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira, Confluence, and code commits, which means the risk is not theoretical. This is why JWT handling must be paired with short lifetimes, audience pinning, key rotation, and rapid revocation workflows. The problem is rarely the token format itself. The problem is assuming a token remains trustworthy after it leaves the issuing boundary. The Guide to the Secret Sprawl Challenge and the State of Secrets Sprawl 2026 both illustrate how exposed credentials become persistent attack paths when governance lags behind deployment speed. Organisations typically encounter JWT risk only after token replay, offboarding failure, or unauthorized API access, at which point the token lifecycle 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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | AAL2 | JWTs often carry authenticator claims that must meet identity assurance expectations. |
| NIST Zero Trust (SP 800-207) | 3.3 | Zero Trust requires explicit verification before trusting any bearer token. |
| OWASP Non-Human Identity Top 10 | NHI-02 | JWTs are a common non-human credential form that can be overexposed or mismanaged. |
Validate token-based authentication strength and pair JWT use with equivalent assurance checks.
