up:: In the Protocols MOC

JWT

JWT (JSON Web Token) is a compact, URL-safe way to package a set of claims, facts like who a user is and what they’re allowed to do, so one system can hand them to another and the receiver can trust them without calling back to the issuer. That trust almost always comes from a digital signature over the token, and in most enterprise deployments that signature is RS256 or ES256, which are RSA and ECDSA underneath. Those are exactly the algorithms Shor’s algorithm breaks on a large quantum computer. So the quantum problem with JWT isn’t that yesterday’s tokens get read later. It’s that once the signature can be forged, an attacker can mint their own valid-looking tokens and walk straight through your identity layer, which makes JWT a Non-HNDL trust-forgery problem.

The short version:

• A JWT is three base64url pieces separated by periods, a header, a payload of claims, and a signature, defined in RFC 7519. The signature is what makes the claims trustworthy.
• The common signing algorithms (RS256, PS256, ES256) are RSA and ECDSA signatures, and both are broken by Shor’s algorithm on a capable quantum computer.
• A forged JWT is a Non-HNDL risk, there’s nothing worth harvesting, because a token only matters live. The danger is an attacker forging fresh tokens once a quantum computer exists, so it’s an authentication and authorization problem, not a stored-ciphertext one.
• Token-signing keys are often owned by an identity or platform team, separate from the PKI team that runs TLS certificates, so a crypto inventory scoped to “certificates” can miss them entirely.
• The migration is to move token signing to a post-quantum signature, ML-DSA, now standardized for JOSE by RFC 9964, and to treat issuer signing keys as high blast radius because one trusted issuer’s key underwrites a huge population of tokens.

Think of a JWT like a notarized letter of introduction. The letter states who you are and what doors you’re allowed to open, and the guard at each door trusts it because of the notary’s seal, not because he phones the notary every time. That’s the whole appeal, the guard checks locally and moves fast. But the entire system rests on the seal being unforgeable. If someone can reproduce the notary’s seal, they can write their own letters granting themselves any access they like, and every guard will wave them through. Quantum computing threatens the seal, the signature, not the letter format. The fix is to re-issue the notary’s seal in a form that can’t be forged, which is what moving token signing to a post-quantum algorithm does.

What is a JWT?

JWT is a compact, URL-safe token format for transferring a set of claims as a JSON object between two parties, standardized in RFC 7519. The claims are carried as the payload of a JSON Web Signature (JWS) structure, which signs them, or, less commonly in enterprise use, as the plaintext of a JSON Web Encryption (JWE) structure, which encrypts them. The signed case is by far the most common, and it’s the one that carries the quantum exposure.

A signed JWT is three base64url-encoded parts joined by period characters:

1. Header, which names the signing algorithm in its alg field (for example RS256 or ES256) and other metadata.
2. Payload, a JSON object of claims. RFC 7519 registers a standard set, including iss (the issuer that created the token), sub (the subject the token is about), aud (the audience it’s intended for), exp (the expiration time, after which it must not be accepted), nbf (a not-before time), iat (when it was issued), and jti (a unique token identifier). Applications add custom claims for roles, groups, scopes, and tenant context.
3. Signature, computed over the header and payload, which is what lets a receiver trust the claims without contacting the issuer.

The important thing to hold onto is that JWT is a container, not an algorithm. It doesn’t specify RSA or ECDSA or HMAC. It specifies a place to name whichever algorithm you chose, in the alg header. So “is JWT quantum-safe?” has no single answer. The answer depends entirely on which signing algorithm a given issuer actually put in that field.

Source: M. Jones, J. Bradley, N. Sakimura, “JSON Web Token (JWT),” RFC 7519, May 2015, datatracker.ietf.org.

Source: M. Jones, J. Bradley, N. Sakimura, “JSON Web Signature (JWS),” RFC 7515, May 2015, datatracker.ietf.org.

Where is a JWT used?

JWTs sit at the identity and authorization layer of modern distributed systems, wherever one component needs to trust an assertion made by another without a round trip back to the source. The heaviest concentrations are:

1. OAuth 2.0 access tokens. RFC 9068 defines a standard JWT profile for OAuth 2.0 access tokens, and it requires those tokens to be signed and forbids the none algorithm. This is the token an API checks to decide whether a caller is allowed in. The token is one of OAuth’s cryptographic surfaces, and the flow-layer proofs and bindings around it, DPoP, mTLS-bound tokens, the client assertion, and signed requests, are covered in PQC in OAuth 2.0 and OIDC.
2. OpenID Connect ID tokens. OIDC, the identity layer built on OAuth 2.0, represents its ID token as a signed JWT, which is how single sign-on tells a relying application who the user is.
3. Service-to-service and machine identity. Internal microservices, API gateways, and service meshes pass JWTs to prove workload identity and carry authorization context between calls.
4. Session and API authentication generally. Mobile backends, single-page-app backends, and plain API keys-as-tokens all lean on JWT because local verification scales, a relying party checks the signature itself rather than asking the issuer every time.

