X.509 Certificate vs Merkle Tree Certs: 40x Gap [2026]

An X.509 certificate is the file that proves a website’s identity to your browser, and post-quantum signatures are about to make it far heavier. Chrome’s security team said in February 2026 that it has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store. It is building Merkle Tree Certificates (MTCs) with partners instead.

That decision splits the post-quantum web into two tracks. One track keeps the familiar chain of signed certificates and swaps in ML-DSA, the NIST signature standard finalized in August 2024. The other batches certificates into an append-only Merkle tree and hands the browser a short inclusion proof. As of October 23, 2026, neither track has publicly trusted certificates in production, and MTCs remain an IETF Internet-Draft (revision -07, dated October 7, 2026).

Size drives the whole debate. According to Let’s Encrypt’s June 2026 figures, an ML-DSA-44 signature runs about 2,420 bytes, against 64 bytes for ECDSA-P256. A typical Web PKI handshake today carries five signatures and two public keys, so the gap compounds quickly. If you want the background on how a signature differs from the certificate that carries it, the explainer on digital signatures versus digital certificates covers the basics.

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

Add now

Why Post-Quantum Signatures Strain the X.509 Certificate Chain #

A classic X.509 certificate chain has three parts. A leaf certificate binds a domain name to a server’s public key. An intermediate certificate vouches for the leaf. A root certificate, already stored in your browser, vouches for the intermediate. Every link carries a signature, and every signature is verified before the lock icon appears.

Over two decades the chain picked up extras. Certificate Transparency (CT) added signed certificate timestamps from public logs. Revocation checks added signed status responses. Cloudflare’s engineers count the result as five signatures and two public keys in a typical TLS handshake. Classical algorithms made that tolerable because the pieces are tiny. An ECDSA-P256 signature is 64 bytes and an RSA-2048 signature is 256 bytes.

Post-quantum signatures change the arithmetic. Cloudflare’s September 29, 2026 write-up puts post-quantum signatures at roughly 40 times the size of classical ones. Let’s Encrypt reports that swapping ML-DSA equivalents into a standard handshake would push it well past 10 kilobytes, and it cites Cloudflare research showing that at that scale a meaningful share of real-world TLS connections fail while the rest slow down. Larger handshakes hit every connection, not just the unlucky ones, which is why defaults matter so much at web scale.

Five signatures, two keys, one oversized handshake

Take the Let’s Encrypt numbers at face value and run the sums. A chain of five signatures and two keys is far larger with ML-DSA-44 than with ECDSA-P256 or RSA-2048. Any such totals are back-of-envelope arithmetic that ignores ASN.1 encoding overhead and every other field in the handshake, but the direction is the point. The post-quantum chain is many times larger than the ECDSA chain.

The cost does not stop at the wire. Cloudflare estimates that post-quantum signatures would balloon the data CT logs must store by 40 times. Log operators, monitors and auditors all pay that bill, and fewer operators means less independent oversight. Cloudflare calls this incentive misalignment the heart of the post-quantum scaling problem.

Authentication also has a different urgency curve than encryption. An attacker can record encrypted traffic today and decrypt it later, so key exchange had to move first. Forging a signature requires a quantum computer to exist at the moment of the attack, which makes certificates a less immediate target. That logic is why hybrid key exchange such as X25519MLKEM768 is already common, as the comparison of ML-KEM and X25519 in TLS 1.3 shows. Let’s Encrypt still tells server operators that turning on hybrid key exchange is one of the highest-leverage moves available this year, ahead of any certificate change.

Long-lived keys complicate the idea that authentication can wait. Root CA keys, code-signing keys and identity systems live for years, and new technology takes years to reach broad adoption. Let’s Encrypt points to tightening timelines, including Google’s pledge to migrate its services by 2029 and a parallel Cloudflare commitment. Start the work late and the old chain becomes the weak link.

How Merkle Tree Certificates Work #

An MTC authority does not sign each certificate one at a time. It adds certificate entries to an append-only Merkle tree and signs the tree head, which can represent potentially millions of certificates according to Google’s announcement. The certificate a browser receives is then a lightweight proof that its entry sits inside that tree. Readers who want the data structure itself can start with the comparison of Merkle and Verkle trees.

