Your handshake already went quantum-resistant and nobody told you
Open a TLS connection to Google or Cloudflare right now and the key exchange protecting it is already post-quantum. It has been for over a year. Chrome and Firefox turned on X25519MLKEM768, a hybrid of classic X25519 and NIST's ML-KEM, by default back in late 2024. Most operators on the receiving end never edited a config file. Their CDN did it for them, quietly, the way these things usually happen.
If you run your own edge, you might not have gotten the free ride. Check what your server actually negotiates:
openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>/dev/null \
| grep -i "Negotiated TLS1.3 group"
OpenSSL 3.5 or newer prints Negotiated TLS1.3 group: X25519MLKEM768 if the server agreed. Nothing back means you fell through to plain X25519, and any traffic captured today is sitting in someone's "harvest now, decrypt later" bucket, waiting for a machine that can break it.
That is the part of the transition that went well. Now the ugly part.
The certificates are the piece that doesn't fit
Key exchange was the easy win because it is throwaway. You negotiate a fresh one every handshake, both sides upgrade on their own schedule, and nobody has to trust a new signature to make it work. Certificates are the opposite of throwaway. They get signed by a CA, chained through intermediates, logged, cached, sometimes pinned, and they are expected to validate on clients you will never patch.
Swapping the algorithm underneath all of that is where it falls apart. And it falls apart for a boring reason. Size.
Why you can't just swap ECDSA for ML-DSA
The numbers are unforgiving. Here is what one signature costs:
- ECDSA-P256: 64 bytes
- RSA-2048: 256 bytes
- ML-DSA-44: roughly 2,420 bytes
A normal Web PKI handshake carries around five signatures and two public keys. The leaf. The intermediate. An SCT or two. The handshake signature itself. Replace every one of those with an ML-DSA equivalent and, by Let's Encrypt's own math in A Post-Quantum Future for Let's Encrypt (Andrew Gabbitas, June 3, 2026), a single handshake lands "well past 10 kilobytes."
Ten kilobytes sounds like nothing until you remember TCP slow start and a flaky mobile link. Cloudflare's measurements found that at that payload size a real share of connections fail outright on live networks, and the ones that survive just get slower. You don't beat the quantum threat by making TLS fall over on a train.
So "issue ML-DSA certs and move on" is not a plan. The standard for doing it already exists. RFC 9881 defines exactly how ML-DSA goes into an X.509 certificate, and it was published in October 2025. It is real. You can generate one this afternoon. It simply does not scale to the public web at these sizes. The right standard, the wrong job.
Merkle Tree Certificates, briefly
The path Let's Encrypt actually committed to is Merkle Tree Certificates, or MTC. The design comes out of the IETF draft draft-davidben-tls-merkle-tree-certs, written by David Benjamin and Devon O'Brien at Google with help from Cloudflare and Geomys, now picked up as a working-group item.
The trick is to stop signing certificates one at a time. A CA gathers a batch, builds a Merkle tree over the whole batch, and signs only the root. Each subscriber's proof is a short inclusion path up that tree instead of a full 2,420-byte signature. Browsers fetch the signed roots ahead of time, out of band, the same way they already pull CRLite filters and root-store updates. Let's Encrypt calls those roots "landmarks." When you connect, the server hands over one signature, one public key, and one inclusion proof.
There is a fallback for when a client's landmarks are stale. MTC drops back to a "standalone" form with a bigger handshake, so the worst case is that same 10KB problem, not a hard failure. The whole bet is that the worst case stays rare.
Transparency stops being a bolt-on
This part should interest anyone who monitors CT logs. Today, Certificate Transparency is external machinery welded onto issuance after the fact. A CA logs a precertificate, collects an SCT, staples it in. A cert can, in principle, exist without ever being logged. Misissuance investigations exist precisely because that gap is real.
With MTC a certificate is a leaf in a published tree. There is no certificate outside the tree. Transparency is not a policy the CA promises to follow, it is the data structure the certificate lives in. If you have built alerting on CT feeds, and if you haven't, that's still the cheapest early-warning system you can wire up, the shape of what you consume shifts a little. The reason you consume it gets stronger.
Revocation and ACME both have to move
None of this is free operationally, and the two places it bites are the two you already fight with.
Revocation first. MTC certificates are short-lived by design, which leans harder on expiry as revocation than on CRLs or OCSP. That matches where the ecosystem is already heading. OCSP is being retired, and the browsers have already rebuilt revocation around CRLite anyway. Practically, it means your "we'll just revoke it" incident runbook keeps getting thinner.
Then ACME. The protocol that renews most of your certs assumes a request-then-response model. Ask, validate, get a cert back now. Batching into a Merkle tree does not map cleanly onto "give me a cert this second." Let's Encrypt said it plainly: issuance infrastructure, ACME, revocation tooling, and transparency-log infrastructure all need work. Your ACME client will have to learn a new issuance flow. And if your renewal automation is already brittle, and most people's is, that is one more thing waiting to break it.
"2027" is not a synonym for "later"
Here is the timeline Let's Encrypt published. A staging environment issuing MTCs in late 2026. A production-ready environment in 2027. Reads like something you can shelve until 2027, right?
Don't. The migration you can't defer isn't MTC at all. It's the key exchange, and it is live now. Every day a server of yours negotiates classic-only X25519 is another day of captured traffic that "harvest now, decrypt later" gets to keep forever. Authentication has a longer runway because you can't forge a signature backwards in time. A quantum computer that shows up in 2032 cannot sign a certificate your client trusted and threw away in 2026. Confidentiality gets no such grace. That asymmetry is the entire reason key exchange shipped first and certificates are taking their time.
What to actually do this quarter
You don't need to touch MTC yet. You do need to stop being the server still stuck in 2023.
Turn on hybrid key exchange. On OpenSSL 3.5+ behind nginx:
ssl_ecdh_curve X25519MLKEM768:X25519:secp256r1;
Put the hybrid group first, keep the classic ones behind it for old clients. Then verify it with the s_client command from the top instead of trusting your own config file.
Get onto OpenSSL 3.5, or a TLS library that speaks ML-KEM. If your distro is pinned to 3.0, that is the real blocker, and it is a patching problem, not a cryptography problem.
Keep your issuance CA-agnostic. The MTC shift is going to reward operators whose automation is not welded to one CA's exact flow. Same argument as the single-CA risk one, now with a protocol migration bolted to the side of it.
And keep watching CT. The feed is about to get more authoritative, not less.
The certificates will sort themselves out over the next couple of years, in standards rooms, mostly without you in the room. The key exchange is your job. It was your job eighteen months ago.
Frequently asked questions
Do I need to replace my certificates with ML-DSA ones right now? No, and you mostly can't in a way that helps. RFC 9881 lets you put ML-DSA into an X.509 certificate today, but the public CAs are not issuing them at scale because the handshake sizes are unworkable, and the browser path forward is Merkle Tree Certificates rather than raw ML-DSA. The urgent action is post-quantum key exchange, not post-quantum certificates.
What is X25519MLKEM768 and how do I know if I have it?
It is a hybrid key exchange that combines classic X25519 with the post-quantum ML-KEM-768, so a break in either one alone does not sink the session. Run openssl s_client -connect yourhost:443 -groups X25519MLKEM768 with OpenSSL 3.5 or newer and look for the line Negotiated TLS1.3 group: X25519MLKEM768 in the output.
Why does post-quantum key exchange matter before post-quantum signatures? Because of "harvest now, decrypt later." Traffic captured today can be stored and decrypted once a quantum computer exists, so your confidentiality is exposed retroactively. A signature can't be forged backwards in time, since a future quantum computer can't sign a certificate your client already stopped trusting, so authentication has more runway to migrate.
Will Merkle Tree Certificates break my monitoring and ACME setup? Some of it will need to change. MTC alters the issuance flow that ACME assumes and leans on short lifetimes instead of traditional revocation, so ACME clients and renewal tooling will ship updates you have to adopt. CT monitoring actually gets stronger, because transparency becomes part of the certificate structure itself rather than a separate log you hope the CA used.
When is this actually happening? Let's Encrypt plans an MTC staging environment in late 2026 and a production-ready one in 2027, and the underlying IETF drafts are still being finalized. Treat 2027 as real for the certificate side, and treat the key exchange as already overdue.
