Merkle Tree Certificates: how Let's Encrypt wants to make the web quantum-safe — without bloating the handshake

Part 1 — For everyone: what this is about

How this article is structured: Part 1 explains, in plain language and with no prior knowledge, what this is about and what it means for you. Part 2 is the technical deep dive with numbers, mechanics and standards.

The padlock and the ID card

When the little padlock appears in your browser, two things happen at once. First, the connection is encrypted — nobody along the way can read along. Second, the website identifies itself: it presents a kind of notarised ID card (the TLS certificate), and your browser checks the signature on it. Encryption protects the content; the ID card protects you from talking to an impostor.

Both halves rest on maths that a sufficiently large quantum computer could one day break. For encryption, time is especially pressing: an attacker can record encrypted traffic today and decrypt it later, once the technology exists („harvest now, decrypt later“). For the ID card the situation is a little more relaxed — a signature has to be forged in real time, i.e. only once a practically usable quantum computer actually exists. But more relaxed does not mean „start later“: new technology takes years to reach everywhere, which is exactly why the industry is starting now.

Why the obvious fix slows the web down

Quantum-safe signatures already exist. The problem is not that they are missing — it is their size. One of the smaller standardised post-quantum signatures is about 38 times larger than what is common today. A normal connection setup (the „handshake“) carries not one but several signatures and keys. Replace them all with the large new ones, and a single handshake grows to over 10 kilobytes.

That sounds like little. At the scale of the entire web it is not: research by Cloudflare shows that at this size a noticeable share of connections fail outright on real networks — and the rest get slower. Slowing every single TLS connection worldwide to guard against a threat that does not yet exist is a bad trade. And defaults are what actually move security on the web.

Let's Encrypt's idea: stamp once instead of millions of times

This is where Merkle Tree Certificates (MTCs) come in, which Let's Encrypt presented on 3 June 2026 as its planned path. The picture: instead of stamping each ID card with its own heavy signature, the certificate authority issues cards in batches and sets a single quantum-safe signature over the whole batch. Your browser keeps these batch signatures (called landmarks) up to date in the background — independently of the actual page visit.

When you then visit a website, it only has to supply a tiny proof that its ID card is part of the known batch. The result is paradoxical and elegant at once: even though quantum-safe methods are used, the connection setup ends up smaller than today. As a pleasant side effect, the public verifiability of certificates („Certificate Transparency“) becomes a built-in property instead of being bolted on afterwards.

What this concretely means for you

For now: nothing. Your Let's Encrypt certificates will continue to be issued and renewed automatically exactly as before. The transition happens over years, not overnight — Let's Encrypt is targeting a staging environment in late 2026 and a production-ready environment in 2027, and before that, standards, browsers, libraries and ACME clients have to follow.

The one thing you should already do today has nothing to do with MTCs but with the more urgent half (encryption): make sure your servers support hybrid post-quantum key exchange (the shorthand is X25519MLKEM768). It protects today's traffic against the „record today, decrypt later“ attack and is one of the highest-leverage, low-effort measures you can take this year. Major browsers and operating systems already support it; often only the server side is missing.

Part 2 — Why authentication is the harder size problem

For years the post-quantum conversation was mostly about encryption, and for good reason: „harvest now, decrypt later“ turns recorded traffic into an immediate risk, whereas forging a signature requires a real, cryptographically relevant quantum computer (CRQC) in real time. That asymmetry has shifted. The NSA's CNSA 2.0 suite has steered national security systems onto a 2030-to-2035 schedule since 2022; NIST's draft IR 8547 would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035; the EU roadmap targets high-risk systems by the end of 2030. In 2026 concrete vendor deadlines were added: Google wants to migrate its services by 2029, Cloudflare followed in parallel, and Go 1.27 added ML-DSA to the standard library. These mandates do not bind the public Web PKI directly, but they set the pace for libraries, browsers and CAs.

The Web PKI is one of the most awkward places for post-quantum signatures — because of size. The bare numbers from the Let's Encrypt post:

A typical Web PKI handshake carries five signatures and two public keys. Replacing them with ML-DSA equivalents pushes a single TLS handshake well past 10 KB. Cloudflare's measurements show the consequence: on real networks a meaningful share of connections then fail outright, and the rest get slower. This is not a tuning problem but a default problem — and defaults move security on the web.

How Merkle Tree Certificates flip the mechanics

The core idea: not every certificate carries its own large post-quantum signature. Instead the CA issues certificates in batches and signs a single cryptographic commitment — the head of a Merkle tree (the „tree head“) — that can cover millions of certificates at once. Because the size of a Merkle proof grows only logarithmically with the number of leaves, even a tree with billions of certificates needs only a few hundred bytes of proof data.