The design flips today’s order of operations. In the current system a CA issues a certificate and then submits it to at least two public CT logs afterward. In an MTC system the issuance log is the source of truth, so a certificate cannot exist outside the tree. Cloudflare summarizes the idea as issuing by logging. Transparency stops being an add-on and becomes a precondition, which also removes the extra timestamp signatures that ride along in today’s handshakes.

Two supporting roles keep the CA honest. A mirroring cosigner stores a copy of the issuance log, verifies that each new state extends the previous one, and adds its own signature. Monitors watch the logs for certificates a domain owner never requested. Cloudflare says Chrome’s draft Quantum-resistant Root Program policy requires at least two cosignatures: one from the issuing CA and one from a Chrome-recognized mirroring cosigner run by a distinct organization.

Standalone versus landmark-relative certificates

MTCs come in two forms, and both can be encoded in the X.509 format that client software recognizes today. The only change is the signature algorithm field. A standalone MTC carries a cosigned tree head plus an inclusion proof, so it works for any client but still ships large post-quantum signatures during the handshake.

The landmark-relative form is where the savings arrive. The CA designates subtrees covering all active certificates as landmarks, and browsers receive those landmarks out of band, outside the TLS handshake. During the handshake the server sends its public key and an inclusion proof that connects to a landmark the browser already trusts. In the common case Let’s Encrypt describes the full authentication path as one signature, one public key and one inclusion proof, which is smaller than today’s Web PKI handshake even with post-quantum algorithms.

Servers must still keep a fallback. A freshly installed browser, an offline device or a client missing the latest landmark update cannot use the compact form. The server then serves a standalone MTC or, during the current experiments, a traditional certificate chain. Certificate requests keep flowing through ACME, the same protocol that automates issuance today.

Note what MTCs are not. They do not abandon X.509 syntax, and they do not replace the idea of a trusted CA. The facts that change are how the CA’s signature is carried, how logging is bound to issuance, and how a client decides to trust a batch of certificates at once. Calling MTCs an X.509 replacement overstates the case, because current designs encode them inside X.509 structures.

X.509 Certificate vs Merkle Tree Certificates: Specs Side by Side #

The table below compares a conventional X.509 certificate chain with the MTC design as of October 23, 2026. Values come from the IETF PLANTS draft, Google’s Chrome announcement, Cloudflare’s September 2026 posts and Let’s Encrypt’s June 2026 plan. Where a feature is still a plan, the cell says so.

Attribute	X.509 certificate chain	Merkle Tree Certificates
Standards status	Mature profile in RFC 5280	IETF Internet-Draft, revision -07 (October 7, 2026)
Encoding	DER-encoded X.509	DER-encoded X.509 with a different signature mechanism
What the client verifies	A signature at every link up to a trusted root	An inclusion proof against a cosigned tree head
Signatures in a typical handshake	Five signatures and two public keys	One signature, one public key, one inclusion proof (landmark form)
Inclusion proof size	Not applicable	Under 1 kB in the Cloudflare and Chrome experiment
Transparency model	Certificate Transparency added after issuance	Built into issuance, no certificate exists outside the tree
Post-quantum path	ML-DSA signatures in X.509 (FIPS 204, RFC 9881)	Post-quantum signature on the tree head, cost shared across the batch
Client-side requirement	None beyond current trust store	Out-of-band landmark updates for the compact form
Fallback behavior	Not needed	Standalone MTC or traditional chain
Issuance protocol	ACME plus legacy methods	ACME (Chrome favors ACME-only workflows)
Cosigning	CA signature only	CA plus an independent mirroring cosigner in Chrome’s draft policy
Chrome trust store	Chrome Root Store, classical algorithms	Chrome Quantum-resistant Root Store, onboarding planned for Q3 2027
Publicly trusted issuance today	Yes, classical signatures only	No, Cloudflare targets Q1 2027
Fit for short-lived certificates	Logging overhead grows with each issuance	Designed to cut logging overhead for short-lived certificates
Chrome’s stance	No immediate plan to add post-quantum X.509 chains	Preferred path for post-quantum public certificates

Two rows deserve emphasis. The encoding row shows why a flat “MTC replaces X.509” headline misleads, since both live in the same container. The Chrome trust store row shows why timing matters: even a perfect MTC deployment cannot reach general web users until a browser trust program accepts the issuing CAs.

Benchmark Data: What the Published Numbers Show #