That last property, decentralized local verification, is exactly why the signature is load-bearing. The relying party isn’t confirming the token with the issuer on each request. It’s trusting math. When that math is a signature a quantum computer can forge, the local check becomes a place forged claims get accepted.

Source: V. Bertocci, “JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens,” RFC 9068, October 2021, datatracker.ietf.org.

Which parts of a JWT are quantum-vulnerable?

The signature is the quantum-vulnerable part, and only for the tokens signed with public-key algorithms. RFC 7518 (JSON Web Algorithms) defines the alg values a JWT can use, and they split cleanly into two groups with very different quantum stories.

The public-key signatures are broken by Shor’s algorithm. The RS* family is RSA (RSASSA-PKCS1-v1_5), the PS* family is RSA with PSS padding, and the ES* family is ECDSA. Every one of those rests on either integer factorization or the elliptic-curve discrete-logarithm problem, and Shor’s algorithm solves both efficiently on a large quantum computer. RS256 is the most widely deployed default, and ES256 is the common elliptic-curve choice, so the mainstream JWT ecosystem is squarely in the vulnerable group.

The HMAC signatures are a different story. The HS* family (HS256, HS384, HS512) is HMAC over a shared secret, which is symmetric. It isn’t broken by Shor’s algorithm at all. Its only quantum concern is Grover’s algorithm, which speeds up brute-forcing a key and is answered by using a long enough secret. The tradeoff with HMAC lives elsewhere, both the issuer and every verifier hold the same secret, so it’s a poor fit for decentralized verification and it widens the population that could leak that secret. On the quantum axis, though, HMAC-signed tokens are the durable ones.

JOSE alg	Signature family	Quantum threat	Exposure class
RS256 / RS384 / RS512	RSA (RSASSA-PKCS1-v1_5)	Broken by Shor’s	Non-HNDL trust forgery
PS256 / PS384 / PS512	RSA (RSASSA-PSS)	Broken by Shor’s	Non-HNDL trust forgery
ES256 / ES384 / ES512	ECDSA	Broken by Shor’s	Non-HNDL trust forgery
HS256 / HS384 / HS512	HMAC (shared secret)	Weakened by Grover’s	Symmetric, use a long secret

If a JWT is also encrypted (a JWE), the encryption’s key establishment can carry a separate harvest-now-decrypt-later exposure, the same way TLS key exchange does. But most enterprise JWTs are signed and not encrypted, and the dominant quantum issue for JWT as a category is the signature, not stored confidentiality.

Source: M. Jones, “JSON Web Algorithms (JWA),” RFC 7518, §3.1, May 2015, datatracker.ietf.org.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

Why is a forged JWT a trust problem and not a harvest problem?

A forged JWT is a Non-HNDL problem because a token only has value at the instant it’s presented, so there’s nothing an attacker gains by recording tokens today. Contrast this with TLS key exchange, where an attacker captures encrypted traffic now and decrypts it years later once a quantum computer arrives. That deferred payoff is what harvest-now-decrypt-later describes, and it makes long-lived confidential data exposed the moment it’s transmitted. A JWT has no such deferred payoff. A token that expired last year is worthless, and a captured token isn’t a signing key.

The danger is instead a forward one. On the day a capable quantum computer exists, an attacker who has an issuer’s public key, which is published openly at a JWKS endpoint by design, can derive the corresponding private key and then forge tokens at will. With a forged signing capability, an attacker can:

1. Mint access tokens that pass every API’s signature check.
2. Mint identity tokens that impersonate any user, including administrators.
3. Assert any role, scope, or group membership they choose in the claims.
4. Impersonate internal services and cross service-to-service trust boundaries.

Because the whole point of a JWT is that relying parties verify locally rather than phoning the issuer, a forged token is accepted everywhere the real issuer is trusted, with no central checkpoint that could catch it. That’s what makes the exposure class matter for sequencing. HNDL items are urgent because the clock is already running on captured data. JWT signing is urgent for a different reason, the blast radius is enormous and the day the forgery becomes possible, it’s immediate and total.

Why do JWT signing keys get missed in cryptographic inventories?

JWT signing keys get missed because they’re usually owned by a different team than the one that owns the certificates most inventories are built to find. A cryptographic discovery effort that starts from “find our TLS certificates and our PKI” tends to be run with, or scoped to, the PKI and network teams. Token-signing keys live somewhere else, in the identity provider, the authorization server, the API gateway, or the platform-engineering layer, and they’re managed by identity or platform engineers who often don’t think of themselves as running cryptography at all. They think of it as “the auth config.”

Two structural facts make this worse:

