Why I built a post-quantum signing API (and why JWT is on borrowed time)

The article explains that JSON Web Tokens (JWTs) signed with current algorithms like RS256 and ES256 are vulnerable to future quantum computer attacks, with nation-state actors already employing "harvest now, decrypt later" strategies. In response, the author created FIPSign, a post-quantum signing API based on NIST's ML-DSA-65 standard, which allows developers to sign any payload with quantum-resistant tokens and includes built-in revocation. The service offers 10,000 free tokens per month, uses the audited @noble/post-quantum library, and aims to provide a simple migration path away from traditional JWT authentication.

JWT with RS256/ES256 is everywhere. It's also going to be broken. Not today. But the clock is ticking — and the timeline is shorter than most developers think. NIST published the post-quantum signature standards in August 2024. AWS KMS added ML-DSA support in June 2025. Microsoft shipped it natively to Windows 11 and .NET in November 2025. The migration window is open — and most backend developers haven't started yet. The problem with classical signatures Every JWT signed with RS256 or ES256 relies on RSA or ECDSA. These algorithms are vulnerable to Shor's algorithm running on a sufficiently powerful quantum computer. NIST finalized the post-quantum replacements in August 2024 — but most developers haven't started migrating yet. The threat isn't just future decryption. Nation-state actors are already harvesting signed traffic today to decrypt and forge once quantum computers arrive. "Harvest now, decrypt later" is a real attack pattern. What I built I built FIPSign https://fipsign.dev — a signing API built on ML-DSA-65 NIST FIPS 204 . The idea is simple: you call /sign with any payload, get back a quantum-resistant token. No infrastructure to manage, no keys to generate or rotate, no DevOps. const { token } = await pq.sign { sub: 'user 123', role: 'admin', expiresInSeconds: 3600, } const { valid, payload } = await pq.verify token Not just for auth Most post-quantum signing tools focus only on user authentication. FIPSign lets you sign anything — the only required field is sub , any string identifying the entity: - sub: "user 123" — user sessions - sub: "order 456" — payment intents - sub: "doc 789" — document certification - sub: "device iot 001" — IoT firmware How revocation works Revocation is built in. When you revoke a token, we store a SHA-256 hash of the ML-DSA-65 signature as a blacklist entry in Cloudflare D1. Every remote /verify call checks that blacklist. Entries expire automatically when the original token would have expired. Local verification localVerify: true runs entirely in memory at ~1ms with no API call — but doesn't check revocation. Use remote verification for payments and admin actions. Why ML-DSA-65 specifically? ML-DSA-65 is NIST security level 3 — the right balance between security and signature size for API use cases. ML-DSA-44 is faster but lower security. ML-DSA-87 produces larger signatures with no practical benefit for most applications. The implementation uses @noble/post-quantum https://github.com/paulmillr/noble-post-quantum — a widely audited library you can verify independently. One more thing — no subscription FIPSign doesn't have monthly plans. You get 10,000 free tokens per month automatically. If you need more, you buy a token pack — they never expire and accumulate across purchases. One account gives you unlimited projects with unlimited API keys per project, each with its own usage stats. Useful if you're managing multiple clients, environments, or microservices from the same account — no enterprise plan required. Try it npm install fipsign-sdk Full guide at fipsign.dev/guide https://fipsign.dev/guide . Free account at app.fipsign.dev https://app.fipsign.dev — no credit card. Happy to answer any questions about the cryptography, the architecture, or the migration path from JWT.