Public benchmarks for MTCs are thin because the technology is months old in the field. Three organizations have published measurable figures: Let’s Encrypt on object sizes, Cloudflare on log storage and a live experiment with Chrome, and Google on the tree-head model. The table collects them with dates.

Source and date	Metric	Published value
Let’s Encrypt, June 3, 2026	Signature size, ML-DSA-44	About 2,420 bytes
Let’s Encrypt, June 3, 2026	Signature size, RSA-2048 and ECDSA-P256	256 bytes and 64 bytes
Let’s Encrypt, June 3, 2026	Public key size, ML-DSA-44, RSA-2048, ECDSA-P256	1,312, 256 and 64 bytes
Let’s Encrypt, June 3, 2026	Handshake with ML-DSA equivalents	Well past 10 kilobytes
Cloudflare, September 29, 2026	Post-quantum vs classical signature size	Roughly 40 times larger
Cloudflare, September 29, 2026	CT log storage with post-quantum signatures	Estimated 40 times more data
Cloudflare and Chrome experiment, 2026	Landmark MTC inclusion proof	Under 1 kB
Cloudflare and Chrome experiment, 2026	Median handshake time vs classical chain	9% faster
Google, February 27, 2026	Certificates covered by one CA signature	Potentially millions per tree head

Read the 9% figure carefully. Cloudflare ran a bootstrap CA that issued MTCs backed by a traditional chain for a selection of domains on its free plan, then served them to half of Chrome Beta 146 users. It served billions of MTCs over the run. Cloudflare says most of the speed gain comes from dropping the intermediate certificate, not from post-quantum math, and the test used classical signatures. The company expects a larger gain once post-quantum signatures enter the picture, but that remains a projection.

We can reason about the post-quantum case from the published sizes. A landmark-relative handshake with ML-DSA-44 needs one 1,312-byte public key, one 2,420-byte signature and a compact inclusion proof, while the chain-based equivalent carries several signatures and keys and comes out far larger. That is a rough comparison under our own simplifying assumptions, not a measured result, and a standalone MTC would sit between the two. Microsoft’s documentation adds context for larger parameter sets, listing ML-DSA public keys of 1,312, 1,952 and 2,592 bytes and signatures of 2,420, 3,309 and 4,627 bytes for the three FIPS 204 sets.

Three caveats limit how far these figures travel. The Cloudflare sample came from free-plan domains and a beta browser channel, so it skews toward small sites and early adopters. The experiment measured connection setup, not the cost of keeping landmark data fresh on millions of devices. And the speed gain compares a trimmed chain with a full one, so a classical chain with the intermediate certificate removed would close part of the gap without any Merkle tree at all. The size numbers carry more weight than the timing number because they follow directly from the algorithms.

No independent lab has yet published head-to-head latency numbers on real post-quantum MTC traffic. Treat any vendor chart claiming otherwise with suspicion until the Q1 2027 pilots and the IETF working group produce data that others can reproduce.

Where Post-Quantum X.509 Chains Still Make Sense #

Chrome’s stance against post-quantum X.509 chains applies to the public web trust store, not to every network on earth. Google’s announcement says it expects to support traditional X.509 certificates with quantum-resistant algorithms later in 2026, for use only in private PKIs that sit outside the Chrome Root Store. That carve-out explains why ML-DSA certificates are spreading through enterprise tooling while public CAs stay classical.

The standards groundwork is done. NIST’s FIPS 204 defines ML-DSA-44, ML-DSA-65 and ML-DSA-87. RFC 9881 covers ML-DSA signatures inside X.509. The TLS-level work is still in draft form, which means the TLS wire format for ML-DSA authentication could still shift. For a side-by-side of the signature families themselves, see the guide to ML-KEM, ML-DSA and SLH-DSA.

Enterprise and cloud vendors have shipped support already. AWS documented ML-DSA support in AWS Private CA on October 15, 2026. Cloudflare says origin servers can present ML-DSA-44 certificates over TLS 1.3 when connecting to its network, a capability that grew out of the Authenticated Origin Pulls and Custom Origin Trust Store features. Microsoft’s documentation describes Phase 1 ML-DSA support in Active Directory Certificate Services, and Oracle Database documents ML-DSA certificate handling with its orapki tool on JDK 24 or later, limited to TLS 1.3. Let’s Encrypt adds that Go 1.27 brings ML-DSA into the standard library, which lowers the barrier for tooling written in Go.

