Identity

On September 29, 2026, Cloudflare announced that it will run a public certificate authority (CA), the kind of organisation browsers trust to vouch that a TLS certificate really belongs to a website. It has signed a definitive agreement to acquire publicly trusted root CA key material from GlobalSign, a root trusted since 2012, and expects the deal to close within two months, subject to customary closing conditions. It has also applied to the root programs run by Chrome, Apple, Microsoft and Mozilla, which decide whose certificates their browsers and operating systems accept.

There is no vulnerability, exploit or patch in this story. It matters because Cloudflare says it will issue Merkle Tree Certificates (MTCs) in production from the first quarter of 2027, a new certificate format built to keep TLS handshakes small once certificates use post-quantum signatures. Classical certificates come first, once the root programs accept the applications. For IT teams, the useful part is what this says about the next few years of certificate work: more change, more often, and less room for manual processes.

Why post-quantum signatures are a size problem

Every HTTPS connection relies on two kinds of public key cryptography. Key exchange agrees the secret that encrypts the session. Signatures prove the server is who it claims to be: the CA signs the certificate, and the server signs part of the handshake with its own key.

A large enough quantum computer would break both. Key exchange is already being fixed: Chrome and Cloudflare negotiate the hybrid X25519MLKEM768 key exchange (classical X25519 combined with the post-quantum ML-KEM-768) by default. Signatures are harder. The post-quantum signature schemes, ML-DSA and SLH-DSA, produce signatures up to about 40 times larger than the RSA or ECDSA signatures in use today. A normal handshake carries several of them: one on each certificate in the chain, plus signed timestamps from Certificate Transparency (CT) logs, the public logs every certificate must appear in. Multiply each by 40 and the handshake becomes slow, especially on mobile networks.

How Merkle Tree Certificates work

A Merkle tree is a structure of hashes. Each leaf is the hash of one item, each parent is the hash of its two children, and the single hash at the top, the tree head, commits to every leaf below it. To prove one leaf is in the tree, you only need the handful of sibling hashes along the path to the top. That path is called an inclusion proof, and it grows very slowly as the tree gets bigger.

MTCs use this to stop signing certificates one by one:

1. The CA batches certificate requests into an append-only issuance log built as a Merkle tree.
2. It signs only the tree head, with one heavy post-quantum signature covering many certificates.
3. Independent cosigners also sign the tree head. Chrome's Quantum-resistant Root Program will require at least two cosignatures: one from the issuing CA and one from a mirroring cosigner run by a different organisation that Chrome recognises.
4. Browsers fetch recent signed tree heads, called landmarks, in the background, outside any TLS connection.
5. During the handshake, the server sends its public key, its own handshake signature and an inclusion proof linking its certificate to a landmark the browser already holds.

The browser hashes its way up the proof and checks that it reaches a tree head it already trusts. In this landmark-relative form there are no CA signatures in the handshake at all, and the inclusion proof is under 1 kB. Because issuance and logging are the same step, every MTC is in a public log from the moment it exists.

There is also a standalone form that carries a cosigned tree head with the proof, for clients that do not have the latest landmarks. It is larger, so it serves as the fallback.

What the Chrome test showed

Cloudflare and Chrome ran the format on real traffic before this announcement. Using Chrome Beta 146, landmark-relative MTCs completed handshakes 9% faster at the median than classical signature chains. The post-quantum design came out ahead of today's certificates because it takes most signatures out of the handshake.

Cloudflare's CA runs on a fork of Boulder, the open source ACME software behind Let's Encrypt, and its MTC work is written up as an IETF draft that Cloudflare co-authored. ACME (Automated Certificate Management Environment) is the protocol clients such as certbot use to request and renew certificates without a person involved. Cloudflare says standard MTC issuance will cost nothing, and that the CA will support RFC 9773, ACME Renewal Information (ARI), which lets a CA tell clients to renew early, for example after a mass revocation.

Two caveats. All four root programs still have to accept the applications under their own processes, and no date for that has been given. And browsers need MTC support before a site can rely on one, so servers will keep classical certificates alongside MTCs for some time.

What to do now

Nothing here needs action this week. The work it points at takes months, so it is worth starting before the certificate changes arrive.

1. Build a certificate inventory. List every public and internal TLS certificate: hostname, issuing CA, key algorithm and size, expiry, and who owns renewal. Start from CT search (crt.sh, filtered on your domains) for public certificates, then scan internal ranges for TLS on all ports. Certificates on load balancers, appliances and VPN gateways are the ones most often missed.
2. Automate renewal with ACME. The CA/Browser Forum schedule cut the maximum lifetime of public certificates from 398 days to 200 days on March 15, 2026. It drops to 100 days on March 15, 2027 and 47 days on March 15, 2029. Anything still renewed by hand will fail at those lengths. Where your ACME client supports ARI, turn it on.
3. Check crypto agility. For each system, confirm you can change the CA, the key type and the certificate chain through configuration alone. Appliances that only accept RSA keys, or firmware that cannot take a new root, are the long-lead items.
4. Remove CA root pinning. Mobile apps, API clients and IoT firmware that pin a specific CA root or intermediate will break when the issuer changes. Pin your own public key with a backup key if you must pin at all, or rely on the platform trust store.
5. Rank harvest now, decrypt later exposure. An attacker can record encrypted traffic today and decrypt it once a quantum computer exists. Certificates do not change that exposure; the key exchange does. Check that VPNs, internal TLS and service-to-service traffic carrying long-lived secrets negotiate a hybrid post-quantum key exchange such as X25519MLKEM768, and plan upgrades for those that cannot.

The order matters. The inventory tells you where the manual renewals and pins are, and automation means that adopting MTCs, once your CA and your users' browsers support them, will not need a manual reissue of every certificate.

The wider lesson

Most organisations will get post-quantum certificates through their CA and their ACME client. Teams that already renew automatically, keep an accurate inventory and avoid hard-coded roots will mostly see a new option in a dashboard. Teams that do not will meet the 100-day limit in March 2027, at about the same time as the first production MTCs.

Our compliance and audit readiness work includes building a certificate and cryptography inventory, and our platform and cloud engineering team sets up ACME automation across load balancers, ingress controllers and appliances. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would run the work.

---

Sources: Cloudflare press release, Cloudflare blog: building a post-quantum CA with MTCs, The Quantum Insider, Futurum Group, Quantum Computing Report, Help Net Security, GlobalSign: 47-day certificate validity, Cloudflare PQC support docs.