The Web's PKI Is Forking: Let's Encrypt Joins the MTC Coalition, and Your Migration Plan Needs Two Tracks
Why your PKI modernization plan now needs two tracks
Let’s Encrypt, the certificate authority behind more than 700 million websites and 54% of all public SSL/TLS certificates, announced on June 3 that Merkle Tree Certificates will be its path to post-quantum web authentication. The organization is targeting late 2026 for a staging environment and 2027 for production readiness.
Four months ago, when Google and Cloudflare published the MTC proposal, the biggest open question was whether the rest of the CA industry would follow or resist what looked like browser vendors dictating PKI architecture. Let’s Encrypt’s commitment answers that question. With Chrome, Cloudflare, DigiCert, and the world’s largest CA aligned, MTCs have crossed from proposal to industry consensus in record time.
This has concrete implications for how organizations should plan the PKI component of their PQC migration. The Web PKI is heading toward a two-track architecture that will persist for years: MTCs for browser-to-server authentication, standard X.509 certificates with ML-DSA signatures for everything else. If your migration plan assumes a single PKI path, it needs revision.
Why MTCs Exist
The engineering constraint is clear. A typical TLS handshake today transmits about 1,248 bytes of authentication data across five signatures and two public keys. If you replace those with ML-DSA-44 (FIPS 204), that figure pushes past 14,700 bytes, well beyond TCP’s initial congestion window. Cloudflare’s engineers found that at that payload size, a meaningful share of TLS connections fail outright. Google’s threshold analysis calls anything above ~7 KB “implausible unless a CRQC is tangibly imminent.”
MTCs solve this by batching. Instead of each certificate carrying its own post-quantum signature, the CA signs a single Merkle tree head representing potentially millions of certificates. 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, the proof is 736 bytes. No signature travels over the wire.
The CA’s post-quantum signature exists only once, on the tree head checkpoint, and Google and Cloudflare have indicated this will use a hybrid approach combining ECDSA and ML-DSA. Because batched signing means the CA’s HSM signs infrequently, the computational cost of expensive PQ signing operations becomes negligible.
MTCs do not replace or bypass NIST-standardized algorithms. ML-DSA still signs the tree head checkpoints. What changes is architectural. Google is redesigning the plumbing that delivers standardized cryptography to billions of browsers without choking the pipes.
Certificate Validity Reductions Add Urgency
The MTC timeline coincides with a separate pressure that compounds any per-certificate overhead. The CA/Browser Forum’s Ballot SC-081v3 shrinks maximum TLS certificate validity from 398 days to 200 days (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. An architecture that amortizes one post-quantum signature across millions of certificates fits this trajectory far more naturally than one that signs each certificate individually. For organizations still managing certificates manually, the validity reductions alone are a forcing function. Combined with the PQC size problem, fully automated certificate management has moved from best practice to prerequisite.
The Non-Browser Gap
The concern I raised in my analysis of Google’s MTC proposal 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 population of non-browser TLS consumers.
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. 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: a split certificate infrastructure that persists for years. Your migration plan needs to account for both tracks.
What Let’s Encrypt Got Right on TNFL
Let’s Encrypt’s framing of urgency is worth noting. For years, the conventional wisdom treated authentication as less urgent than encryption because signature forgery requires a CRQC operating in real time, not retroactively. Let’s Encrypt’s post explicitly acknowledges this framing and then moves past it, noting that long-lived keys, particularly root CA keys and code-signing keys, are high-value targets.
That is the right instinct, and it aligns with the Trust Now, Forge Later thesis I have been developing since 2018. The deeper TNFL concern, the one that drives the urgency in my framework’s treatment of signature migration, 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. The supply-chain and code-signing pieces remain open.
The IETF PLANTS Working Group
The standardization vehicle for MTCs is the IETF PLANTS (PKI, Logs, And Tree Signatures) working group, established after a successful Birds-of-a-Feather session at IETF 124. Google, Cloudflare, Let’s Encrypt, and Filippo Valsorda are participating. The ACME protocol that Let’s Encrypt subscribers use to obtain certificates will need extensions to support MTC issuance. Organizations running ACME clients or operating certificate infrastructure should start monitoring the PLANTS working group and the mtcs@chromium.org mailing list.
Migration Impact
For organizations running PQC migration programs, Let’s Encrypt’s announcement changes the planning assumptions for PKI modernization:
If you operate public-facing web services, start tracking MTC developments and ensure your ACME clients will be ready. Nothing changes in your certificate issuance today, but the production timeline (2027 for Let’s Encrypt) is close enough that infrastructure planning should begin. Browser-facing TLS will migrate via MTCs, not via ML-DSA X.509 certificates.
If you maintain internal PKI for microservices, VPNs, mTLS, and device authentication, plan for the standard X.509 path. Your internal CAs will need to issue certificates with ML-DSA or composite signatures. This is the harder migration: you own the CA, you own the clients, and you bear the full performance cost of larger signatures and certificate chains. Phase 6 of the PQC Migration Framework covers PKI modernization, including dual-stack CA deployment for this scenario.
Enable hybrid post-quantum key exchange now (X25519MLKEM768). This addresses the more urgent HNDL encryption threat immediately, requires no certificate changes, and is supported by all major browsers and edge providers today.
Automate your certificate management completely. 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.
Bottom line: The Web PKI’s post-quantum architecture is now decided. MTCs for browser-facing authentication, standard X.509 with PQC signatures for everything else. Organizations should update their Phase 6 PKI modernization plans to reflect this two-track reality. If you are waiting for the industry to converge on a single approach, it already has: two approaches, for two different trust models.
For the full analysis of the MTC architecture and its implications, see Google’s Merkle Tree (MTC) Gambit to Quantum-Proof HTTPS, Cloudflare Joins Google: Two Internet Giants Now Say 2029, and Let’s Encrypt Commits to Merkle Tree Certificates on PostQuantum.com.
The Applied Quantum PQC Migration Framework addresses PKI modernization and dual-stack CA deployment in Phase 6 (Infrastructure & Performance).