A MITRE capability assessment dated October 17 and refreshed October 23, as summarized by industry press, reportedly found ML-DSA issuance in private or enterprise products from Keyfactor, Microsoft and DigiCert but no browser that validates post-quantum-signed X.509 certificates. Oracle’s own guidance, dated October 13, warns that public CAs do not yet broadly issue ML-DSA certificates for production TLS. Both points line up with Chrome’s roadmap.

The case for plain ML-DSA chains is simplicity. Every certificate carries its own signature, so there is no landmark update service, no cosigner network and no dependency on a client’s freshness. Closed environments can run them today: service meshes, mutual TLS between internal workloads, device fleets and lab testbeds. The cost is the size penalty described earlier, which private networks can usually absorb because they control both ends of the connection.

Classical certificates are also not going away overnight. The classical baseline for signatures, whether RSA, ECDSA or EdDSA, stays in service during the transition, and the trade-offs among those schemes are laid out in the breakdown of Ed25519 versus ECDSA. NIST’s draft transition guidance, as Let’s Encrypt summarizes it, would deprecate RSA-2048 and P-256 after 2030 and disallow them after 2035, a draft proposal rather than a final rule.

Who Is Building What: Chrome, Cloudflare, Let’s Encrypt and Apple #

The MTC effort has moved from a draft idea to a multi-vendor program in under a year. The dated milestones below come from the vendors’ own announcements and the IETF record.

• February 27, 2026: Google announces Chrome’s MTC program in three phases. Phase 1 is a feasibility study with Cloudflare. Phase 2, planned for Q1 2027, invites CT log operators that already run a usable log in Chrome to bootstrap public MTCs. Phase 3, planned for Q3 2027, finalizes onboarding of additional CAs into the Chrome Quantum-resistant Root Store.
• June 3, 2026: Let’s Encrypt commits to MTCs as its path to post-quantum certificates, targeting a staging environment in late 2026 and a production-ready service in 2027.
• August 2026: Cloudflare begins winding down its Chrome experiment after concluding that MTCs work in practice.
• September 21, 2026: Apple announces work on an MTC root program policy, with a draft expected by the end of October 2026. Reporting on the direction says it would require three cosignatures per certificate, including an independent mirror operator.
• September 29, 2026: Cloudflare announces it will become a public CA that issues classical certificates and MTCs, aiming for first production MTCs in Q1 2027 and inclusion in Chrome’s Quantum-resistant Root Store.
• October 7, 2026: The IETF PLANTS working group publishes draft-ietf-plants-merkle-tree-certs-07.
• October 15, 2026: The UK NCSC publishes revised TLS guidance covering hybrid and pure post-quantum key exchange, and says post-quantum authentication recommendations for TLS will follow in coming months.

The pattern is worth reading closely. Chrome supplies the browser trust program, Cloudflare and Let’s Encrypt supply the issuance capacity, and the IETF supplies the protocol text. Apple’s entry matters because Safari and iOS reach a large share of mobile users, and a second major root program accepting MTCs would make the model hard for CAs to ignore. Apple’s draft had not appeared as of October 23, so its requirements remain reported direction, not published policy.

Standards work runs in parallel on the TLS side. A draft called TLS Trust Anchor Identifiers describes how a client and server negotiate which trust anchor to use, which is the mechanism that lets a server offer an MTC to a client that supports it and a classical chain to one that does not. Its authors cite the PLANTS draft as related work and frame the problem as gradual, heterogeneous deployment of post-quantum CAs. A separate draft, Post-Quantum Traditional Hybrid Authentication with Dual Certificates in TLS 1.3, covers the alternative of presenting a traditional and a post-quantum chain in one exchange. Neither is final.

Government clocks add pressure on all of these timelines. Let’s Encrypt notes that the NSA’s CNSA 2.0 suite has pointed national security systems toward post-quantum algorithms on a 2030 to 2035 schedule since 2022, and that the European Union’s roadmap targets high-risk systems by the end of 2030 and broad migration by 2035. Those mandates do not bind the public Web PKI directly. They do set the end-of-decade deadline that browsers, library authors and CAs already work toward, and Google and Cloudflare have both set 2029 as their own internal target.