1. The signing key isn’t in a certificate. A JWT signing key is frequently a raw key published as a JSON Web Key at a JWKS endpoint, not an X.509 certificate in a certificate store. Tooling that enumerates certificates walks right past it.
2. “We use JWT” is easy to know, the crypto underneath is not. A team can tell you an API uses bearer tokens while having no idea which alg the issuer signs with, how long tokens live, whether validators pin an algorithm, or how key rollover actually works. The architectural fact is visible; the cryptographic fact takes inspecting a live token’s header, the issuer’s configuration, and the JWKS contents.

This is why a cryptographic bill of materials that reaches into identity and token-signing systems alongside network certificates is what surfaces this class of key, and why cryptographic ownership of the token layer has to be assigned deliberately rather than assumed to sit with PKI.

Source: M. Jones, “JSON Web Key (JWK),” RFC 7517, May 2015, datatracker.ietf.org.

How does a JWT go post-quantum?

A JWT goes post-quantum by re-signing tokens with a quantum-safe signature algorithm, and as of 2026 the standardized path is ML-DSA. RFC 9964, published May 2026 on the IETF Standards Track, defines how to use ML-DSA (the NIST module-lattice signature standard from FIPS 204) with JOSE and COSE, and registers three new JWS alg identifiers: ML-DSA-44, ML-DSA-65, and ML-DSA-87. Those map to the three FIPS 204 parameter sets at increasing security categories, so a JWT ecosystem swaps its RS256 or ES256 issuer for an ML-DSA-* issuer and keeps the same token structure.

ML-DSA parameter set	FIPS 204 security category	JOSE alg (RFC 9964)	Signature size
ML-DSA-44	Category 2	ML-DSA-44	2,420 bytes
ML-DSA-65	Category 3	ML-DSA-65	3,309 bytes
ML-DSA-87	Category 5	ML-DSA-87	4,627 bytes

Two things carry over from the wider transition:

1. The conservative alternative. Where a hash-based signature is preferred over a lattice one, SLH-DSA is the standardized option, at the cost of much larger signatures. ML-DSA is the general-purpose default for the same reasons NIST chose it as the primary signature standard.
2. Hybrid during the overlap. For a transition period, composite or parallel signatures pair a classical algorithm with ML-DSA so both a legacy verifier and a post-quantum-aware verifier can each validate what they understand. This is the hybrid pattern applied to token signing, and an IETF draft for PQ/T composite signatures in JOSE and COSE was in progress in 2026.

The token format itself doesn’t change. RFC 7519’s three-part structure and the registered claims stay exactly as they are. What changes is the alg in the header, the key type at the issuer, and every verifier’s ability to recognize the new algorithm.

Source: M. Prorock, O. Steele, R. Misoczki, M. Osborne, C. Cloostermans, “ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE),” RFC 9964, May 2026, datatracker.ietf.org.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, csrc.nist.gov.

What does migrating JWT signing actually look like?

Migrating JWT signing is an issuer-and-verifier coordination problem, because a token signed with a new algorithm is only useful if every party that validates it recognizes that algorithm. A signed token is a one-to-many trust relationship, one issuer, many verifiers spread across services, gateways, SDKs, and sometimes vendor platforms, and the migration succeeds only when the verifiers can accept the new signature before, or at the same time as, the issuer starts producing it.

The defining features in practice:

1. Verifier support gates the switch. If an issuer starts signing with ML-DSA-65 but a downstream API’s JWT library doesn’t understand it, that API rejects every token and breaks. So verifier upgrades come first, then the issuer flips, which is why parallel or hybrid signing during the overlap is valuable, old verifiers keep validating the classical signature while new ones validate the ML-DSA one.
2. Issuer signing keys are high blast radius. One central issuer’s key underwrites the entire token population that trusts it, so it belongs near the front of any prioritization. The blast radius of a token-signing key is measured by how many services, users, and privileged operations trust tokens from that issuer, and for a primary identity provider that number is often the whole estate.
3. Vendor-controlled issuers move on the vendor’s clock. A large share of token issuance runs on surfaces the enterprise doesn’t directly control, SaaS identity providers, managed authorization servers, cloud IAM, third-party auth SDKs. For those, ML-DSA signing arrives when the provider ships it, so the timeline depends on vendor roadmaps as much as on internal work.
4. Token size is a real deployment trap. An ML-DSA-65 signature is 3,309 bytes where an ECDSA P-256 signature is a small fraction of that, and JWTs frequently travel in an HTTP Authorization header. Post-quantum signatures push token size up by kilobytes, which can collide with header-size limits in proxies, gateways, and web servers, and with cookie-size limits where tokens are stored in cookies. The size jump is the JWT analog of the oversized-ClientHello trap in TLS, and it’s what production testing has to catch.

