Merkle Tree Certificates batch issuance into an append-only Merkle tree so that a CA signs the tree root rather than each certificate, letting clients verify inclusion with a short sequence of hashes against a signed tree head. The design principle behind it is "don't log what you issue, issue by logging" — transparency becomes a condition of operation rather than a separate step. After industry support and an experimental deployment with Chrome, MTCs are the chosen path, and Cloudflare's new certificate authority will issue them, targeting early 2027 for inclusion in Chrome's Quantum-resistant Root Store. Standard MTC issuance will be offered at no cost, and because the CA also issues classical certificates, it can default to the strongest authentication available.

Sizing the post-quantum problem

Authenticating roughly a billion TLS servers without preloading every public key into every client has traditionally been solved with certificate chains, but revocation checks and certificate transparency have since added keys and signatures — five signatures and two keys in a typical TLS handshake. PQ signatures are roughly 40 times larger than classical ones, an overhead that clients, CAs, logs and monitors would all have to absorb.

Transparency was bolted on, which is where the scaling pain concentrates. Certificates get logged repeatedly in different forms across multiple logs, so monitors must download and process every log to avoid missing an issuance. That cost makes it hard to sustain a diverse set of log operators. Cloudflare estimates PQ signatures will inflate CT log storage by 40x — a scaling problem entangled with incentive misalignment. The existing CT ecosystem made issuance publicly auditable by requiring submission to at least two public logs. Cloudflare has run the Nimbus family of CT logs since 2016 and is launching Raio, a family of static CT logs.

Logging alone doesn't make a certificate correctly issued or safe. Monitoring compares log records against what domain owners expect. Cloudflare launched Certificate Transparency Monitoring in 2019 and recently made it generally available, and publishes large-scale certificate measurements on Radar's Certificate Transparency page. As servers move to PQ authentication, monitoring gains a further role: domains that have upgraded should watch CT logs for unexpectedly issued legacy certificates that would let clients fall back onto a malicious downgrade path.

What changes for a certificate authority

In the MTC architecture the CA's duties are recognizable: validate control of a domain, bind it to a public key, issue certificates. What shifts is that the CA maintains a transparency log backed by a Merkle tree, and an inclusion proof in that tree serves as the trust anchor. CAs additionally operate Mirroring cosigners that hold a copy of issuance logs, verify append-only consistency, and keep those logs transparent and available to the rest of the ecosystem. Building this means tracking new PQ Root Program requirements and writing issuance and mirroring software alongside the facilities, operations and compliance functions of a conventional CA.

Issuance, step by step

MTCs are encoded in the X.509 format clients already recognize, distinguished by a "funny" signature algorithm. In standalone form the certificate's signature value carries a cosigned tree head plus an inclusion proof. In landmark-relative form the signature value is just the lightweight inclusion proof and no heavyweight PQ signature, which requires clients to obtain cosigned tree heads out of band, for example through a browser update mechanism.

A standalone issuance begins with a request over the Automatic Certificate Management Environment (ACME) protocol, which handles requests, domain-control validation and issuance workflows. Cloudflare's ACME infrastructure will fork Boulder, the widely deployed software behind Let's Encrypt, which is actively developing MTC support in Boulder; Cloudflare will incorporate those upstream changes plus its own modifications and contribute back where possible.

When the ACME server confirms control of the domain, the CA serializes the data and appends it to an append-only log. It computes the updated log state and signs a checkpoint over it, attesting that every entry in the Merkle tree up to that point was issued by the CA.

That state and checkpoint go to a trusted cosigner, which durably stores a copy, checks that each new state is append-only and consistent with the previous tree, and verifies it is correctly formed. The extra cosignature tells clients and monitors that an independent party saw the same log state and that the CA isn't showing different views to different parts of the ecosystem, and it keeps issued certificates monitorable even if the CA's log goes unavailable.

Chrome's Quantum-resistant Root Program draft policy requires at least two cosignatures: one from a Chrome-recognized Mirroring Cosigner run by a distinct organization, and one from the issuing MTC CA. Cloudflare will therefore mirror for other pilot CAs and require at least one independent cosignature on its own certificates. The mirroring cosigner will be implemented in Azul, Cloudflare's open-source Rust transparency log, and will speak c2sp's tlog mirror protocol.

Once a cosignature arrives, the CA assembles the MTC from the cosignatures, the server's public key and the inclusion proof, and returns it to the server for use in TLS.

Cutting TLS overhead with landmarks

Standalone certificates still put large PQ signatures on the wire. The efficiency gains come from landmark-relative certificates, which drop cosignatures from each certificate. A CA designates a sequence of subtrees covering all active certificates in its log as a landmark and ships those subtrees, with the data needed to authenticate them, to clients through an out-of-band update service. During the handshake, the browser checks that the server's certificate data — domain name and public key — appears in a trusted subtree of the CA's log; if the inclusion proof links that certificate to a cosigned landmark and the public key then proves possession, the client knows the server is the right one.

Because the signatures and tree metadata travel to TLS clients out of band, a small set of MTC batch signatures covers billions of certificates from one CA. Landmarks don't remove the need for standalone MTCs, since clients may be freshly installed, offline, or missing the relevant landmark update. Servers should therefore keep a standalone certificate fallback.

Chrome experiment: MTCs at production volume

To test whether MTCs hold up between a client and server, we ran an experiment with Chrome using a "bootstrap CA" — a fake CA that stubbed the issuance pipeline — issuing MTCs backed by a traditional certificate chain for selected Cloudflare domains on the "free" plan. Those certificates were served to 50% of Chrome Beta 146, and billions of MTCs were served over the course of the experiment.

For TLS, the common case proved efficient: with a landmark-relative certificate, the handshake transmits one public key, one signature, and an inclusion proof of less than 1kB. Where a landmark-relative certificate could not be negotiated with the client, the experiment fell back to the traditional certificate chain rather than serving a standalone certificate.

MTCs also shift the scaling properties of transparency. The log carries only hashes of public keys: there are no per-entry signatures, and the tree head signature covers the entire log. Because the CA issuance log is the source of truth for every certificate the CA issues, certificate explosion is prevented, and log consumers need fetch only a single copy of each certificate.

At median, landmark MTCs were 9% faster than a classical signature chain — most of that gain comes from intermediate elision. Since the test used MTCs with classical signatures, the improvement should be larger with post-quantum signatures. With these results in hand and cross-industry collaboration underway in the IETF's PLANTS WG, the experiment began winding down last month (August 2026).

Open questions and next steps

The experiment showed MTCs work in practice, and issuing certificates as a real CA is the next milestone. Several questions, though, can only be answered by exercising the full PKI ecosystem:

  • Can independent monitors consume and verify MTC issuance logs at production volume?
  • Will enough CAs and cosigners emerge to give the system the diversity it needs for resilience?
  • How should browsers balance the performance benefits of compact landmark MTCs against the fallback paths required by clients without fresh landmarks?

MTCs have become the authoritative design for post-quantum authentication, but proving them out at production Internet scale requires root programs, browser vendors, CAs, mirrors, monitors, and the wider community to take part.

Operating CA infrastructure carries real responsibility: browsers, domain owners, and everyday people rely on a CA to validate identities correctly, protect signing keys, follow policy, and operate reliably. Before Cloudflare's CA can be trusted by browsers to issue MTCs, it must apply to Chrome's Quantum Resistant root store and undergo a rigorous evaluation. We expect to be held to the same bar as any other trusted CA, and we hope other CAs emerge to support MTC adoption and to work with any browser deploying MTCs.