Cloudflare’s CA plan also changes the competitive picture among cloud providers. The company combines CDN reach, ACME infrastructure forked from Let’s Encrypt’s Boulder software, and the Azul transparency log written in Rust. How that stacks up against hyperscaler approaches is covered in the comparison of Cloudflare and AWS on post-quantum encryption.

Pricing and Availability Compared #

Certificates are a service, so cost belongs in the comparison. No post-quantum certificate product has a published public price list yet. What exists are statements of intent about free issuance and a few cloud features without separate line items in the sources reviewed.

Option	Status on October 23, 2026	Published price
Cloudflare MTC issuance	Announced, production targeted for Q1 2027, subject to root program approval	Standard issuance stated as free, no pricing page yet
Cloudflare ML-DSA-44 origin certificates	Available for Cloudflare-to-origin connections over TLS 1.3	No separate price confirmed
AWS Private CA with ML-DSA	Documented October 15, 2026	Not stated in the sources reviewed
Conventional public X.509 certificates	Generally available, classical signatures only	Varies by CA, no universal price
Publicly trusted ML-DSA certificates	Not generally available on the Web PKI	None

Free is the likely end state for the common case. Cloudflare says it will provide standard MTC issuance at no cost, and Let’s Encrypt says post-quantum certificates will arrive free, automated and open to anyone with an ACME client when they ship. Both statements describe plans, not products, and neither promises that add-ons such as custom validity periods or enterprise validation will cost nothing.

Hidden costs sit elsewhere. ACME client maintainers must add MTC support, which Let’s Encrypt says will require client-side changes. Operators who want the safest posture will keep a classical chain as a fallback during the overlap, which means paying for two certificates for a while. Monitoring teams will need to watch both CT logs and MTC issuance logs. Budget engineering time for those three items before you budget for certificate fees.

Real-World Deployments and Tests #

Several live projects show where each design stands. Each of the examples below is dated and attributed to the organization that ran it.

• Chrome and Cloudflare feasibility study. Cloudflare issued MTCs through a bootstrap CA for selected domains on its free plan and served them to 50% of Chrome Beta 146. The run produced billions of MTCs, an inclusion proof under 1 kB in the common case, and a median handshake that was 9% faster than the classical chain. Every MTC connection was backed by a traditional trusted certificate as a safety net.
• Cloudflare origin authentication. Since mid-2026 Cloudflare has let origin servers authenticate with ML-DSA certificates and negotiate X25519MLKEM768 key agreement on the leg between its edge and the customer’s server. This path covers server-to-server traffic, not browser-facing TLS, and shows plain ML-DSA X.509 working in a controlled setting.
• Let’s Encrypt planning. The nonprofit CA is developing MTC support in Boulder, its open-source ACME server, and targets a staging environment in late 2026. Cloudflare plans to maintain its own Boulder fork that tracks those upstream changes.
• Microsoft PQC TLS pilot. Microsoft reportedly launched a pilot on August 27, 2026 that lets approved CAs in its Trusted Root Program test ML-DSA-87 certificates on Windows 11 and Windows Server 2025. The pilot certificates are not publicly trusted and aimed at closed environments and enterprise testbeds.
• AWS Private CA. AWS added ML-DSA to Private CA, which gives internal PKIs a quantum-resistant root of trust. Standards-compliant mTLS clients can use the certificates, and AWS lists IKEv2 and IPsec peers as supported.
• UK NCSC guidance. On October 15, 2026 the NCSC recommended both hybrid and pure post-quantum TLS configurations for general use and for protecting government OFFICIAL information, following the IETF’s publication of RFC 10024 on hybrid key agreement for TLS 1.3. It says high-priority migration activities should finish by 2031 and that authentication recommendations for TLS are coming, which is the gap MTCs aim to fill.
• Oracle Database and Java. Oracle documents ML-DSA certificate creation, signing and validation through its orapki tool on JDK 24 or later, and its guidance describes JDK 27 as carrying the core ML-DSA and ML-KEM capabilities needed for an initial transition. Java shops can therefore test post-quantum certificates in private deployments without waiting for browsers.
• DNS faces the same wall. Large post-quantum signatures also strain DNSSEC, and Cloudflare has been working on that problem separately, as described in coverage ofpost-quantum DNSSEC and TLS .

