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

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 — 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 — 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. Free account at app.fipsign.dev — no credit card.

Happy to answer any questions about the cryptography, the architecture, or the migration path from JWT.