The nonprofit that secures more than 500 million websites with free TLS certificates published a detailed post-quantum migration roadmap June 3, 2026, and its preferred path solves a problem most operators haven't noticed yet: naively swapping today's signatures for quantum-resistant ones would push a typical HTTPS handshake past 10 kilobytes — and Cloudflare's real-world testing shows that at that payload size, a meaningful share of connections simply fail.
Let's Encrypt, operated by the nonprofit Internet Security Research Group (ISRG), announced that Merkle Tree Certificates (MTCs) are its chosen route to quantum-safe Web PKI. The approach, which batches a post-quantum signature across thousands of certificates at once rather than signing each individually, is already backed by Chrome as its preferred standard and is being tested on live internet traffic by Cloudflare and Google. Let's Encrypt is targeting a staging environment by late 2026 and a production-ready deployment in 2027.
ML-DSA Signatures Are 38 Times Bigger: Why That Breaks the Web
The size problem begins with the math. The dominant NIST-standardized post-quantum signature scheme, ML-DSA-44, produces signatures of approximately 2,420 bytes. The ECDSA-P256 signatures that Web PKI certificates use today are 64 bytes. Public keys expand comparably: 1,312 bytes for ML-DSA-44 against 64 bytes for ECDSA-P256. Those figures come directly from the IETF draft specification for Merkle Tree Certificates.
A typical TLS handshake carries five signatures and two public keys. Replacing all of them with ML-DSA equivalents pushes authentication overhead past 10 kilobytes per connection — roughly two to three times larger than an entire HTML page on many websites, and that overhead arrives before the user sees a single character.
The consequences are not theoretical. Cloudflare researcher Bas Westerbaan documented that approximately five percent of connections failed during early post-quantum key exchange testing, due to middleboxes — firewalls, load balancers, and intrusion detection systems — that cannot handle oversized TLS records. The rest of the connections completed, but more slowly, because oversized payloads exceed TCP's initial congestion window and force additional network round trips. "Larger handshakes would affect every TLS connection, not just those that would fail," the Let's Encrypt team wrote in its June 3 post. "They would mean constrained bandwidth, slower connections, and a worse experience for users, all in exchange for security against a threat that hasn't materialized yet."
How Merkle Tree Certificates Solve the Size Problem
MTCs invert the conventional certificate issuance model. A certificate authority using the traditional approach signs each certificate individually, meaning each TLS handshake must carry its own full signature chain. Under MTCs, the CA instead issues certificates in batches — potentially covering millions of domains at once — and applies a single post-quantum signature, called a landmark, to the entire batch.
Browsers maintain a cache of current landmarks, updated out-of-band from the TLS handshake itself. In the common path, what a server needs to present during authentication shrinks to three elements: one post-quantum signature, one public key, and one Merkle inclusion proof. The inclusion proof is a compact hash-based chain demonstrating that a specific leaf certificate is part of the signed batch. Because a Merkle proof's size grows only logarithmically with the number of certificates in the tree, a batch containing billions of certificates still requires only a few hundred bytes of proof data.
The result is that an MTC-based handshake is smaller than today's Web PKI handshakes, even though it uses post-quantum algorithms. David Benjamin, the Google engineer who leads the IETF PLANTS working group draft for MTCs, described the design philosophy as integrating Certificate Transparency into the certificate issuance process "rather than bolting it on after the fact."
A fallback "standalone" form handles edge cases where a client's cached landmarks have become stale, using slightly larger handshakes until the client updates.
Certificate Transparency Becomes Structurally Mandatory
The MTC architecture carries a second benefit that Let's Encrypt described as nearly as significant as the size savings: Certificate Transparency shifts from a policy requirement to an architectural property of issuance.
Under today's system, CAs issue certificates and then log them separately. The TLS handshake carries extra signatures — called Signed Certificate Timestamps — to attest that logging occurred. Those SCT signatures are themselves part of the authentication overhead that makes naive post-quantum migration so expensive.
With MTCs, a certificate cannot exist outside the published Merkle tree. There is no separate logging step and no separate attestation signature, because the inclusion proof that a server presents in the handshake is itself proof of publication. Certificate Transparency is built into the math.
This is ground Let's Encrypt already knows. The organization has operated append-only Merkle tree-based Certificate Transparency logs since 2019, giving it direct operational experience with the data structure at the heart of MTC issuance.
Industry Alignment Behind Merkle Tree Certificates
The MTC approach has attracted broad ecosystem commitment in the months since Google and Cloudflare jointly published their proposal. Chrome has declared MTCs its preferred path for adding post-quantum certificates to the public web. Cloudflare and Google are running a live feasibility experiment against real internet traffic. DigiCert, one of the largest commercial CAs, is participating in the IETF PLANTS working group and has publicly endorsed the MTC architecture as the most consequential shift in internet trust infrastructure in years. Major CAs including Sectigo will also need to develop new tree-head signing infrastructure to participate in the transition.
The urgency behind all of this sharpened earlier in 2026. Google announced that it would migrate its own services to post-quantum cryptography by 2029, citing tightening expert estimates for when a cryptographically relevant quantum computer capable of forging authentication signatures in real time might arrive. Cloudflare followed with a parallel 2029 commitment.
Gartner has predicted that conventional asymmetric cryptography will be unsafe for protecting sensitive data by 2029, citing harvest-now-decrypt-later threats — the practice of adversaries recording encrypted traffic today and storing it for decryption once a quantum computer becomes available. That threat is active now, not hypothetical.
Policy Deadlines Closing In for Operators
National policy timelines are converging on the same end-of-decade window. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires all new National Security System acquisitions to meet post-quantum standards by January 1, 2027. All National Security Systems must use only post-quantum algorithms by December 31, 2030. NIST's transition guidance, NIST IR 8547, would deprecate RSA-2048 and P-256 for new federal systems after 2030 and disallow them entirely after 2035. None of these mandates bind the public Web PKI directly, but the browsers, libraries, and standards bodies that the Web PKI depends on are all working toward the same deadline.
Meanwhile, the CA/Browser Forum has been tightening certificate lifetimes independently of post-quantum concerns. Maximum certificate validity began dropping in March 2026 — from 398 days to 200 days — with further reductions to 100 days by March 2027 and 47 days by March 2029. Shorter lifetimes mean more frequent issuance, which means paying any performance overhead more often. It is another reason a naive ML-DSA migration would be unsustainable, and a reason the engineering stakes around MTCs extend beyond quantum readiness alone.
What the MTC Migration Requires From the Stack
Let's Encrypt was direct that issuing MTCs at its scale is "not a small endeavor." The transition requires changes to its issuance infrastructure, the ACME protocol that subscribers use to obtain certificates, revocation and operational tooling, and the transparency-log infrastructure that MTCs subsume. The organization is participating in the IETF PLANTS and ACME working groups as standards take shape.
In parallel, Let's Encrypt is tracking the standards for ML-DSA signatures in standard X.509 format — covered by RFC 9881 and the in-progress TLS extension draft — as a fallback path. Go 1.27, expected in August 2026, is set to add ML-DSA to its standard library via a new crypto/mldsa package, according to the work-in-progress release notes, a signal that post-quantum signatures are maturing from research algorithms into practical infrastructure.
For non-browser clients — IoT devices, embedded systems, API clients, and proxies — the MTC architecture is more complex. The landmark distribution model requires a client that can maintain and update a cache of batch signatures out-of-band from the TLS handshake. The current IETF draft primarily targets public web PKI environments; organizations running private PKI for internal services or device fleets will need to track both the PLANTS standard and any additional ACME client work required to support non-browser use cases.
What Operators Should Do Right Now
Let's Encrypt was explicit that nothing changes today for existing certificate holders. Current certificates continue to be issued and renewed as normal. When MTCs become available, they will arrive through the same free, automated ACME workflow operators already use.
The organization's immediate recommendation for anyone who operates internet-facing servers addresses a separate and more urgent problem: post-quantum encryption, not post-quantum authentication. Any TLS connection that does not use post-quantum key exchange is potentially vulnerable to harvest-now-decrypt-later collection right now. Let's Encrypt recommends enabling hybrid post-quantum key exchange (X25519MLKEM768) on any internet-facing server. Major browsers and operating systems already support it on the client side; server-side enablement protects against adversaries recording today's encrypted traffic.
For ACME client developers and certificate automation teams, the recommendation is to begin tracking the IETF PLANTS working group and the Chromium MTC mailing list. Some forthcoming ACME protocol changes will require client-side support, and early preparation will ease the ecosystem transition.
Frequently Asked Questions
What are Merkle Tree Certificates and how do they work?
Merkle Tree Certificates are a post-quantum TLS certificate format that applies a single quantum-resistant signature to an entire batch of certificates at once, rather than signing each one individually. During a TLS handshake, a server presents only one signature, one public key, and a compact Merkle inclusion proof showing that its certificate is part of a batch already signed by the certificate authority. Because browsers cache those batch signatures out-of-band, the per-connection overhead is actually smaller than today's web PKI handshakes — even though the underlying algorithm is quantum-resistant.
Why would naively replacing TLS certificates with post-quantum signatures break the web?
The dominant post-quantum signature algorithm, ML-DSA-44, produces signatures of approximately 2,420 bytes, compared to 64 bytes for the ECDSA signatures web certificates use today. A typical TLS handshake carries five signatures and two public keys; replacing them all with ML-DSA equivalents pushes authentication data past 10 kilobytes per connection. Cloudflare's live testing found that at that payload size, around five percent of connections fail entirely due to middlebox incompatibilities, with the remainder completing more slowly as oversized payloads trigger additional network round trips.
What should web operators do now to prepare for post-quantum cryptography?
The most urgent step is enabling hybrid post-quantum key exchange — specifically X25519MLKEM768 — on any internet-facing server. This protects against harvest-now-decrypt-later attacks, where adversaries are recording encrypted traffic today with the intent of decrypting it once quantum computers become available. For certificate management, no changes are needed yet; Let's Encrypt certificates will continue to be issued and renewed normally until the Merkle Tree Certificate standard is production-ready, which the organization targets for 2027.
When will Let's Encrypt's post-quantum certificates be available?
Let's Encrypt is targeting a staging environment that issues Merkle Tree Certificates by late 2026, with a production-ready environment planned for 2027. The exact timeline depends on the IETF PLANTS standardization process, which is ongoing, as well as updates to browsers, language runtimes, and ACME clients. When post-quantum certificates do become available, they will be issued through the same free, automated ACME workflow Let's Encrypt subscribers already use.
ⓒ 2026 TECHTIMES.com All rights reserved. Do not reproduce without permission.