Together these examples reveal a division of labor. Private and server-to-server traffic is adopting ML-DSA chains first because operators control both ends. Browser-facing traffic is waiting for MTCs because the open web cannot absorb the extra bytes. If you run both kinds of systems, plan on two migration tracks that finish at different times.

What Cryptographers Say About the Trade-Offs #

Direct commentary on MTCs from independent cryptographers is still sparse, so the quotes below come from adjacent debates over post-quantum migration. They frame the stakes and the caution that surrounds any new scheme. The interpretation that follows each one is ours.

Tanja Lange, Professor of Cryptology at Eindhoven University of Technology, explained the harvest-now threat in a 2017 ScienceDaily interview: “An attacker can record our secure communication today and break it with a quantum computer years later. All of today’s secrets will be lost.” That warning concerns encryption, which is why key exchange moved to hybrid post-quantum designs first and certificates second.

Joppe W. Bos, a cryptographer and technical director, put the maturity gap bluntly on a slide in his 2024 post-quantum presentation: “ECC / RSA benefit from decades of cryptanalysis including logical / physical attacks.” Classical certificate signatures carry that long record. ML-DSA is newer and MTCs newer still, which argues for keeping a classical fallback in place during the overlap.

Daniel J. Bernstein, a cryptographer and computer science professor, defended hybrid deployment in an IETF TLS list discussion of ML-KEM: “We hope ML-KEM is adding protection against quantum computers. However, in case of security failures in the ML-KEM spec or ML-KEM software, we continue also using ECC, instead of throwing ECC away.” He was talking about key agreement, but the same instinct explains why MTC deployments keep a traditional chain behind them and why an IETF draft covers dual-certificate hybrid authentication in TLS 1.3.

Security Trade-Offs and Failure Modes #

Smaller handshakes do not come free. MTCs trade a familiar trust model for a new one, and several of the new moving parts can fail in ways operators have not yet seen in production.

Downgrade risk comes first. Every deployment today keeps a traditional certificate as a fallback, so an attacker who can obtain a classical certificate for your domain might force clients down the old path. Cloudflare advises domain owners who move to post-quantum authentication to watch CT logs for unexpectedly issued legacy certificates. Chrome’s roadmap addresses part of the problem by planning an opt-in downgrade protection for sites that only want quantum-resistant certificates, but that feature arrives with Phase 3 in Q3 2027.

The landmark channel is the second new dependency. Compact MTCs only work when the browser holds fresh landmark data, delivered outside the handshake by the browser vendor’s update service. That concentrates responsibility in a small number of update pipelines. A stale or poisoned landmark feed would either break fast paths or, worse, mislead clients. Mirroring cosigners soften the risk because they give independent parties a copy of each issuance log, and Chrome’s draft policy requires one from a distinct organization.

CA compromise remains the old nightmare. When researchers reported compromised private keys for eMudhra intermediate CA certificates, Chrome moved to protect users, and the follow-up fallout appears in coverage of eMudhra’s exit from the global TLS business. MTCs do not remove that class of problem. They change what a forged certificate looks like, since a certificate must appear in a public tree to validate, which makes silent misissuance easier to spot. Chrome also proposes replacing legacy CRLs with a revocation framework focused on key compromise.

Cryptographic assumptions deserve respect too. ML-DSA rests on lattice problems, while the Merkle tree relies on hash function security. The lattice side carries a recent cautionary tale from NIST’s additional-signature process: the designers of HAWK reportedly withdrew their candidate in late July 2026 after an AI-assisted attack became public. NIST said, according to secondary reporting, that the withdrawal does not affect finalized standards such as ML-DSA, which use different mathematical foundations. The episode still shows why crypto agility, not a single bet, is the safe design principle.

Finally, complexity itself is a risk. Plain X.509 has twenty years of tooling, fuzzing and operational lore behind it. MTCs add cosigners, monitors, landmarks and new ACME behaviors, and the spec is still at an Internet-Draft revision. Expect implementation bugs during the first production year, which is one reason Chrome and Cloudflare insisted on a traditional fallback during testing.

Use-Case Recommendations #

The right choice depends on who controls the client. Match your situation to one of the profiles below.

