The Quantum Clock Is Ticking How JWT and JOSE Are Evolving for a Post-Quantum World
JSON Web Tokens (JWT) are everywhere. They secure API calls, authenticate users across microservices, and underpin the identity layer of modern web applications. But the cryptographic foundations that make JWTs trustworthy, like RSA and elliptic curve signatures, face a serious threat. Quantum computing could break them. The race to retrofit the JWT and JOSE ecosystem for a post-quantum future is under way. The IETF is at the centre of it.
What Are JSON Web Tokens?
A JSON Web Token (JWT, pronounced ‘jot’) is a compact, URL-safe token format defined in RFC 7519. It provides a standardised way of securely transmitting claims – structured pieces of information – between two parties. A JWT has three Base64URL-encoded parts. These parts are separated by dots. The header shows the token type and signing algorithm. The payload holds claims, like user identity, permissions, and expiry time. The signature uses cryptography to prove the token was not changed after it was issued.
JWTs are signed using symmetric algorithms, such as HMAC-SHA256. In many enterprise settings, asymmetric key pairs are used, such as RSA or ECDSA. This signature gives JWTs their power. A service can verify a token’s authenticity and integrity. It does not need to call the issuing server. This stateless design makes JWTs easy to scale. That is why they are now the main token format. They are widely used in OAuth 2.0, OpenID Connect, and modern API authentication.
Why JWTs Are Critical for Financial Services
In financial services, JWTs are not just convenient. They are a core security tool. Banks, insurers, payment firms, and fintechs use them every day. Their importance spans several critical areas.
Open Banking and Regulatory Compliance. The Financial-grade API (FAPI) security profiles are developed by the OpenID Foundation. They are used across Open Banking ecosystems in the UK, EU, Brazil, and beyond. They require signed and encrypted JWTs at several points in the authorisation flow. Under PSD2 in Europe, and under similar rules worldwide, each data-sharing request is secure. A third-party provider sends the request to a bank. The bank protects the request. It uses JWT-based request objects and JWT-secured authorisation responses (JARM). These JWT exchanges ensure non-repudiation, tamper protection, and client authentication. Traditional API keys or shared secrets cannot provide this level of security.
API-Driven Architectures. Modern financial institutions run on microservices. A single payment may go through several internal services. These can include fraud checks. They can also include KYC checks. The payment may then trigger ledger updates. It may also send notifications. Each service must authenticate and authorise the request. JWTs package trust data in a self-contained, verifiable token. This removes the need for each service to query a central session store. It also supports the horizontal scaling that financial platforms need.
Single Sign-On and Identity Federation. Large financial groups often operate multiple customer-facing brands and back-office platforms. JWTs support single sign-on (SSO) across these properties. They let customers and employees sign in once.They can then access multiple systems with ease. The token-based model is also essential for identity federation with external partners, insurers, and payment networks.
Mobile and Digital Banking. The small size and stateless design of JWTs make them ideal for mobile banking apps. Lightweight token exchange with back-end APIs is key for performance. Every balance check, transfer initiation, and biometric re-authentication in a modern banking app relies on JWT-secured communication.
In short, JWTs sit at the heart of trust in digital financial services. If the cryptographic algorithms that sign and encrypt those tokens are compromised, quantum computing may cause it. The consequences for the financial sector would be systemic. This is why the evolution of JWT and JOSE for post-quantum cryptography is not an academic exercise. For FSS organisations, it is an operational imperative.
How organisations should prepare for post-quantum cryptography
Why Post-Quantum Cryptography Matters for JWT
JWTs use the JSON Object Signing and Encryption (JOSE) framework.JOSE is a set of IETF standards, called RFCs 7515 to 7518. These standards define how tokens are signed (JWS) and encrypted (JWE). They also define how keys are represented (JWK). Today, most JWTs use RSA or ECDSA signatures. A powerful quantum computer could break these using Shor’s algorithm. The danger is not hypothetical. Nation-states and skilled adversaries already harvest encrypted traffic in “store now, decrypt later” attacks. They bet that future quantum machines will crack today’s secrets.
This is why NIST launched its Post-Quantum Cryptography Standardisation Project in 2016. It evaluated 82 candidate algorithms from 25 countries. After years of careful review, NIST published its first three final PQC standards on 13 August 2024. These were FIPS 203 (ML-KEM, from CRYSTALS-Kyber) for key encapsulation. FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) covers digital signatures. FIPS 205 (SLH-DSA, from SPHINCS+) is a hash-based backup for signatures. A fourth standard based on FALCON (FN-DSA) is still in development, and HQC was selected for standardisation in March 2025.
The IETF Brings PQC to JOSE and JWT
With NIST’s algorithms now finalised, the IETF must wire them into the protocols the internet uses. This work includes JOSE. Several active Internet-Drafts are charting this course.
The draft for JOSE and COSE Encoding for Post-Quantum Signatures defines how to serialise ML-DSA and SLH-DSA. It defines them as JWS algorithm identifiers.It also registers them as new key types in JWK. It explains how to use them to sign JWTs. A new key type value, ‘PQK’ (Post Quantum Key Pair), has been proposed.It sits alongside algorithm identifiers. These map cleanly to NIST’s parameter sets and security levels.
On the encryption side, the PQ KEMs for JOSE and COSE draft explains how to use ML-KEM in JWE. It covers direct key agreement and key agreement with key wrapping. It defines identifiers for ML-KEM-512, ML-KEM-768, and ML-KEM-1024. This brings lattice-based key encapsulation into the JWT encryption workflow.
There is also more work on hybrid approaches. These combine a classical algorithm like ECDH with a post-quantum KEM. This means security can still hold even if one method is broken. The draft on PQ/T Hybrid KEMs for HPKE with JOSE and COSE tackles this directly. It reflects a widely held engineering view that defence in depth is prudent. This is especially true during a transition period.During this period, confidence in new algorithms is still maturing.
Challenges on the Road Ahead
Adapting JOSE for PQC is not a simple algorithm swap. Post-quantum signatures and keys are much larger than classical ones. An ML-DSA signature can be several kilobytes. An ECDSA signature is often only a few hundred bytes. Beyond the cryptographic design itself, these larger signature sizes introduce practical operational considerations. Many API gateways, reverse proxies, and load balancers enforce strict HTTP header size limits. JWT-based authentication flows rely on these limits. Larger tokens can therefore impact compatibility with existing infrastructure, mobile client performance, and high-frequency API environments such as financial trading systems. Designing with crypto-agility in mind – allowing algorithm identifiers and validation logic to evolve without rewriting token infrastructure – becomes essential for a smooth transition. For JWTs that travel in HTTP headers or compact URLs, this size increase has real protocol implications.
The IETF’s PQUIP (Post-Quantum Use in Protocols) working group is leading the wider effort. It tracks how ready each major security protocol is for PQC. As one talk at the 2025 PQC Conference put it, the work is about half new algorithm registration. The other half is redesigning protocol machinery to fit the very different traits of post-quantum primitives.
Cryptographic Visibility: The Missing Foundation
Venari’s Adaptive Cryptographic Intelligence Platform gives organisations the visibility they need before any migration can begin.
The greatest barrier to post-quantum migration is not the cryptography itself – it is visibility. Most organisations cannot produce a comprehensive inventory of the cryptographic algorithms, cipher suites, and key agreements running across their infrastructure. Without that inventory, migration planning is guesswork.
Venari Security’s Adaptive Cryptographic Intelligence Platform addresses this gap directly. It passively monitors TLS traffic at the network layer. It maps every cryptographic exchange across all endpoints. It does this without agents or active scanning. The result is a live cryptographic inventory. It is the key foundation in both the G7 PQC roadmap and NCSC guidance. Both list it as the first critical step.
Venari helps organisations move beyond static compliance checks to continuous cryptographic assurance. It finds quantum-vulnerable assets, sets remediation priorities, and validates progress. It aligns progress with NIST post-quantum standards and frameworks like DORA and NIS2. As Venari CEO Tom Millar has emphasised, cryptographic resilience is fundamentally a governance and visibility problem before it becomes a cryptographic one. For organisations moving from RSA- and ECDSA-signed JWTs to ML-DSA or hybrid PQC tokens, the same rule applies.
You cannot migrate what you cannot see.
As Venari CEO Tom Millar has emphasised, cryptographic resilience is fundamentally a governance and visibility problem before it becomes a cryptographic one.
Venari offers free PQC readiness checks. It also provides cryptography maturity reviews. And Venari creates tailored migration roadmaps that match NCSC timelines. This helps clients take action early, rather than just reacting to the quantum threat. They are preparing for it in a clear, steady way. They do so with confidence and a plan they can defend.
Act Now
NIST’s message is unambiguous: organisations should begin integrating these algorithms immediately. For teams that build on JWT and JOSE, that means taking concrete steps now.
First, track the IETF drafts. The Internet-Drafts for JOSE PQC signatures and PQ KEMs are still evolving. To stay current, subscribe to the IETF JOSE and COSE working group mailing lists.
Second, experiment with PQC-capable libraries. Open-source implementations can be a practical starting point.These include Open Quantum Safe (liboqs). They also include Bouncy Castle (version 1.78 or later, with ML-DSA and ML-KEM).Another option is the NIST reference code. They help you prototype PQC-signed JWTs in a development environment.
Third, plan for crypto agility. Design your systems so signing algorithms, key types, and key lengths can be changed in configuration. Avoid code changes. This is the single most valuable architectural investment you can make before the standards are finalised.
Finally, build your cryptographic inventory. Partners like Venari Security can give the visibility and clear migration roadmaps you need. This can turn a complex, multi-year transition into a manageable programme of work. The quantum clock is ticking, and the standards are no longer hypothetical.
Ready to transform your security approach?
New to some of the terminology in this story? Explore our glossary of terms to quickly understand the key concepts used throughout this article.