In August 2024, the National Institute of Standards and Technology finalized the first post-quantum cryptography standards in history. It was the result of an eight-year selection process involving cryptographers from around the world.
Most developers missed it entirely.
That's not a criticism — it happened quietly, buried under the usual noise of framework releases and AI announcements. But the implications for the code you're shipping today are significant, and the window to act is shorter than most people think.
What NIST actually published
Three standards. The one that matters most for developers building APIs and authentication systems is FIPS 204, which specifies ML-DSA — Module Lattice-based Digital Signature Algorithm.
ML-DSA comes in three variants: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The numbers roughly correspond to security levels. ML-DSA-65 is the sweet spot for most production use cases — NIST security level 3, reasonable signature size, fast enough for high-throughput APIs.
The other two standards cover key encapsulation (ML-KEM, formerly Kyber) and a hash-based signature scheme (SLH-DSA). Important, but less immediately relevant if your primary concern is signing tokens and verifying identity.
Why your current signatures are vulnerable
If you're using JWT today — and most APIs are — you're almost certainly signing with RS256 (RSA) or ES256 (ECDSA). Both of these rely on mathematical problems that are hard for classical computers to solve: integer factorization for RSA, discrete logarithm for ECDSA.
Peter Shor published an algorithm in 1994 that solves both of these problems efficiently on a quantum computer. A sufficiently powerful quantum computer running Shor's algorithm can break RS256 and ES256. Not slowly — efficiently.
The natural response is: "quantum computers aren't powerful enough yet, so why does this matter now?"
Two reasons.
Harvest now, decrypt later. Nation-state actors are already recording encrypted traffic and signed tokens today, storing them for future decryption once quantum hardware is available. If you're signing anything with a long-term security requirement — contracts, compliance records, device certificates, financial transactions — those signatures are already being collected.
Migration takes years. Updating cryptographic primitives across a production system isn't a one-afternoon job. It touches every service that signs or verifies tokens, every client that stores them, every integration that depends on the format. The teams that start now will be ready when quantum computers arrive. The teams that wait will be scrambling.
Estimates for cryptographically relevant quantum computers range from 10 to 20 years. That sounds comfortable until you factor in that large-scale migrations typically take 3 to 7 years.
What "post-quantum resistant" actually means
ML-DSA is based on the hardness of lattice problems — specifically Module Learning With Errors (Module-LWE) and Module Short Integer Solution (Module-SIS). Unlike RSA and ECDSA, no known quantum algorithm provides a significant speedup against these problems.
This doesn't mean ML-DSA is unbreakable. It means that the best known attacks — classical or quantum — require computational effort that scales in a way that makes them infeasible for any realistic adversary. That's the same bar RSA and ECDSA were held to before Shor's algorithm changed the picture.
The signatures are larger than ECDSA signatures — an ML-DSA-65 signature is around 3.3 KB compared to 64 bytes for ES256. For API tokens and document signing, this is a manageable tradeoff. For TLS handshakes at massive scale, it requires more careful consideration.
What this means for your code today
If you're building a new system, there's no good reason to start with RS256 or ES256. The post-quantum alternatives are standardized, implemented in audited libraries, and ready for production.
If you have an existing system, the migration path depends on your architecture. The core change is replacing the signing and verification step — the token format, the payload structure, and everything else can stay the same. The hard part is coordinating the rollout across services that need to verify tokens issued under the old scheme during the transition period.
The practical checklist:
- Audit where you're generating signatures today (JWT issuance, document signing, webhook signatures, device authentication)
- Identify which of those have long-term security requirements vs. short-lived session tokens
- Prioritize migration for anything with long-term requirements
- For new projects, start with ML-DSA-65
The tooling gap
Here's the honest state of things: the tooling for post-quantum signing is still catching up.
Most JWT libraries don't support ML-DSA yet. HSMs are adding support gradually — the standard only finalized in August 2024, so hardware vendors are still shipping firmware updates. Key management services from the major cloud providers are on their roadmaps but not universally available.
The clearest path for most developers right now is using an audited implementation of ML-DSA-65 directly — the @noble/post-quantum library is a well-regarded option — or using a managed signing service that handles the key management and infrastructure.
What I built
After going through this migration problem myself, I built FIPSign — a signing API that lets you sign any payload with ML-DSA-65 without managing keys, running infrastructure, or calling sales.
The API is simple: you pass a payload with a sub field identifying the entity, get back a quantum-resistant signed token. Verification checks the ML-DSA-65 signature, token expiry, and a revocation list. Revocation is built in — something JWT alone doesn't give you.
import { PQAuth } from 'fipsign-sdk'
const pq = new PQAuth('pqa_your_api_key')
const { token } = await pq.sign({
sub: 'user_123',
role: 'admin',
expiresInSeconds: 3600,
})
const { valid, payload } = await pq.verify(token)
It's not the only path to ML-DSA-65 in production — but it's the fastest one I know of if you want to start signing with a post-quantum algorithm today without building key management from scratch.
10,000 free tokens per month, no credit card. SDK for JS/TS and Python, REST API for everything else. Full guide at fipsign.dev/guide.
The August 2024 publication was a quiet moment that most developers scrolled past. The cryptographic community has been working toward this for eight years. The standards are finalized, the libraries exist, and the threat — while not immediate — is real enough that waiting is a decision with consequences.
The best time to start was August 2024. The second best time is now.
