Cloudflare’s plan to issue Merkle Tree Certificates is less about quantum computers than it is about the size of a TLS handshake, and that makes it an agent infrastructure story.
Here is what was actually announced. On September 29, 2026, Cloudflare (NYSE: NET) said it intends to become a public Certificate Authority, issuing both traditional and post-quantum certificates. The post-quantum path runs through Merkle Tree Certificates, or MTCs. Production MTC issuance is scheduled for the first quarter of 2027. The service will be built on an open-source platform, and Cloudflare will acquire a trusted certificate root from GlobalSign to smooth the transition into existing trust stores.
That is the full set of confirmed details. Everything past this point is my reading of why it matters, and I will be clear about which parts are reasoning rather than reported fact.
The quantum framing undersells the actual constraint
The public narrative around post-quantum TLS is about a future machine that breaks RSA and elliptic curve signatures. Fine. But the engineering pain of migrating to post-quantum signatures shows up long before any such machine exists, and it shows up as bytes on the wire. Post-quantum signature schemes are, as a class, substantially larger than the ECDSA signatures the web runs on today. A certificate chain carries multiple signatures and multiple public keys. Multiply that expansion across a chain and you inflate the one part of a connection that is most sensitive to size: the first round trip.
This is the structural reason a design like MTC exists. Rather than shipping every signature inline with every handshake, a Merkle-tree-based approach lets a relying party verify membership against a published structure, which shrinks what has to travel per connection. I am describing the general design logic of tree-based certificate schemes here, not a Cloudflare performance claim, because no performance numbers were published in what I have seen.
Why this lands differently for agents than for browsers
A human loading a webpage opens a handful of connections and then reuses them. An autonomous agent does not behave that way. Agent architectures that are now common in production look like this:
- A planner that fans out across dozens of tool endpoints per task step
- Retrieval layers hitting many distinct hosts, often with short-lived connections
- Model Context Protocol servers and similar tool brokers, each a separate TLS origin
- Retry and fallback logic that re-establishes connections aggressively on timeout
- Sandboxed or ephemeral execution environments that start with a cold connection pool every time
Every one of those patterns multiplies handshakes per unit of useful work. An agent loop is, from a network perspective, a handshake amplifier. If post-quantum certificate chains add kilobytes to each new connection, the cost does not land evenly across the web. It lands hardest on exactly the workloads that open the most connections and tolerate latency the worst, because latency in an agent loop compounds across sequential reasoning steps rather than being hidden behind a progress bar.
So when I read a Q1 2027 date for production MTC issuance, I do not read it as a cryptography milestone. I read it as a deadline for agent runtime maintainers to understand what their TLS stack will be negotiating.
The GlobalSign root is the most practical detail in the announcement
Acquiring an existing trusted root is the unglamorous part and probably the most consequential. New CA roots take years to propagate into browser and OS trust stores. Agent stacks are worse than browsers here, not better: they depend on whatever certificate bundle happens to be baked into a container image, a language runtime, or a pinned dependency. Those bundles go stale and nobody notices until a connection fails inside a tool call, where the error surfaces as an unhelpful agent apology rather than a security warning.
Starting from an already-trusted root sidesteps the slowest part of that problem. It does not sidestep the client-side question, which is whether the software in your agent’s dependency tree can validate a new certificate type at all.
What I would actually do before 2027
Three things, in order of how cheap they are.
First, measure your handshake-to-work ratio. Count new TLS connections per completed agent task. If that number is in the hundreds, certificate size is your problem and you should know it now rather than in a postmortem.
Second, audit where your trust roots come from. Not conceptually, concretely: which file, which image layer, which package version, and who updates it.
Third, fix connection reuse. Pooling, keepalives, and session resumption reduce exposure to certificate size regardless of which signature scheme wins. This is work that pays off today and hedges whatever 2027 brings.
The open-source platform commitment is the part I will be watching most closely. A CA that publishes its issuance stack is one that agent infrastructure teams can test against before they depend on it, and testing beforehand is the difference between a migration and an incident.
đź•’ Published: