Why do JWTs still leave organisations with identity risk?

Why This Matters for Security Teams

JWTs solve one problem, but they often leave the harder one untouched: proving that the holder should still be trusted right now. A token can be valid, signed, and unexpired while the underlying service account has excessive privilege, the refresh token path is weak, or the signing key has leaked. That is why JWT risk is usually an identity governance problem, not just a cryptography problem. NHI governance research shows how broad the exposure is: the Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which turns any token compromise into immediate blast-radius expansion. Security teams also underestimate how much depends on surrounding controls such as key rotation, claim validation, issuer checks, and revocation design. NIST’s NIST Cybersecurity Framework 2.0 treats identity assurance and continuous protection as operational disciplines, not one-time configuration tasks. In practice, many security teams encounter JWT abuse only after a stolen token or weak validation rule has already been used to move laterally, rather than through intentional testing of the token lifecycle.

How It Works in Practice

A JWT becomes risky when organisations treat it as the identity control rather than as one credential in a larger NHI system. The token may carry useful claims, but those claims are only safe if the issuer is trusted, the signature is validated correctly, the audience and expiry are checked, and the downstream service enforces least privilege. If any of those checks are skipped, an attacker can replay or modify access in ways that are hard to detect. Operationally, teams should harden the full path:

• Use short-lived tokens and tightly bound refresh flows, because long-lived secrets increase exposure after compromise.
• Validate issuer, audience, expiry, nonce, and algorithm choices consistently across services.
• Rotate signing keys and isolate them from build systems, code, and CI/CD tooling.
• Apply RBAC only where role boundaries are stable; for service-to-service access, pair it with workload identity and policy checks at request time.

This is where NHI visibility matters. The 52 NHI Breaches Analysis shows how often identity failures become breach paths, and the Top 10 NHI Issues highlights common breakdowns such as overprivilege and weak secret handling. For implementation guidance, NIST CSF 2.0 and the NIST Cybersecurity Framework 2.0 both reinforce continuous monitoring, access governance, and recovery discipline. These controls tend to break down in fast-moving microservice estates because teams cannot keep token policy, key rotation, and service ownership aligned across hundreds of deployments.

Common Variations and Edge Cases

Tighter token controls often increase operational overhead, so organisations have to balance security against delivery speed and service complexity. That tradeoff is especially visible in systems that rely on federated identity, external IdPs, or many machine-to-machine integrations where token formats differ by platform. Current guidance suggests three common edge cases deserve special handling. First, JWTs used as access tokens for high-value internal APIs should be treated as ephemeral credentials, not durable authorisations. Second, where token revocation is not feasible at scale, short TTLs and JIT issuance become more important than elaborate blacklist logic. Third, in agentic or highly autonomous workloads, static claims are often insufficient because behaviour changes by task; in those cases, current best practice is evolving toward intent-based authorisation and workload identity rather than simple role mapping. The OWASP NHI Top 10 and Ultimate Guide to NHIs — Key Challenges and Risks are useful references for these failure modes. For teams modernising governance, the practical answer is not to eliminate JWTs, but to wrap them in rotation, monitoring, workload identity, and policy enforcement that can fail closed when assumptions drift.

Related resources from NHI Mgmt Group

• Why do ephemeral credentials still leave risk in machine access models?
• When does short-lived identity still leave too much risk?
• What breaks when organisations keep passwords as the default identity control?
• Why do OAuth tokens create long-lived identity risk in enterprise environments?