The roles involved:

• The CA signs exactly one post-quantum signature per batch over the Merkle tree head.
• The browser (relying party) keeps these batch signatures — the landmarks — current, and does so out-of-band, separately from the TLS handshake.
• The server in the common case carries only one signature, one public key and one inclusion proof in the handshake — the path through the Merkle tree showing that its certificate hangs under the known, signed tree head. That path is the „few hundred bytes“ part and makes the handshake smaller than today.

For the case where a client's landmark is out of date, there is the „standalone“ form: a slightly larger handshake as a fallback that works without a current landmark. That is the deliberate degradation for the edge case, not the common case.

Certificate Transparency becomes a property of issuance

Today Certificate Transparency is bolted on afterwards: CAs issue certificates, log them separately, and additional signatures (SCTs) ride along in the handshake to attest to that logging. With MTCs, a certificate cannot exist outside the Merkle tree — transparency is intrinsic to issuance. For Let's Encrypt this is not new ground: the organisation has operated CT logs since 2019, and those are append-only Merkle trees — the same data structure MTCs build on, proven in production and at web scale.

The moving parts: standards, experiments, deadlines

• IETF PLANTS working group — formed after a successful BoF at IETF 124 in Montreal, standardising the design. Current status includes draft-ietf-plants-merkle-tree-certs-04 (May 2026). Authors of the underlying draft: David Benjamin and Devon O'Brien (Google), Bas Westerbaan and Luke Valenta (Cloudflare), and Filippo Valsorda.
• Chrome declared MTCs its preferred path for post-quantum certificates on the public web in February 2026.
• Cloudflare and Chrome are already running a feasibility experiment with MTCs against real internet traffic.
• Parallel standards track (explicitly tracked by Let's Encrypt): ML-DSA signatures in X.509 are standardised as RFC 9881; ML-DSA in TLS is progressing as draft-ietf-tls-mldsa.
• Let's Encrypt roadmap: a staging environment issuing MTCs in late 2026; a production-ready environment in 2027. This requires changes across the stack — issuance infrastructure, the ACME protocol (RFC 8555) used by subscribers, revocation and operational tooling, and the transparency-log infrastructure that MTCs subsume.

A note on source discipline: some secondary reports misattribute RFC 9881 to „the ACME protocol“ — RFC 9881 is ML-DSA-in-X.509; ACME itself is RFC 8555.

A sense of scale: Let's Encrypt issued around 54% of all public TLS certificates in the first quarter of 2026. When that actor commits to MTCs, the approach becomes viable for the majority of the encrypted web — that is the real lever behind the news.

What operators and ACME client maintainers should do now

Today

Enable hybrid post-quantum key exchange (X25519MLKEM768) on your servers. It is the most effective immediate measure against „harvest now, decrypt later“ and is independent of MTCs. The browser and OS side are largely ready; the bottleneck is server configuration (TLS termination at the reverse proxy / load balancer / CDN).

Watch

If you maintain an ACME client or run an ACME-driven certificate pipeline, start tracking the PLANTS working group and the mtcs@chromium.org list now. MTCs bring client-side changes; an ACME client that is ready when the issuance side is ready is the cheaper option.

Inventory

Where does your operation depend on ACME automation (cert-manager in Kubernetes, Caddy/Traefik auto-TLS, acme.sh cron jobs, platform integrations)? That list is the map of where client-side adjustments will later be needed. Nothing changes in issuance today — but having the map before you need it is the difference between a planned follow-up and a scramble.

What this means for how I see platforms

I treat crypto agility as a platform property, not a one-off project — the same line I drew in my post on Post-Quantum Security (RFC 9964, ML-DSA). MTCs are a good example: the transition only works if issuance, transport (TLS), transparency and client tooling move together, and the only way to do that without braking the web is to change the mechanics, not just the algorithms. For the stacks I operate this means, concretely: hybrid key exchange live today, ACME paths documented, and the PLANTS / X.509 ML-DSA standards in view, so that the switch — whether MTCs or ML-DSA-signed X.509 certificates are ultimately delivered — becomes a configuration topic and not an emergency.

Sources

• Let's Encrypt — A Post-Quantum Future for Let's Encrypt (Andrew Gabbitas, 03 Jun 2026; primary source)
• Cyber Security News — Let's Encrypt Unveils Merkle Tree Certificates (05 Jun 2026)
• Google Security Blog — Chrome's MTC announcement (February 2026)
• Cloudflare — Another look at PQ signatures (size/failure measurements)
• IETF PLANTS Working Group (MTC standardisation)
• RFC 9881 — ML-DSA in X.509