Underneath all of it is a crypto-agility question. An issuer and a validator that can add a new alg, publish a new key at the JWKS endpoint, and retire an old one without a service outage can migrate; a validator with a single hard-coded algorithm has to be re-architected first. The signed-assertion pattern isn’t unique to JWT either, SAML carries the same design, XML assertions signed with RSA or ECDSA, and it inherits the same forge-the-signature exposure and the same fix.

Source: M. Prorock et al., “ML-DSA for JOSE and COSE,” RFC 9964, May 2026, datatracker.ietf.org.

Common misconceptions

1. “JWT is broken by quantum computers.” The format isn’t broken. One piece inside a signed JWT, the public-key signature, is, and only for tokens signed with RSA or ECDSA algorithms. The three-part token structure and the claims stay exactly the same, and the fix is to change the signing algorithm to ML-DSA.
2. “A JWT is encrypted, so it’s private.” A standard signed JWT is signed rather than encrypted. Anyone who holds the token can base64url-decode the payload and read every claim. Confidentiality comes from encrypting the token (JWE) or from the TLS transport, and the signature proves authenticity while doing nothing for secrecy.
3. “The quantum risk to JWT is that old tokens get read later.” That’s the HNDL story, and it’s the wrong one here. Tokens expire and carry no deferred value, so there’s nothing to harvest. The risk is a forward one, forging fresh tokens once a quantum computer exists, which makes JWT a Non-HNDL trust problem.
4. “Our identity vendor will handle the whole transition.” A vendor handles the issuers and validators it runs, and it moves on its own schedule. The JWTs your own services issue and validate, your gateways, your internal machine-to-machine trust, are yours to migrate, and vendor timelines still have to be pinned down rather than assumed.
5. “We use HMAC-signed tokens, so quantum doesn’t touch us, and we’re done.” HMAC (HS256) really is durable against Shor’s algorithm, so that part is true. The catch is that HMAC’s shared-secret model is a poor fit for decentralized verification and widens the set of parties holding the secret, which is a separate risk to manage on its own terms.
6. “Switching the signature is a config flag.” Changing the issuer’s alg is the easy part. The work is getting every verifier, across services, SDKs, gateways, and vendor platforms, to accept the new algorithm first, and handling the larger token size in headers and cookies along the way.

Questions people ask

What actually changes in a JWT for post-quantum? The signing algorithm changes, from a classical one like RS256 or ES256 to a post-quantum one like ML-DSA-65, now standardized for JOSE by RFC 9964. The token’s three-part structure and its claims stay the same. The issuer signs with a new key type, and every verifier needs to recognize the new algorithm.

Do I have to rewrite my applications? Usually not the application logic. The change lands in the issuing service, the token-validation library or middleware, and the key configuration. As long as your JWT library adds ML-DSA support and your validators aren’t hard-wired to one algorithm, application code generally stays put.

Is a forged JWT a harvest-now-decrypt-later problem? No. Tokens expire and have no value after the fact, so there’s nothing worth recording. The risk is forging new tokens once a quantum computer can break the signature, which is a live authentication and authorization problem, a Non-HNDL risk, not a stored-data one.

Which JWT signing algorithms are safe against quantum computers? The HMAC family (HS256, HS384, HS512) is safe against Shor’s algorithm because it’s symmetric, though it carries shared-secret tradeoffs. The RSA and ECDSA families (RS*, PS*, ES*) are the vulnerable ones. The post-quantum replacement for the public-key case is ML-DSA.

Why are token-signing keys often missed in a crypto inventory? Because they’re usually owned by identity or platform teams and published as raw keys at a JWKS endpoint, not as X.509 certificates in a certificate store. An inventory scoped to “certificates and PKI” walks past them, so token-signing has to be brought into scope deliberately.

How urgent is migrating JWT signing compared to TLS? They’re urgent for different reasons. TLS key exchange is urgent because harvested traffic is decryptable later, so the clock is already running. JWT signing is urgent because the blast radius of a forged issuer key is enormous and the exposure becomes total the day forgery is possible, so central, high-privilege issuers belong near the front of the plan.

Will post-quantum JWTs be bigger? Yes. An ML-DSA-65 signature is about 3,309 bytes where an ECDSA P-256 signature is a small fraction of that, so tokens grow by kilobytes. That matters because JWTs ride in HTTP Authorization headers and cookies, both of which have size limits that larger tokens can exceed, so header and cookie sizing is part of the migration testing.

Does encrypting a JWT solve the quantum problem? Only a different piece of it. Encrypting a token (JWE) protects the claims’ confidentiality and, if it uses a quantum-safe key establishment, closes an HNDL exposure. It does nothing about a forgeable signature, which is the dominant JWT risk, so signed tokens still need a post-quantum signature regardless.

---

Everything here is the map, given freely. When your team needs its token-signing keys found across every issuer and gateway, its JWT exposure prioritized by blast radius, and an ML-DSA migration sequenced so no verifier breaks, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.