Cloudflare plans to become a public certificate authority and issue both conventional TLS certificates and a post-quantum alternative designed to keep HTTPS authentication fast. The company has applied to the Chrome, Apple, Microsoft and Mozilla root programs, signed an agreement to acquire established root key material from GlobalSign, and is targeting the first production Merkle Tree Certificates for the first quarter of 2027.
The distinction between plan and product matters. Cloudflare is not issuing public certificates yet, and its root-program applications still need approval. The GlobalSign transaction is also expected to close within two months, subject to customary conditions. What Cloudflare has announced is the infrastructure and trust strategy for entering a market that underpins nearly every secure website.
The move is significant for two reasons. It could add another free, automated issuer alongside Let’s Encrypt, improving resilience in a certificate ecosystem concentrated among a small number of providers. It also gives Chrome’s emerging post-quantum certificate system a large operator willing to test it at internet scale.
Why HTTPS needs more than post-quantum encryption
TLS does two related jobs. Key exchange protects the contents of a connection, while certificate authentication helps the browser verify that it reached the intended server. The web has made much faster progress on the first job.
Modern browsers can negotiate the hybrid X25519MLKEM768 key exchange in TLS 1.3, combining a conventional elliptic-curve method with the NIST-standardized ML-KEM algorithm. Cloudflare reports that about 70% of browser-generated traffic reaching its network already uses hybrid post-quantum encryption. Only about 15% of connections from Cloudflare to origin servers do, leaving a large gap behind the edge.
Authentication is harder. Today’s certificate chains rely on RSA or elliptic-curve signatures that a sufficiently capable quantum computer could eventually forge. Replacing those signatures with current post-quantum alternatives is not a simple drop-in upgrade. Cloudflare estimates that post-quantum signatures are roughly 40 times larger than classical signatures and could increase the storage carried by certificate-transparency logs by a similar factor.
That extra data is not merely an accounting nuisance. A TLS handshake already carries multiple keys and signatures. Inflating each certificate chain can increase connection setup time, push more handshakes across network packet boundaries and cause failures on constrained or lossy networks.
How Merkle Tree Certificates change the model
Merkle Tree Certificates, or MTCs, avoid signing every certificate separately. An issuing authority adds certificates to an append-only Merkle tree, signs a checkpoint representing the tree’s state and obtains cosignatures from independent mirror operators. A browser can then verify a compact inclusion proof showing that a site’s certificate is present in the approved tree.
The most efficient version moves the bulky tree signatures out of individual TLS handshakes. Browsers receive authenticated “landmarks” through their update mechanism, while servers send a public key, a normal proof of possession and an inclusion proof of less than 1 KB. A standalone MTC carrying its own signed tree head remains available as a fallback when a client lacks a current landmark.
This also folds transparency into issuance. Conventional certificates are issued first and then copied into separate public logs. With an MTC, the certificate’s inclusion in the append-only log is part of the trust proof itself. Cloudflare summarizes the design as issuing by logging rather than logging what was already issued.
A joint experiment with Chrome served billions of MTCs to half of Chrome Beta 146 users across selected Cloudflare domains. Cloudflare reports that the landmark-relative form was 9% faster at the median than the classical chain used in the test, largely because it omitted intermediate certificates. That trial used classical signatures, so it demonstrated the delivery architecture rather than a finished quantum-resistant production chain.
Cloudflare is building two paths into browser trust
A new certificate authority normally faces a long distribution problem. Even after browser approval, its root certificate must reach operating systems, browsers, phones, appliances and embedded devices. Hardware that no longer receives trust-store updates may never recognize it.
Cloudflare’s planned acquisition addresses that legacy problem by obtaining GlobalSign root material already trusted across a broad device base since 2012. In parallel, Cloudflare is applying for new roots under the current policies of Chrome, Apple, Microsoft and Mozilla. The acquired root is intended to cover older clients; newly approved roots would support the policies and cryptography of the next phase.
For conventional certificates, Cloudflare plans an ACME-first service. Operators already using automated certificate clients should be able to switch by changing the directory endpoint instead of deploying a new certificate-management stack. Cloudflare also intends to require ACME Renewal Information support, defined in RFC 9773, so it can advance renewal windows and replace affected certificates in the background during a security or compliance incident.
The company says its standard classical and MTC issuance will be free. It plans to use a fork of Boulder, the open-source ACME software that powers Let’s Encrypt, and contribute compatible work upstream where possible. Let’s Encrypt is independently targeting a production-ready MTC environment in 2027, suggesting the format is becoming a shared industry direction rather than a Cloudflare-only design.
What website and security teams should do now
No site needs to replace its public certificate with a Cloudflare MTC today. Production issuance has not started, Chrome’s quantum-resistant root policy is still developing, and broad support outside Chrome will determine how quickly MTCs become useful across the web.
There are, however, several preparation steps that do not depend on Cloudflare’s launch:
- Inventory certificate automation. Identify services still using manual renewal, undocumented certificate scripts or clients without ACME Renewal Information support.
- Measure both halves of TLS. Confirm that visitor-facing TLS 1.3 connections can negotiate X25519MLKEM768, then separately test the CDN-to-origin or proxy-to-origin path. Edge protection does not guarantee that the origin connection is post-quantum.
- Watch certificate-transparency logs. Once a domain adopts post-quantum authentication, an unexpected classical certificate could create a downgrade path. Monitoring remains necessary even when issuance and transparency are more tightly coupled.
- Test old and embedded clients. Appliances, apps with pinned roots and unmaintained operating systems may behave differently from current browsers. Cloudflare’s acquired root may improve compatibility, but it cannot replace application-level testing.
- Separate key exchange from authentication in roadmaps. Deploying ML-KEM protects recorded traffic from future decryption. It does not by itself prevent a future attacker from forging a server certificate or software-signing identity.
Chrome has already stated that it does not plan to trust traditional X.509 certificate chains simply stuffed with large post-quantum signatures. Its quantum-resistant root program instead centers on MTCs, independent mirroring and operational review. That makes the browser’s acceptance process, not Cloudflare’s announced date, the critical dependency for the early 2027 target.
The unresolved questions are operational
The underlying Merkle-tree technique is well understood, but running it as public trust infrastructure creates new failure modes. Independent mirrors must remain available and agree on append-only history. Browsers need fresh landmarks without making offline or newly installed clients unreliable. Certificate monitors must process the new logs at production volume. Multiple issuers and cosigners must emerge so the replacement system does not concentrate trust in a different way.
Cloudflare’s position gives the experiment unusual scale: the company says it handles more than 20% of global internet request traffic and already manages millions of certificates through other authorities. That reach can accelerate deployment, but it also raises the standard for transparency and incident response. Cloudflare has promised reproducible builds for its signing software, hardware-security-module attestations and a public operational health dashboard. Those commitments will matter once the authority begins issuing, because a public CA is judged less by its launch claims than by how it validates domains, protects keys, revokes mistakes and recovers without taking sites offline.
The next meaningful milestones are the GlobalSign root transaction closing, root-program approvals, Chrome’s production policy and the first real MTC issuance. Until then, Cloudflare’s announcement is best read as the start of a public infrastructure project, not a switch website owners can turn on.
Featured image and architecture diagram: Cloudflare.
