By Let’s Encrypt published its formal post-quantum roadmap today, and it’s not what you think. The organization isn’t swapping in a new algorithm and calling it done. It’s rebuilding the architecture of HTTPS certificates from the ground up — because if it doesn’t, quantum-resistant TLS would be slower and less reliable than what we have now. The plan is called Merkle Tree Certificates, and it has a production timeline.
The Size Problem Nobody Warned You About
Post-quantum cryptography comes with a size penalty that most developers haven’t internalized yet. The ECDSA signatures your servers send today are 64 bytes each. The NIST-standardized post-quantum replacement, ML-DSA-44, produces signatures of roughly 2,420 bytes — almost 38 times larger. A typical TLS handshake carries five signatures and two public keys. Do the arithmetic, and you’re looking at handshakes that balloon past 10KB.
That number matters. Cloudflare’s research found that oversized handshakes cause a meaningful share of TLS connections to fail outright on real-world networks, and slow down the rest. For a CA that issues six million certificates per day, “we’ll add some latency” isn’t an acceptable answer.
So Let’s Encrypt isn’t using per-certificate post-quantum signatures at all. Instead, it’s adopting Merkle Tree Certificates.
How Merkle Tree Certificates Shrink the Problem Away
The core idea: instead of signing each certificate individually, the CA signs entire batches of certificates at once with a single signature. Browsers receive these batch signatures — called landmarks — through a separate update channel, decoupled from TLS handshakes entirely. What the server sends in the handshake is a compact Merkle inclusion proof: a path of hashes showing that your certificate is part of the signed batch.
At Let’s Encrypt’s scale, that inclusion proof is about 384 bytes — 12 SHA-256 hashes. One signature plus one inclusion proof fits in a handshake that’s actually smaller than today’s Web PKI overhead, despite using quantum-resistant algorithms. The math works because Merkle trees scale logarithmically: batching a million certificates only requires about twenty hashes per proof.
There’s a bonus: Certificate Transparency is built in by design. Currently, CT requires separate logging after issuance, with additional signatures stuffed into the TLS handshake. With MTCs, a certificate that isn’t in the published tree simply doesn’t exist. As Let’s Encrypt explains in its announcement: “Certificate Transparency is built in.” The organization has operated Merkle tree infrastructure since 2019, so this isn’t greenfield work.
Two Fronts, Two Urgencies
Let’s Encrypt draws a sharp line between encryption and authentication — and developers should too.
Key exchange is urgent now. Nation-state actors are intercepting TLS sessions today and storing the ciphertext to decrypt once quantum computers arrive. This “harvest now, decrypt later” threat means data you encrypt in 2026 could be readable in 2032. The fix is hybrid post-quantum key exchange — specifically X25519MLKEM768, which blends classical and quantum-resistant algorithms. Chrome and Firefox already support it. Let’s Encrypt calls enabling it “one of the highest-leverage things you can do this year.”
For NGINX, it’s a one-line config change:
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;Certificate authentication is not urgent now. Unlike encrypted data, signatures only need to be valid at the moment of verification — you can’t retroactively forge a signature with a future quantum computer. The MTC migration has a deliberate timeline: Let’s Encrypt targets a staging environment in late 2026 and a production-ready rollout in 2027.
What Developers Need to Do
The action items split cleanly by role:
- Server operators (everyone): Enable X25519MLKEM768 key exchange now. OpenSSL 3.5+ and modern NGINX/Apache support it. Check NGINX’s post-quantum configuration guide for full setup. This protects in-flight data against harvest-now-decrypt-later attacks today.
- ACME client maintainers: Start tracking the IETF PLANTS working group (PKI, Logs, And Tree Signatures). Client changes will be needed before MTC issuance begins. The draft is on its third revision.
- Everyone else: Nothing to do yet. Current Let’s Encrypt certificates keep renewing automatically. When MTCs arrive, they’ll roll out “free, automated, and available to anyone with an ACME client” — the same frictionless model as today.
This urgency split is worth emphasizing: if you run a server that handles sensitive user data, enabling hybrid key exchange is not optional anymore. The threat is active. The fix takes five minutes. The VSCode GitHub token vulnerability patched this week is a reminder that security debt compounds fast — don’t let key exchange become the same story.
The Timeline to 2035
Government mandates have set the outer bounds: NIST deprecates RSA-2048 and P-256 after 2030 and disallows them entirely after 2035. The EU targets high-risk systems by 2030. Google and Cloudflare have both publicly committed to migrating their services by 2029.
Let’s Encrypt’s June 3 post slots into that picture: staging in late 2026, production in 2027, years ahead of the mandates. The standards work is advancing — Chrome adopted MTCs as its preferred post-quantum cert approach in February 2026, and Cloudflare is already running pilot MTC deployments on live traffic — which suggests the architecture is solid enough to bet on.
The quantum deadline feels distant. The infrastructure work to meet it is not.
