{"slug": "why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time", "title": "Why I built a post-quantum signing API (and why JWT is on borrowed time)", "summary": "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.", "body_md": "JWT with RS256/ES256 is everywhere. It's also going to be broken.\n\nNot today. But the clock is ticking — and the timeline is shorter than most developers think.\n\nNIST 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.\n\n## The problem with classical signatures\n\nEvery 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.\n\nThe 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.\n\n## What I built\n\nI built [FIPSign](https://fipsign.dev) — a signing API built on ML-DSA-65 (NIST FIPS 204). The idea is simple: you call `/sign`\n\nwith any payload, get back a quantum-resistant token. No infrastructure to manage, no keys to generate or rotate, no DevOps.\n\n```\nconst { token } = await pq.sign({\n  sub: 'user_123',\n  role: 'admin',\n  expiresInSeconds: 3600,\n})\n\nconst { valid, payload } = await pq.verify(token)\n```\n\n## Not just for auth\n\nMost post-quantum signing tools focus only on user authentication. FIPSign lets you sign anything — the only required field is `sub`\n\n, any string identifying the entity:\n\n-\n`sub: \"user_123\"`\n\n— user sessions -\n`sub: \"order_456\"`\n\n— payment intents -\n`sub: \"doc_789\"`\n\n— document certification -\n`sub: \"device_iot_001\"`\n\n— IoT firmware\n\n## How revocation works\n\nRevocation 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`\n\ncall checks that blacklist. Entries expire automatically when the original token would have expired.\n\nLocal verification (`localVerify: true`\n\n) runs entirely in memory at ~1ms with no API call — but doesn't check revocation. Use remote verification for payments and admin actions.\n\n## Why ML-DSA-65 specifically?\n\nML-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.\n\nThe implementation uses [@noble/post-quantum](https://github.com/paulmillr/noble-post-quantum) — a widely audited library you can verify independently.\n\n## One more thing — no subscription\n\nFIPSign 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.\n\nOne 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.\n\n## Try it\n\n```\nnpm install fipsign-sdk\n```\n\nFull guide at [fipsign.dev/guide](https://fipsign.dev/guide). Free account at [app.fipsign.dev](https://app.fipsign.dev) — no credit card.\n\nHappy to answer any questions about the cryptography, the architecture, or the migration path from JWT.", "url": "https://wpnews.pro/news/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time", "canonical_source": "https://dev.to/pqbuilder/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time-1d65", "published_at": "2026-05-22 12:36:31+00:00", "updated_at": "2026-05-22 13:07:33.402506+00:00", "lang": "en", "topics": ["cybersecurity", "developer-tools", "cloud-computing", "products", "research"], "entities": ["FIPSign", "NIST", "Cloudflare D1", "ML-DSA-65", "RS256", "ES256", "RSA", "ECDSA"], "alternates": {"html": "https://wpnews.pro/news/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time", "markdown": "https://wpnews.pro/news/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time.md", "text": "https://wpnews.pro/news/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time.txt", "jsonld": "https://wpnews.pro/news/why-i-built-a-post-quantum-signing-api-and-why-jwt-is-on-borrowed-time.jsonld"}}