Picture a quantum computer big enough to forge the signature on google.com's certificate. It doesn't exist yet. When it does, every RSA and elliptic-curve cert on the web turns into a bad photocopy anyone can fake. The fix the industry keeps landing on is ML-DSA, the lattice signature NIST standardized as FIPS 204 back in 2024, and on July 9 Cloudflare wrote the bluntest version of the argument: stop waiting for a prettier algorithm and ship this one. We've watched the post-quantum encryption side get quietly solved already. Signatures are the half that's still dragging, and they're the half that has to be in place before the quantum computer shows up, not after. Here's what ML-DSA actually costs you, in bytes and in verify time, and why the smaller options everyone keeps pointing at won't save you in time.
The short answer
A big enough quantum computer would forge today’s RSA and elliptic-curve certificates. The industry’s answer for signatures is ML-DSA, standardized as FIPS 204. On July 9 Cloudflare made the case to deploy it now rather than wait for the smaller schemes NIST is still building. The price is size, not security. You aren’t migrating this week, but it’s worth knowing where you sign things.
What ML-DSA is, and why it’s the default
Short version. ML-DSA is a post-quantum signature algorithm NIST published as FIPS 204 in August 2024. You may know it by its competition name, Dilithium. It’s lattice-based, so the math that lets a quantum computer chew through RSA and elliptic-curve keys doesn’t apply to it. That’s the whole point: a signature that still means something after “Q-day”, the hypothetical morning a quantum machine can forge classical certificates.
Here’s the part people miss. Post-quantum encryption is mostly a solved problem already. If you opened a connection to a modern site today, there’s a good chance the key exchange used ML-KEM under the hood and you never noticed. Signatures are the other half, and they’ve lagged. Cloudflare’s July 9 post put it plainly: signatures are the harder migration, and they have to land before the threat is real, not after, because you can’t retroactively re-sign the world’s certificates once a quantum computer is forging them.
The cost is size, not security
This is the honest catch, and it’s a big one. ML-DSA is safe. It’s also fat.
An Ed25519 signature is 64 bytes. ML-DSA-44, the smallest ML-DSA parameter set, is 2,420 bytes, with a public key of 1,312 bytes against Ed25519’s 32. Step up to ML-DSA-65 and you’re at 3,293 bytes. That balloons the moment you put it in a real TLS handshake, because a certificate carries a signature, and a chain carries several, plus certificate-transparency proofs on top. Independent figures for a depth-two chain with ML-DSA-65 put the on-wire certificate overhead around 17,500 bytes, versus a few hundred today. Every handshake pays that, every time.
Bytes aren’t the only tax. Verification is where your servers and clients spend time, and it’s a touch slower than the fastest classical curves. Not a wall, but not free either. For a busy edge, small per-handshake costs add up across billions of connections, which is exactly why a company like Cloudflare cares about the difference between a 666-byte signature and a 2,420-byte one.
Then why not wait for the small one?
Because “the small one” is a 2033 problem, maybe later. NIST kicked off a second round for signatures precisely because ML-DSA is chunky, and there are nine candidates in play. FN-DSA (Falcon) gives you a 666-byte signature, which is gorgeous by comparison. SQIsign is tiny, 148 bytes. The multivariate schemes go smaller still on the signature while paying it back in monstrous public keys.
The problem isn’t the math. It’s the calendar. Cloudflare’s read is that FN-DSA won’t be standardized before roughly 2033, and the multivariate options push into 2034 and beyond. Their own deployment target for post-quantum signatures is 2029. Do the subtraction: if you wait for the pretty algorithm, you miss your own deadline, and migrations of this size take years to roll through every browser and CA, plus a long tail of embedded devices you forgot you own. So the argument is almost boring in its logic. Ship the one that’s standardized, eat the extra bytes, and swap later if something better actually ships. I think that’s right, even if it stings to deploy the fat option knowing a leaner one is theoretically coming.
What this means for you
Probably nothing you touch this week.
There’s no ML-DSA button to press on your cert renewal yet, and browser plus CA support for these certificates is still landing. What you can do is cheap: map where you actually rely on signatures. TLS certificates, obviously. But also code signing, the firmware on your boxes, any token your systems take on trust. That’s the surface that has to move eventually, and knowing its shape now beats discovering it under deadline. If you want to sanity-check what your endpoints serve today, our SSL Certificate Checker reads back the chain and expiry, and if you’re still fuzzy on where TLS versions sit, the TLS 1.2 versus TLS 1.3 breakdown covers the handshake this all rides on.
The honest read
ML-DSA winning isn’t a story about the best algorithm. It’s a story about the only one that’s ready, and a clock that doesn’t care about elegance. The signatures are big, verification costs a little more, and a leaner scheme is sitting in a NIST queue looking better on paper. None of that changes the call, because a signature you can deploy in 2029 beats a smaller one you can’t touch until 2033. Watch for CA and browser support to firm up over the next year or two. That’s the signal that this stops being a whitepaper argument and starts being a renewal option you’ll actually pick.
Sources: Cloudflare’s post on why we cannot wait for better post-quantum signatures (July 9, 2026), and NIST’s official standard FIPS 204 (ML-DSA), published August 2024. Signature and key sizes are from the FIPS 204 parameter sets; the 2033 and 2029 timelines are Cloudflare’s stated estimates and targets, not fixed dates.
Frequently asked questions
What is ML-DSA?
ML-DSA is a post-quantum digital signature algorithm, standardized by NIST as FIPS 204 in August 2024. It was known during the competition as Dilithium. It is lattice-based, which means a quantum computer cannot break it the way one would break RSA or elliptic-curve signatures. It is meant to sign things like TLS certificates and firmware so that authenticity survives the arrival of quantum computers.
Why does Cloudflare say to ship ML-DSA now instead of waiting?
Because the alternatives are years away. NIST is still working on nine newer signature schemes, some with much smaller signatures, but the fast-following ones like FN-DSA are not expected to be standardized until around 2033, and multivariate schemes even later. Cloudflare argues that migration takes years by itself and that waiting for a smaller algorithm risks missing the window before quantum attacks become real. ML-DSA is the only option standardized and deployable today.
How much bigger is an ML-DSA signature than an elliptic-curve one?
A lot. An Ed25519 signature is 64 bytes with a 32-byte public key. ML-DSA-44 is a 2,420-byte signature with a 1,312-byte public key, and ML-DSA-65 is 3,293 bytes with a 1,952-byte key. In a real TLS handshake with a certificate chain, that pushes the on-wire certificate data from a few hundred bytes into the tens of kilobytes.
Do I need to migrate my certificates to ML-DSA today?
No. There is no switch to flip yet, and browser plus certificate-authority support for ML-DSA certificates is still rolling out. What you can do now is inventory where you rely on signatures (TLS certs, code signing, firmware, tokens) so you know the surface area, and treat post-quantum signatures as a planned migration rather than a surprise. The post-quantum encryption side, using ML-KEM, is already largely on by default.
Is ML-DSA the same thing as post-quantum encryption?
No, and mixing them up is common. Encryption (key exchange) protects the confidentiality of your traffic, and the post-quantum piece there is ML-KEM, which most modern browsers and servers already negotiate. ML-DSA is a signature scheme, which protects authenticity, proving a certificate or a message really came from who it claims. They are separate problems on separate timelines, and signatures are the one still catching up.
