Let’s Encrypt Commits to Merkle Tree Certificates for Post-Quantum HTTPS

June 5, 2026 – Let’s Encrypt, the nonprofit certificate authority operated by the Internet Security Research Group (ISRG) that secures more than 700 million websites, has announced that Merkle Tree Certificates (MTCs) will be its path to post-quantum web authentication. The organization is targeting late 2026 for a staging environment that issues MTCs and 2027 for production readiness.

The announcement, authored by Let’s Encrypt engineer Andrew Gabbitas, commits the world’s largest certificate authority to the same architectural approach that Google and Cloudflare proposed in February. Let’s Encrypt issued 54.4% of all public SSL/TLS certificates in Q1 2026, so its adoption of MTCs essentially makes the standard viable for the majority of the encrypted web.

Let’s Encrypt has operated append-only Merkle tree-based Certificate Transparency logs since 2019, giving the organization production experience with the core data structure that MTCs depend on. The team is participating in the IETF PLANTS (PKI, Logs, And Tree Signatures) and ACME working groups as the standards are finalized.

Alongside the MTC work, Let’s Encrypt said it is tracking ML-DSA (FIPS 204) signatures in standard X.509 format via RFC 9881 and the in-progress TLS extension draft, as well as Go 1.27’s forthcoming crypto/mldsa package. Nothing changes for existing subscribers today; current certificates will continue to be issued and renewed as before.

Why Authentication Became Urgent

Let’s Encrypt’s announcement frames the problem with unusual directness. For years, the post-quantum conversation in the TLS ecosystem focused on encryption, driven by the Harvest Now, Decrypt Later (HNDL) threat: adversaries recording encrypted traffic today for future quantum decryption. Authentication received less attention because forging a digital signature requires a cryptographically relevant quantum computer (CRQC) operating in real time, not retroactively.

That calculation has shifted. The Let’s Encrypt post cites three acceleration signals in quick succession: the NSA’s CNSA 2.0 suite directing national security systems toward post-quantum algorithms on a 2030-to-2035 schedule, NIST’s draft transition guidance deprecating RSA-2048 and P-256 after 2030, and the EU’s coordinated roadmap targeting high-risk systems by the end of this decade. In 2026 alone, Google committed to migrating its services by 2029, and Cloudflare published a parallel post-quantum roadmap.

Let’s Encrypt’s conclusion: post-quantum authentication is no longer a problem the Web PKI can defer. Long-lived keys, particularly root CA keys and code-signing keys, are high-value targets, and new cryptographic infrastructure takes years to reach broad adoption.

The Size Problem That Drove the Decision

The decision to choose MTCs over a straightforward algorithm swap rests on a hard engineering constraint. As I detailed in my analysis of Google’s MTC proposal, a typical TLS handshake today transmits about 1,248 bytes of authentication data across five signatures and two public keys. Replacing those with ML-DSA-44 would push that figure past 14,700 bytes, well beyond TCP’s initial congestion window. Cloudflare’s real-world testing has shown that at that payload size, a meaningful share of TLS connections simply fail.

MTCs solve this by batching. Instead of each certificate carrying its own post-quantum signature, a CA signs a single Merkle tree head representing potentially millions of certificates at once. Browsers receive tree head updates out-of-band (through browser updates, analogous to how root certificates are distributed today), and the TLS handshake carries only a compact inclusion proof, a chain of hash values that grows logarithmically with tree size. For a batch of roughly 4.4 million certificates, that proof is just 736 bytes. No signature at all travels over the wire.

Let’s Encrypt emphasized that issuing MTCs at its scale is “not a small endeavor,” requiring changes to its issuance infrastructure, the ACME protocol that subscribers use to obtain certificates, revocation tooling, and the transparency-log infrastructure that MTCs subsume.

Ecosystem Momentum Building Behind MTCs

Let’s Encrypt is the third major player to commit to MTCs since Google and Cloudflare published the proposal in February. Chrome has declared MTCs its preferred path for post-quantum certificates in the public web, and Cloudflare is running a live feasibility experiment with Chrome against real internet traffic. DigiCert has published an open-source MTC Playground for developers to test the mechanics. The IETF’s PLANTS working group, established after a successful Birds-of-a-Feather session at IETF 124, is standardizing the design with participation from Google, Cloudflare, Let’s Encrypt, and independent cryptographer Filippo Valsorda.

The timing coincides with a separate pressure that is accelerating certificate automation across the industry. The CA/Browser Forum’s Ballot SC-081v3 is shrinking maximum TLS certificate validity from 398 days to 200 days (as of March 2026), then 100 days (March 2027), and ultimately 47 days (March 2029). Let’s Encrypt has already announced it will reduce certificate lifetimes to 64 days by February 2027 and 45 days by February 2028. Shorter lifetimes mean more frequent issuance, which compounds any per-certificate overhead. An architecture that amortizes a single post-quantum signature across millions of certificates fits this trajectory far more naturally than one that signs each certificate individually.

My Analysis

