Cloudflare is building a certificate authority to make post-quantum website authentication practical without burdening TLS connections with oversized signatures.
The company plans to issue conventional certificates alongside Merkle Tree Certificates, or MTCs, and is targeting early 2027 for admission to Chrome’s new Quantum-resistant Root Store; standard MTC issuance will be free.
The initiative addresses a gap in web public key infrastructure. Browsers currently trust certificate authorities to validate domain control and bind a website’s identity to a public key, while Certificate Transparency logs expose issuance for auditing.
That model works today, but Cloudflare estimates post-quantum signatures could increase CT storage requirements by 40 times; a typical TLS handshake already carries several signatures and keys.
This matters because quantum-safe authentication must preserve both security and responsiveness across billions of websites, browsers, logs, monitors, and certificate renewals worldwide.
MTCs redesign this process around an append-only Merkle tree. Instead of signing each certificate and subsequently submitting it to separate logs, the CA records certificate data in an issuance log and signs a checkpoint covering the tree’s state.
A website then receives an inclusion proof, a sequence of hashes showing its certificate belongs to the signed tree. The concept changes the rule from “log what you issue” to “issue by logging,” making transparency part of issuance rather than a later attachment.
According to research published by Cloudflare, the company’s workflow will use ACME for requests and domain-control validation. Its ACME service will fork Boulder, the software behind Let’s Encrypt, which is developing MTC support.
After validation, the CA adds the certificate data to its log, signs the updated checkpoint and submits it to a mirroring cosigner. That independent service checks append-only consistency, stores a copy, and helps prevent the CA from presenting conflicting log views.
Chrome’s draft policy requires a cosignature from the issuing CA and another from a recognized mirror operated by a separate organization. Cloudflare intends to build its mirror with Azul, its open-source, Rust-based transparency-log software, while supporting the C2SP tlog-mirror protocol for interoperability.
Only after obtaining the required cosignatures does the CA assemble the public key, inclusion proof, and signatures into a standalone MTC.
The performance gain comes from landmark-relative certificates. Browsers can receive tree substructures, called landmarks, through an out-of-band update channel.
During TLS negotiation, a server then sends only its certificate data and a lightweight proof connecting it to a trusted landmark, eliminating heavyweight post-quantum signatures from the handshake. Standalone MTCs remain necessary when a client is new, offline or lacks a current landmark.
Cloudflare says a deployment with 50 percent of Chrome Beta 146 users served billions of MTCs for free-plan domains. Landmark handshakes transmitted one public key, one signature, and an inclusion proof smaller than 1 KB, producing a 9 percent median speed improvement over classical certificate chains.
Importantly, the trial used classical signatures, and Cloudflare acknowledged that much of the measured gain came from removing the intermediate certificate.
The design is promising but unfinished. MTC remains an active IETF PLANTS working-group Internet-Draft, not a finalized standard, and Cloudflare must still pass Chrome’s root-program review before browsers trust its certificates.
Production deployment must also prove that independent monitors, multiple CAs, and diverse cosigners can process logs reliably at Internet scale.
For defenders, CT monitoring will remain essential: organizations adopting post-quantum authentication should watch for unexpected legacy certificates that could enable a downgrade path.
Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup into your SOC
