A Merkle Tree Certificate (MTC) is a new, more compact kind of TLS certificate, currently an experimental IETF proposal, in which a Certificate Authority batches many certificates into a single Merkle tree and signs only the tree’s root, rather than signing each certificate individually. A browser then proves its certificate belongs to that signed tree using a short inclusion proof instead of carrying a full chain of signatures. The aim is to deliver post-quantum, quantum-safe authentication without the oversized signatures that NIST’s PQC algorithms would otherwise add to every TLS handshake.
If you manage digital certificates for a living, the phrase “post-quantum transition” has probably moved from a distant abstraction to something sitting on your roadmap. NIST has finalized its first post-quantum cryptography (PQC) standards, browsers are already shipping quantum-safe key exchange, and the question is no longer whether the WebPKI will change but how disruptive that change will be. The honest answer is that the cryptography is the easy part. The hard part is fitting it into a thirty-year-old certificate ecosystem without breaking the performance everyone quietly depends on.
That is the gap Merkle Tree Certificates were built to close. One thing to clear up first, because the name trips people up: Merkle Tree Certificates (MTCs) are not a NIST publication. They are an experimental proposal in the IETF, currently developed in the PLANTS working group and authored by engineers from Google, Cloudflare, and Geomys. What ties them to NIST is the problem they solve. The NIST-standardized PQC signature algorithms, such as ML-DSA, are dramatically larger than the elliptic-curve signatures we use today, and MTCs are a structural answer to that size problem. Understanding MTCs, then, means understanding why NIST’s quantum-safe algorithms put the web in an awkward position in the first place.
Why Post-Quantum Certificates Strain the Web’s Performance Budget
The reason the industry is moving toward PQC at all is the “harvest-now, decrypt-later” threat. An adversary can capture encrypted traffic today and store it, betting that a future quantum computer running Shor’s algorithm will eventually unravel the RSA and elliptic-curve cryptography that protected it. Gartner has projected that conventional asymmetric cryptography like RSA and ECC could be unsafe for protecting sensitive data well before a full quantum break actually arrives. To get ahead of this, Chrome and other major browsers have already rolled out a hybrid post-quantum key exchange (X25519MLKEM768) to defend the confidentiality of the TLS handshake.
Authentication is a different story. The signatures that prove a certificate is legitimate are not vulnerable until a cryptographically relevant quantum computer actually exists, so there is a little breathing room. But when that day comes, the numbers are brutal. An ECDSA P-256 signature is about 64 bytes. ML-DSA-44, one of the more compact NIST PQC signature schemes, produces signatures of roughly 2,420 bytes, nearly forty times larger. Move up to ML-DSA-65 and you are looking at signatures around 3,309 bytes alongside public keys of about 1,952 bytes.
Those figures matter because certificates are exchanged during the TLS handshake, the latency-sensitive moment before a single byte of a web page loads. A typical certificate chain today is around four kilobytes. Stack post-quantum signatures across a chain plus the Signed Certificate Timestamps that Certificate Transparency requires, and the per-handshake signature overhead can climb from a few hundred bytes to well over thirteen thousand.
Some estimates put full quantum-safe handshakes at fifteen to thirty kilobytes. On mobile or constrained networks, that bloat translates directly into slower page loads, and if quantum-safe security feels slow, adoption stalls and the protection it promises never reaches users. MTCs exist to break that trade-off.
What Merkle Tree Certificates Actually Are
A Merkle tree is a familiar structure to anyone who has worked with transparency logs or blockchains: data is hashed into leaves, pairs of hashes are combined and hashed again, and the process repeats until a single hash, the root, represents the entire dataset. Anyone can prove that a specific leaf belongs to the tree using a short “inclusion proof” (a handful of sibling hashes) rather than the whole dataset.
MTCs apply that idea to certificate issuance. Instead of a Certificate Authority signing every individual certificate, the CA gathers many certificates into a large Merkle tree and signs only the root, called the Tree Head, once. A relying party such as a browser then receives a compact proof that its certificate is included under that signed root. What is easy to miss here is that MTCs do not invent new cryptography or sidestep NIST’s standards. ML-DSA still does the signing; it just signs a single batched Tree Head rather than thousands of individual certificates. The primitives are standard; what changes is the architecture that delivers them.
How Merkle Tree Certificates Work
The idea is straightforward in outline, but a handful of moving parts have to work together to make it hold up in practice, from how a certificate is issued to how a browser ends up trusting it.
From Per-Certificate Signatures to a Single Signed Tree Head
In classical PKI, every link in an X.509 chain is individually signed and transmitted in full on every handshake. With MTCs, the CA maintains a running log of everything it issues and periodically signs a view of that log, the Tree Head, to assert that the listed certificates are genuinely its own. Because one signature now covers an entire batch of certificates, the expensive post-quantum signature cost is amortized across all of them instead of being paid per certificate, per connection. The CA’s signature can also be combined with cosignatures from independent parties who verify that the CA is operating correctly and who may mirror the log.
Merging Certificate Transparency with Issuance
The design also changes how Certificate Transparency works, and this is one of the parts worth paying attention to. Today, CT works as a separate layer added on top of issuance: CAs submit certificates to independent logs, which return Signed Certificate Timestamps that browsers later verify, adding still more signatures to the handshake. MTCs fold logging directly into issuance, so the act of issuing a certificate and the act of logging it become inseparable. That delivers comparable transparency and accountability guarantees while removing the separate SCT signatures that inflate the post-quantum handshake.
The Signatureless (Landmark) Optimization
The part that gets the most attention is an optional optimization the draft describes for what it calls landmark certificates. A traditional X.509 certificate carries a public key, one CA signature, and two CT signatures. In MTC’s signatureless mode, the public key stays but the signatures are effectively moved elsewhere, so that for an up-to-date relying party the handshake needs only a public key and a Merkle inclusion proof, with no on-wire signature at all.
Research applying MTCs to private infrastructure found a landmark proof can be on the order of 736 bytes, with the validation material distributed out-of-band rather than crammed into every handshake. The catch, and it is an important one, is that this only works for relying parties that are sufficiently current; older clients fall back to a more traditional, signature-bearing path. To keep that fallback window small, MTCs lean on shorter-lived certificates and defined validity windows, which means certificates turn over more frequently than many teams are used to.
What This Means for the WebPKI and Certificate Management
The shift reaches well beyond cryptography, changing how trust is distributed, how certificates are governed, and how the teams who manage them have to operate day to day.
A New Trust Model and the Chrome Roadmap
Google has made clear that it does not intend to simply stuff post-quantum signatures into traditional X.509 certificates for Chrome. Instead it is pursuing MTCs as the path forward, and it is already live-testing them with Cloudflare. The plan includes a separate Chrome Quantum-resistant Root Store with its own root program, rolled out across phases, with the framework for onboarding additional CAs targeted for around the third quarter of 2027. For the CA ecosystem, that combination of active testing and concrete timelines signals that this is well past the thought-experiment stage.
That signal grew stronger in June 2026. On June 3, 2026, Let’s Encrypt, the nonprofit certificate authority that secures more than 500 million websites, published its post-quantum roadmap and named Merkle Tree Certificates as its chosen path. It is targeting a staging environment that issues MTCs in late 2026 and a production-ready environment in 2027.
Let’s Encrypt has operated Certificate Transparency logs built on Merkle trees since 2019, so it already has hands-on experience with the data structure MTCs depend on. The organization stressed that nothing changes for existing subscribers today, certificates keep being issued over ACME exactly as before, while the deeper work happens in issuance infrastructure, the ACME protocol, and revocation and transparency tooling. When a CA that issues so large a share of the web’s certificates commits to a specific post-quantum path, the rest of the ecosystem has to pay attention.
Beyond the Browser: Private PKI
Although MTCs were conceived for the public WebPKI, the same pressures exist inside the enterprise. Environments like Kubernetes control planes and cloud-native 5G cores mutually authenticate thousands of connections per second, and post-quantum signature overhead compounds fast in those settings. Early research has begun adapting MTC architectures to private PKI, replacing a cluster’s internal CA with an MTC-style authority, complete with cosigners and landmark distributors. If that work matures, the ideas behind MTCs could spread well past public TLS and into the machine identities that modern infrastructure depends on.
The Trade-offs and Open Questions
None of this comes for free. MTCs introduce real complexity into an ecosystem that has spent decades hardening the X.509 model, and the signatureless benefit only applies to clients that stay current. Out-of-band distribution of validation material, the move to shorter certificate lifetimes, the need for cosigners and monitors, and a parallel quantum-resistant root store all add moving parts. The proposal is still experimental and evolving inside the IETF, so specifics will keep shifting. The point is not to pin your plans to a draft that may still change. It is to read the direction of travel. Trust is being re-architected, and certificates are getting shorter-lived and more numerous.
Why Automation Stops Being Optional
That direction of travel has one unavoidable consequence for the teams who actually run certificate operations. A world of shorter validity windows, batched issuance, integrated transparency, and possibly two coexisting trust models (classical X.509 and MTC) is a world where manual certificate management quietly becomes impossible. You cannot hand-track certificates that rotate every few days across a quantum-resistant root store and a legacy one at the same time. The organizations that weather this transition smoothly will be the ones that already have deep visibility into every certificate they hold, the crypto-agility to swap algorithms and formats without re-architecting, and automated discovery, enrollment, and renewal that does not care whether the underlying signature is ECDSA or ML-DSA. Preparing for MTCs, in practice, looks a lot like getting your certificate lifecycle management house in order now.
How Can Encryption Consulting Help?
Merkle Tree Certificates are still experimental, and the draft will keep changing before anything reaches production. That is exactly why the smart move right now is not to chase the spec, but to get your certificate estate into the kind of shape where a shift like this is a configuration change rather than a fire drill. The groundwork that pays off the day MTCs (or whatever they become) arrive is the same groundwork that pays off today: knowing every certificate you hold, being able to change cryptography without re-architecting, and automating the lifecycle so nothing slips through the cracks.
Encryption Consulting’s CertSecure Manager is a vendor-neutral certificate lifecycle management solution that centralizes discovery, automation, enrollment, policy enforcement, and integrations. It prevents outages with automated renewals, enhances compliance, streamlines IT operations, and unifies management of public and private CAs through a single, automated, and scalable platform.
Those same capabilities are what prepare you for the MTC era. Complete discovery gives you the full inventory you will need when trust models start to shift, so you are never guessing what runs where. Automated enrollment and renewal handle the shorter-lived certificates and faster rotation that MTCs lean on, which quickly become unmanageable by hand.
The platform’s crypto-agility lets you move between algorithms, from today’s ECDSA and RSA toward post-quantum options like ML-DSA, without rebuilding your workflows. And because CertSecure Manager already manages public and private CAs side by side, it is built for a transition period in which classical X.509 and new certificate formats have to coexist. Paired with robust role-based access control and clear visibility into your certificate operations, that puts you in a position to adopt what comes next on your own timeline rather than scrambling to react.
Conclusion
Merkle Tree Certificates are not really a replacement for NIST’s post-quantum algorithms. They are the plumbing that makes those algorithms practical on the open web. NIST gave us quantum-safe signatures, and their size threatened to choke the TLS handshake. MTCs are the IETF’s structural fix: they trade per-certificate signatures for a single signed Tree Head, add compact inclusion proofs, and weave Certificate Transparency directly into issuance. The result is a credible path to quantum-resistant authentication without the performance penalty that would otherwise stall adoption.
The proposal is still experimental, the timelines still moving, and the trade-offs still being negotiated inside the IETF. But the major browsers, CAs, and CLM vendors are all treating it as a serious signal about where the WebPKI is heading: toward more trust anchors, shorter-lived certificates, integrated transparency, and a period in which classical and post-quantum models coexist. Whether or not MTCs land in exactly their current form, the operational lesson is the same. The teams that handle this well will be the ones who already know which certificates they own, can swap cryptography when they need to, and have automated the lifecycle from end to end. Get those fundamentals right, and even a redesign of trust itself becomes something you manage calmly rather than scramble against.
