The number that breaks everything is 2,420
That is the size, in bytes, of a single ML-DSA-44 signature. The post-quantum signature scheme NIST standardized as FIPS 204, the one your certificates will eventually be signed with, produces signatures roughly 38 times larger than the ECDSA-P256 signatures the Web PKI runs on today. The public keys are 1,312 bytes against 64. Nobody is arguing about whether these algorithms are secure against a quantum computer. They are. The argument is about whether you can fit them through a TLS handshake without wrecking it, and the honest answer right now is no.
On June 3, 2026, Let's Encrypt published its plan for this, and the interesting part is what the plan is not. It is not "we'll start signing certificates with ML-DSA." It is Merkle Tree Certificates, a different shape of certificate entirely (HN discussion). That choice tells you how bad the size problem actually is.
Why you can't just swap the algorithm
Picture what a browser validates on a normal HTTPS connection. There's your leaf certificate with its signature. There's the intermediate that signed it, with its own signature. There are Signed Certificate Timestamps proving the cert was logged. Sometimes an OCSP staple. Each of those carries a signature and, somewhere up the chain, a public key.
Today that whole bundle is small. ECDSA signatures are 64 bytes, RSA-2048 signatures 256. Now replace every signature and every key with ML-DSA equivalents. The leaf signature alone jumps to 2,420 bytes. Add the intermediate's signature, the keys, the SCTs signed with the same scheme, and authentication overhead sails past 10 kilobytes on a single connection. That is not a rounding error. TCP's initial congestion window is often ten packets, around 14 KB. Blow past it and the handshake needs extra round trips before the first byte of your page moves. On a slow mobile link that's real, measurable latency, and it happens on every fresh connection.
There's a second problem that has nothing to do with speed. Middleboxes. Plenty of network gear makes assumptions about how big a certificate message can be, and a lot of it predates anyone imagining a 10 KB one. Chrome, Cloudflare and Google have been running feasibility experiments precisely because the failure mode isn't "slower," it's "some fraction of clients can't connect at all." You don't find those clients until you break them.
So the naive migration, keep the PKI exactly as it is and change the algorithm, produces certificates that are both slower and less compatible. That's the wall Let's Encrypt walked into, and Merkle Tree Certificates are how they're trying to walk around it.
Merkle Tree Certificates, in one paragraph
A Certificate Authority issues certificates in batches. Instead of signing each one individually, it builds a Merkle tree over the whole batch and signs the tree's root once. That single signature covers thousands of certificates. Browsers get the signed tree heads, the design calls them landmarks, separately from the TLS handshake, distributed ahead of time the way root stores already are. When your server presents an MTC, the common case sends one signature, one public key, and one short inclusion proof showing your certificate sits in a batch the browser already trusts. The result is smaller than today's handshake even though the underlying signature is post-quantum. And Certificate Transparency stops being a separate system bolted on afterward, because public logging is baked into the tree.
What actually travels on the wire
The expensive part, that 2,420-byte signature, gets amortized. Split one signature across ten thousand certificates and it costs a quarter of a byte each on the wire. What the server actually hands over is the inclusion proof: a short list of hashes showing your leaf sits in a tree the client already vouched for. The math underneath is enormous. The thing on the wire is tiny. That's the whole trick.
Nothing is free, though, and here the price is the distribution model. The browser has to already hold the tree head that covers your certificate. So the CA publishes tree heads, clients pull them on a schedule, and it works exactly like the root updates and Certificate Transparency logs you already sync without thinking about it. The cost didn't vanish. It moved off the connection and into a background job you never see.
The catch nobody should gloss over
Merkle Tree Certificates only help in the common case, and the common case has a precondition: the relying party already knows about the batch your certificate lives in. Freshly issued certificate, a client that hasn't synced recently, an offline verifier, a private trust path? The MTC fast path doesn't apply, and you fall back to a traditional X.509 certificate with a full signature.
Which means MTC is not a replacement for the PKI you run. It's an optimization layered on top of one that still has to exist. You will keep issuing classic certificates for the fallback, and post-quantum ML-DSA-in-X.509 has its own standards track for exactly that: RFC 9881 defines how ML-DSA signatures live inside ordinary X.509 certificates and CRLs. MTC is the thing that makes the common case affordable. It is not the thing that makes the classic case go away.
The timeline you should plan around, not panic about
Let's Encrypt is targeting late 2026 for a staging environment that issues MTCs, and 2027 for production. That's soon enough to matter and far enough that nothing on your servers changes this week. Existing certificates keep working. Your ACME client keeps renewing. When post-quantum issuance is ready it'll be free and automated through the clients you already run, the same way every other Let's Encrypt change has landed.
The reason not to file this under "someday" is that the surrounding deadlines are real and dated. Google wants its own services migrated by 2029. NIST plans to deprecate RSA-2048 and P-256 from 2030 and disallow them after 2035. France's ANSSI said in June 2026 it will stop certifying security products that aren't quantum-safe from 2027, and the NSA's CNSA 2.0 lands PQC requirements for national security systems on a similar schedule. None of those is a certificate you renew, but together they set the pace the whole ecosystem moves at.
This also connects to two changes already in flight. Shorter certificate lifetimes make the logging overhead of classic Certificate Transparency worse, which is part of why baking CT into MTC is attractive, and we covered that schedule in the 47-day certificate lifetime post. And post-quantum signatures can only ride on TLS 1.3, never 1.2, which is one more reason the TLS 1.2 development freeze matters more than it looks.
What to actually do before any of this ships
You can't deploy post-quantum certificates yet. You can stop being the reason they're hard to deploy later. That's a crypto-agility problem, and it's boring in a good way.
Start by knowing what you have. Pull the signature algorithm off a live certificate:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -text \
| grep -i "Signature Algorithm" | head -1
To see what a full chain actually weighs today, which is the number MTC is competing against:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null \
| grep -c "BEGIN CERTIFICATE"
Then look for hardcoding. Anything that pins ecdsa-with-SHA256, assumes a signature is 64 or 256 bytes, or allocates a fixed buffer for a certificate message is a landmine. The tooling is already moving: RFC 9881 is published, pyca/cryptography added ML-DSA X.509 signing in version 49, and Go 1.27 ships an crypto/mldsa package. If you build anything that parses or validates certificates, those are what you test against now, in staging, long before a real MTC shows up.
And keep your ACME clients current. The whole point of the Let's Encrypt approach is that post-quantum issuance arrives through the client you already run. That only works if you're running a version recent enough to have it. An ACME client two years stale is the thing that turns an automated migration into a manual one.
Where monitoring fits, and where it doesn't
Monitoring won't migrate anything, and it shouldn't pretend to. What it does is tell you the truth about your inventory before the deadlines land: which signature algorithms you're actually running, which chains are heavy, which endpoints are still stuck on TLS 1.2 and therefore shut out of post-quantum entirely. That's the dull, useful kind of readiness. The clever kind, rewriting your PKI around a draft that's still at revision four, is how you build something you'll be ripping out in eighteen months.
Frequently asked questions
Do I need to do anything to my certificates right now? No. Existing certificates keep working, your ACME client keeps renewing, and nothing about post-quantum changes what's deployed today. The useful move now is crypto agility, knowing your signature algorithms and removing hardcoded assumptions, not swapping any certificate.
Why not just use ML-DSA certificates directly instead of Merkle Tree Certificates? Size. A single ML-DSA-44 signature is about 2,420 bytes versus 64 for ECDSA-P256, and replacing every signature and key in a normal chain pushes authentication overhead past 10 KB per connection, which hurts latency and breaks size-sensitive network gear. MTC amortizes one large signature across a whole batch, so the common case ends up smaller than today's handshake.
When can I actually get a post-quantum certificate from Let's Encrypt? Let's Encrypt is targeting late 2026 for a staging environment issuing MTCs and 2027 for production. Those dates are goals tied to standards still being finalized in the IETF PLANTS and ACME working groups, so treat them as direction rather than a fixed release date.
Does this mean traditional X.509 certificates are going away? No. MTC only helps when the relying party already holds the batch your certificate belongs to; freshly issued certs, out-of-date clients and private trust paths fall back to ordinary X.509, and RFC 9881 exists precisely to carry ML-DSA in that classic format. MTC is an optimization on top of the PKI, not a replacement for it.
Are my TLS 1.2 endpoints affected? Yes, in the sense that they're excluded. Post-quantum signature schemes are being standardized for TLS 1.3 only, so any client or server still on TLS 1.2 gets no post-quantum path at all. That's one more item on the list of reasons to finish the 1.3 migration.