When I wrote about Google’s MTC proposal in February, the biggest open question was whether the rest of the CA ecosystem would follow Chrome’s lead or resist what looked like a browser vendor dictating PKI architecture. Let’s Encrypt’s commitment four months later answers that question decisively. The world’s largest CA, processing more than half of all public TLS certificates, has chosen the same path. With Chrome, Cloudflare, DigiCert, and Let’s Encrypt aligned, MTCs have crossed from proposal to ecosystem consensus in record time.

The speed matters. My earlier article cited a Let’s Encrypt engineer estimating 10 to 15 years for full MTC ecosystem rollout. The organization’s own staging target of late 2026 and production target of 2027 suggests that estimate referred to complete global deployment, not the CA’s own infrastructure readiness. The gap between “our systems are ready” and “every ACME client, operating system, and embedded device can consume MTCs” remains vast, but the supply side is moving faster than most observers expected.

What Let’s Encrypt Got Right on TNFL

The most interesting aspect of the announcement is how Let’s Encrypt frames the urgency of authentication migration. Their post explicitly acknowledges that authentication has historically been considered less urgent than encryption because signature forgery requires a CRQC operating in real time. This is technically correct as a description of the conventional wisdom, but it understates the real risk.

I have argued since 2018 that Trust Now, Forge Later (TNFL) deserves at least as much attention as HNDL. The threat model is different: rather than harvesting encrypted data for future decryption, TNFL targets trust relationships. Software updates, firmware signatures, code-signing certificates, legal documents, financial transaction authorizations, all of these depend on signature schemes that a future CRQC could forge. The consequences arrive as a cliff, not a slow burn, because a forged signature is indistinguishable from a real one the moment the forgery becomes possible.

Let’s Encrypt’s post does gesture toward this by noting that “long-lived keys (root certificate authorities, code-signing keys, identity systems) are particularly valuable targets.” That is the right instinct. But the announcement treats the problem primarily through the lens of TLS handshake authentication, where the real-time forgery requirement does make the threat less immediate than HNDL for data in transit. The deeper TNFL concern, the one that keeps me up at night, is about the trust infrastructure itself: root CA private keys, code-signing hierarchies, and software supply chains where a single forged signature can cascade through millions of systems.

MTCs address the handshake authentication piece elegantly. The supply chain and code-signing pieces remain open problems that no current proposal fully resolves.

The Non-Browser Gap Is Still Real

The structural concern I raised in February persists: MTCs are optimized for a world where browsers mediate trust, receive frequent updates, and maintain background connections to transparency services. This works for Chrome, Firefox, and Safari users. It does not work for curl, Python’s requests library, IoT devices, embedded systems, or the vast ecosystem of non-browser TLS consumers that collectively represent a large share of internet traffic.

Let’s Encrypt acknowledges this implicitly by tracking ML-DSA in X.509 as a parallel path. The organization is watching RFC 9881 and the draft-ietf-tls-mldsa TLS extension, which would allow traditional X.509 certificates to carry post-quantum signatures. This matters because the non-browser ecosystem will likely need standard X.509 certificates with ML-DSA or FN-DSA (FIPS 206) signatures, performance overhead and all, until operating systems can distribute tree heads at the system level.

The result will almost certainly be a split ecosystem that persists for years: MTCs for browser-to-server authentication, composite or ML-DSA X.509 certificates for everything else. Organizations running internal PKI for microservices, VPNs, mTLS, and device authentication should plan for the standard X.509 path. Organizations operating public-facing web services should start tracking MTC developments and ensure their ACME clients will be ready.

What Organizations Should Do Now

Let’s Encrypt was explicit that nothing changes today for its subscribers. But “nothing changes today” and “nothing to do” are different statements. Three actions are worth taking now.

First, if you operate servers, enable hybrid post-quantum key exchange (X25519MLKEM768). Let’s Encrypt’s own post makes this recommendation. Major browsers and operating systems already support it. This addresses the more urgent HNDL encryption threat and requires no certificate changes.

Second, ensure your certificate management is fully automated. The CA/Browser Forum’s validity reductions are coming regardless of post-quantum considerations. Organizations that can rotate certificates at high frequency will be in the best position to migrate when MTC issuance goes live. Organizations still managing certificates manually will struggle with both the validity reductions and the eventual cryptographic transition.

Third, if you maintain an ACME client or operate certificate infrastructure, start monitoring the IETF PLANTS working group and the [email protected] mailing list. The protocol changes required to request and install MTCs will need client-side support.

The Broader PQC Migration Signal

Let’s Encrypt’s announcement reinforces a point I have been making with growing urgency: the quantum deadline is no longer about predicting when a CRQC arrives. The ecosystem is setting its own deadlines. Google has committed to 2029. The EU targets 2030 for high-risk systems. NIST’s draft guidance deprecates classical algorithms after 2030. Certificate authorities are already re-architecting their infrastructure. These are not contingency plans triggered by a hardware breakthrough; they are engineering roadmaps executing on fixed schedules.

The organizations that will be best positioned are the ones treating PQC migration as an infrastructure modernization program that happens to be motivated by a cryptographic transition, rather than a panic response to a specific threat timeline. Let’s Encrypt’s measured, systematic approach, staging in 2026, production in 2027, full ecosystem rollout over years, is a model for how this should work. The PQC Migration Framework I published provides a structured approach for organizations that want to follow a similarly systematic path.