Cloudflare announces free certificate authority for quantum-resistant TLS

Cloudflare announced, on October 5, 2026, plans to operate a public, free certificate authority (CA) dedicated to issuing quantum-resistant TLS certificates. The announcement, detailed by Mari Galicer on the company's blog and reported by InfoQ, targets a structural problem that has been holding back the adoption of post-quantum cryptography on the web: digital signatures resistant to quantum attacks are too large for the traditional X.509 certificate model.

So far, the post-quantum race has progressed well on key exchange, but has stalled on authentication. Cloudflare wants to unlock this second half with an architecture it calls Merkle Tree Certificates, currently under discussion in the IETF's PLANTS working group.

Why post-quantum certificates weigh 40 times more

TLS security today depends almost entirely on classic asymmetric primitives, such as RSA and elliptic curve cryptography. In a post-quantum world, NIST has standardized algorithms such as ML-DSA and Falcon to protect against attacks based on Shor's algorithm, which a sufficiently large quantum computer could run against current keys.

The problem is one of size, not theory. Directly swapping RSA or ECC for ML-DSA or Falcon within the traditional hierarchical chain of X.509 certificates inflates the volume of data exchanged during the handshake by about 40 times, according to Cloudflare. In practice, this means:

• Multi-kilobyte certificate chains on every new TLS connection;
• TCP packet fragmentation on networks with restricted MTU;
• Extra round trips (RTT) just to complete the handshake;
• Overhead on Certificate Transparency logs, which publicly record every issued certificate and were not sized for signatures this large.

On mobile networks or networks with packet loss, this extra weight isn't just a performance detail: it can mean the handshake failing or the connection dropping before the page even loads.

Cloudflare's solution: Merkle Tree Certificates

Instead of individually signing each server certificate with a heavy post-quantum signature, the Merkle Tree Certificates model groups issuances into an append-only Merkle tree structure (one that only grows, and is never rewritten). The CA signs only the root of that tree with a post-quantum signature; the leaf nodes, which represent individual certificates, rely on compact cryptographic hashes.

This also changes the relationship between issuing and logging a certificate. Today, in a traditional CA, the X.509 certificate is generated and only afterward sent, asynchronously, to third-party Certificate Transparency logs, which return a signed timestamp (SCT). In the Merkle tree model, issuance and logging become the same process: the CA inserts the entry into the tree, and the certificate itself becomes a proof of inclusion referencing that tree's signed root (the "tree head").

The practical gain is that, instead of delivering several heavy signatures during the connection, the server sends only its leaf entry plus an authentication path with intermediate hashes, whose size grows logarithmically with the depth of the tree, much lighter than a full post-quantum signature.

A lighter handshake, with a caching trick

To further reduce traffic, clients and browsers can cache synchronized versions of the "tree heads," called landmarks. When the client already trusts a recent landmark, the server only needs to send the truncated inclusion proof between its leaf and that landmark, which brings handshake size close to parity with traditional elliptic curve connections.

Cloudflare's implementation is hybrid: each edge endpoint receives both a conventional X.509 certificate and a corresponding Merkle Tree Certificate. During TLS negotiation, modern clients that signal support for this authentication receive the compact, tree-based proof; legacy clients fall back, without breaking anything, to the standard X.509 chain.

According to InfoQ, Cloudflare has already run production experiments in partnership with the Chrome engineering team, and observed that the architecture maintained low handshake latency while preserving end-to-end auditable transparency. Mari Galicer, who detailed the initiative on Cloudflare's blog, noted that turning logging into an architectural prerequisite of issuance itself prevents untracked certificates from entering circulation.

What changes for those operating web infrastructure

For engineering teams that manage certificates in production, the post-quantum transition via Merkle Tree Certificates brings trade-offs that go beyond swapping one algorithm for another. Since tree heads are updated on a continuous cadence, certificates become tied to short validity windows, which pushes the industry even further toward automated renewal via protocols like ACME, instead of long-lived certificates issued manually.

In summary: whoever automates certificate issuance and renewal today is already more prepared for this transition than those who still treat TLS as static configuration. Three points are worth auditing:

1. Whether the automated certificate manager in use (whether ACME or an internal tool) supports renewal in short windows and handles multiple certificate formats per endpoint well;
2. Whether the client-side cryptographic libraries used in the stack (mobile, embedded, low-level HTTP libraries) already have or will have support for hybrid verification;
3. Whether the application's edge topology supports serving two certificate types simultaneously during the transition period.

Timeline and what remains open

Cloudflare plans to open standard issuance at no cost for any web property, with broad public issuance expected in early 2027, coinciding with inclusion in browser trust stores, such as Chrome's Quantum-resistant Root Store. Until then, the Merkle Tree Certificates model remains under discussion at the IETF via the PLANTS group, which means specification details may still change before final standardization.

For now, points remain open that Cloudflare itself has not publicly detailed as of the announcement: how interoperability will work with competing CAs that adopt the same standard, what real support will look like in TLS libraries outside the Chrome/Cloudflare ecosystem, and how teams that depend on wildcard certificates or legacy automation will migrate without rebuilding entire issuance pipelines. For those building and operating web services in Brazil, the 2027 timeline still leaves time to follow the standardization process at the IETF before deciding when to migrate.