1. Public website or API operator. Stay on classical X.509 certificates from your current CA, enable hybrid key exchange (X25519MLKEM768) on your servers and terminate TLS 1.3 only where you can. Revisit MTCs when your CA or CDN announces ACME support, which Cloudflare puts at Q1 2027 and Let’s Encrypt at 2027.
2. CDN, SaaS or hosting provider. You will likely receive MTCs through your upstream CA first. Plan to serve both a classical chain and an MTC for the same name, and design your edge to select the best option per client. Budget engineering time for landmark freshness checks and fallback testing.
3. Enterprise internal PKI and mTLS. Pilot ML-DSA certificates now, using AWS Private CA, Microsoft AD CS or DigiCert private PKI, on a non-critical service mesh or lab network. You control both ends, so the larger chain costs little, and you learn which libraries choke on big certificates.
4. IoT and long-lived embedded devices. These fleets may be offline or rarely updated, so they cannot depend on fresh landmarks. Favor trust-anchor agility in firmware, keep certificate chains short, and test standalone MTC and ML-DSA handling in your TLS stack before devices ship.
5. CA operators and ACME client maintainers. Join the IETF PLANTS and ACME working groups and follow the Chromium MTC mailing list that Let’s Encrypt points to. Client support for MTC issuance flows will be needed before production CAs launch.
6. Security and compliance teams. Build a cryptographic inventory now. NIST’s draft transition guidance points to 2030 and 2035 milestones for RSA and elliptic curves, and the UK NCSC recommends high-priority migration activities by 2031. Knowing where every certificate and key lives is the prerequisite for any of the options above.

Migration Guide: Getting Ready in Eight Steps #

Nobody can migrate to publicly trusted MTCs today, but you can remove the obstacles. The steps below prepare a typical web estate for either track. For a wider look at the key-exchange half of the transition, see the overview of post-quantum cryptography adoption.

1. Inventory your certificates. List every public and private certificate, its signature algorithm, key type, issuer and expiry. Include load balancers, internal services, device fleets and third-party endpoints that present your names.
2. Check what your servers present today. The command below prints the signature and key algorithms of a live certificate.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -text \
  | grep -E "Signature Algorithm|Public Key Algorithm|Public-Key"

1. Turn on TLS 1.3 and hybrid key exchange. The UK NCSC notes that TLS 1.3 is the only TLS version that supports post-quantum cryptography and that earlier versions will not be upgraded. With OpenSSL 3.5 or newer you can test whether a server negotiates the X25519MLKEM768 hybrid group.

echo | openssl s_client -connect example.com:443 -tls1_3 \
  -groups X25519MLKEM768 2>/dev/null | grep -i "group"

1. Automate issuance with ACME. MTC issuance runs through ACME, and Chrome favors ACME-only workflows. Move manual certificate processes onto an ACME client that you can update quickly when MTC support lands.
2. Pilot ML-DSA in a private PKI. Stand up a test CA with a vendor that documents ML-DSA support, issue certificates to a non-production service, and measure handshake size, CPU use and failure rates behind your real load balancers and middleboxes.
3. Stress-test oversized handshakes. Cloudflare and Let’s Encrypt both note that large post-quantum handshakes fail on some real networks. Send test traffic through your firewalls, proxies and TLS inspection gear to find devices that break.
4. Set up monitoring. Subscribe to CT log monitoring for your domains now. The same discipline will extend to MTC issuance logs and will catch downgrade attempts through unexpected legacy certificates.
5. Keep a classical fallback and a review calendar. Review your plan at each milestone: Apple’s draft policy expected by the end of October 2026, Let’s Encrypt’s staging environment in late 2026, and Cloudflare’s and Chrome’s Q1 2027 targets. Do not retire classical certificates until a major browser trusts your replacement.

Pros and Cons #

Classical X.509 certificate chains (with ML-DSA where used in private PKI)

• Pro: Twenty years of tooling, audits and operator experience stand behind the chain model.
• Pro: No landmark service, cosigner network or client freshness requirement.
• Pro: ML-DSA chains already work in private PKI products from AWS, Microsoft and DigiCert.
• Con: Post-quantum signatures are roughly 40 times larger than classical ones, and handshakes grow well past 10 kilobytes.
• Con: CT log storage would swell about 40 times under Cloudflare’s estimate.
• Con: Chrome has no immediate plan to trust post-quantum X.509 chains in its public root store.

Merkle Tree Certificates

