Summary: Cloudflare announced on September 29, 2026 that it intends to become a public certificate authority, applying to major root programs and agreeing to acquire a trusted GlobalSign root. No certificates are being issued yet; the plan targets redundancy for free automated TLS and includes ACME-first issuance requiring ARI support. Cloudflare also plans to be among the first issuers of production Merkle Tree Certificates in Q1 2027.
Cloudflare announced on September 29, 2026 that it intends to become a public certificate authority. It has applied for inclusion in the Chrome, Apple, Microsoft, and Mozilla root programs and signed a definitive agreement to acquire an established, broadly trusted root from GlobalSign. Nothing is being issued yet — this is a public commitment with early milestones — but if you ship anything that terminates TLS, it is worth understanding why this matters.
Why a second big free CA is a systems problem
Let’s Encrypt issues on the order of ten million certificates a day and serves more than 500 million sites, per Cloudflare’s announcement. That concentration is the actual risk: if the dominant free CA has a bad week, there is no comparable free, automated fallback ready to absorb the load. Cloudflare frames its own CA as the same redundancy idea it already applies at the certificate-pack level — every Universal SSL cert ships with a backup from a different authority — but scaled to the whole Internet.
The company has felt this pain from the consumer side too. It terminates TLS for millions of domains and cites rate limits, validation edge cases, revocation latency, and root distribution lag as things it has dealt with while running its own services.
Two roots, two jobs
The root strategy is the pragmatic part. A brand-new root takes years to propagate into operating systems, browsers, and devices, and never reaches hardware that has stopped receiving updates. The acquired GlobalSign root has been trusted across clients since 2012, giving day-one reach to older devices. The new roots Cloudflare will submit are built for where policy is heading, including programs that cap root age.
The takeaway for builders: compatibility and forward-compliance are different constraints, and this design pays for both instead of picking one.
What adoption will look like
Cloudflare says the CA will be ACME-first, using the open automated issuance protocol. If you already point your tooling at an existing free CA, switching means changing a directory URL — no new tooling, nothing to re-architect. Notably, issuance will be conditional on supporting ACME Renewal Information (ARI, RFC 9773), so renewal automation is required rather than optional. When a CA needs to retire certificates, it can move renewal windows forward and spread replacements over time instead of forcing a hard revocation cliff.
The post-quantum angle
Cloudflare plans to be among the first CAs issuing production Merkle Tree Certificates (MTCs), with first certificates targeted for Q1 2027. MTCs are a compact certificate format designed for a post-quantum world where traditional chains grow large enough to strain TLS handshakes; Chrome has named MTCs its preferred path for post-quantum authentication. The plan is one CA carrying both classic certificates and MTCs, so customers can migrate at their own pace rather than maintaining two systems across a multi-decade transition.
If you are planning your own cryptographic inventory and migration path, we covered how Cloudflare’s AI-driven cryptography discovery work changes migration planning in Crypto Discovery at Scale. Knowing what algorithms you actually run is the prerequisite for any of this.
The realistic read
The transparency commitments — reproducible builds of signing software, attested hardware security modules, a public dashboard for issuance health — are the right instincts, since audits are point-in-time snapshots rather than evidence of day-to-day operations. But this is early. Root program approval is not guaranteed, Cloudflare is not issuing certificates yet, and the supplied announcement does not specify a timeline for general availability beyond the MTC target.
The practical move for now: make sure your issuance and renewal are already fully automated through ACME with ARI support. That is the requirement regardless of which CA you end up using, and it is what makes switching later a one-line change instead of a project.