• Pro: The common handshake carries one signature, one public key and an inclusion proof under 1 kB.
• Pro: Transparency is built into issuance, so no certificate exists outside a public tree.
• Pro: Backed by Chrome, Cloudflare and Let’s Encrypt, with Apple drafting a root policy.
• Pro: Free standard issuance is planned by both Cloudflare and Let’s Encrypt.
• Con: Still an Internet-Draft, with no publicly trusted issuance before 2027.
• Con: Compact form needs out-of-band landmark updates, and servers must keep a fallback.
• Con: New components such as mirroring cosigners add operational complexity and new failure modes.

Verdict: Which Certificate Model Wins #

For the public web, Merkle Tree Certificates win on design and classical X.509 chains win on availability. The experimental numbers favor MTCs: a post-quantum chain is far larger than a landmark-relative MTC, and Cloudflare’s experiment reported a 9% median speed gain over a classical signature chain. That was an experimental result, not a production guarantee. Google’s Chrome work has reportedly made MTCs its preferred direction for post-quantum authentication.

For private networks, post-quantum X.509 with ML-DSA wins today. It ships in AWS Private CA and in enterprise tooling, it needs no browser changes, and the size penalty is manageable when you own both ends of the connection. Teams that wait for MTCs to reach their internal PKI will wait longer than necessary.

The practical ranking as of October 23, 2026 follows. First, enable hybrid key exchange everywhere, because the harvest-now threat is the urgent one. Second, pilot ML-DSA certificates in private PKI. Third, prepare ACME automation and CT monitoring so that MTC adoption in 2027 is a configuration change, not a project. Fourth, keep classical certificates in service until a major browser trusts your replacement. More background on algorithm families sits in the cryptography section.

Four events would change this ranking. A browser vendor accepting post-quantum X.509 chains into a public root store would revive the chain model on the open web. A serious flaw in the MTC draft, such as a landmark-update weakness, would delay the 2027 timetable. Independent measurements showing that post-quantum handshakes fail far less often than Cloudflare’s research suggests would weaken the size argument. And a break in ML-DSA itself would send everyone back to hash-based options. None of those has happened as of today.

Frequently Asked Questions #

What is an x509 certificate?

An x509 certificate is a standardized digital document, profiled in RFC 5280, that binds a public key to an identity such as a domain name. A trusted certificate authority signs it, and browsers verify that signature chain against root certificates they already hold.

Do Merkle Tree Certificates replace X.509?

No. Current designs encode MTCs in the X.509 format with a different signature mechanism. They change how trust and logging work, not the container, and conventional X.509 chains remain in use during the transition.

Can I get a publicly trusted Merkle Tree Certificate today?

Not yet. Cloudflare says it is not issuing certificates and targets production in Q1 2027, subject to root program approval. Let’s Encrypt targets a staging environment in late 2026 and production in 2027.

Are MTCs post-quantum secure?

The architecture lets a CA use post-quantum signatures on the tree head and spread their cost across many certificates. Cloudflare’s Chrome experiment used classical signatures, so it measured the structure, not post-quantum security. Reported draft requirements from Apple include ML-DSA cosignatures.

Why not simply use ML-DSA certificates on public websites?

The bytes. An ML-DSA-44 signature is about 2,420 bytes, many times the size of an ECDSA-P256 signature, and a full chain would push handshakes well past 10 kilobytes. Chrome says it has no immediate plan to add such chains to its root store.

Does hybrid post-quantum key exchange depend on the certificate type?

No. Key exchange (X25519MLKEM768) and authentication (certificates) are separate parts of TLS 1.3. You can enable hybrid key exchange today with ordinary classical certificates, and Let’s Encrypt recommends doing so first.

When will Chrome trust MTCs?

Google’s published plan invites CT log operators to bootstrap public MTCs in Q1 2027 and opens onboarding of additional CAs to the Chrome Quantum-resistant Root Store in Q3 2027. Cloudflare is targeting early 2027 for its own inclusion. These are plans, and dates can slip.

What should I do this quarter?

Inventory your certificates, enable TLS 1.3 with hybrid key exchange, automate renewals through ACME, and pilot ML-DSA in a private PKI. Those four moves help under either certificate track.

source & further reading

shattered.io — original article SUSE Locks Down AI Agents With 3 NVIDIA Chips [2026] Claude Duet: 3 Apps, 2 Plans, 0 Browser View [2026] InstructMesh: Novices Fix 90% of AI 3D Flaws [2026]