Cloudflare’s Latest Innovations: What Shipped This Autumn, and the Launch That Impressed Me Most
The most impressive Cloudflare launch this autumn is its plan to become a public certificate authority issuing Merkle Tree Certificates. They replace chains of large post quantum signatures with a compact inclusion proof, and early Chrome Beta tests showed handshakes about 9% faster at the median, mostly from dropping the intermediate certificate.
By Andrew Baker, CIO at Capitec Bank
In June I argued that Cloudflare had missed its market, and that the Internet needs a trust layer rather than another security tool. By a trust layer I meant continuous, cryptographic assurance that identities are genuine, content is unaltered and delegated authority is legitimate, for machines as much as for humans, and my view was that Cloudflare already held most of the primitives needed to provide it but kept selling itself as one more line item in the enterprise security stack. Cloudflare has since made 46 announcements in a single week, and with that much landing at once it felt like the right moment to read through all of it properly and ask a narrower question: which of these launches actually move Cloudflare towards that trust layer, and which change the architecture conversation in other ways, rather than simply adding another tile to the dashboard.
1. The Shape of the Week
Cloudflare organised the week around a theme per day: open source on the Monday, application security and the post quantum transition on the Tuesday, new economic models for agents on the Wednesday, an expanded developer platform on the Thursday, and performance, observability and accessibility on the Friday. The framing for all of it came from the founders’ letter, which made the claim that automated traffic overtook human activity on Cloudflare’s network for the first time this year. That is Cloudflare’s own measurement of its own network, so I would treat it as a statement about the traffic Cloudflare sees rather than about the Internet as a whole, but it explains why almost every announcement has an agent somewhere in its story.
If you only skim the list, the week reads like a sprawl of unrelated releases. Read more slowly and three threads come through quite clearly. The first is trust infrastructure being rebuilt for a post quantum world, the second is the developer platform filling in the remaining gaps that used to push serious workloads back to a hyperscaler, and the third is an attempt to give machines a way to pay for what they consume. I want to work through the launches that matter most under each of those threads, starting with the one I think will look the most significant in five years.
2. The Most Impressive: Cloudflare Becoming a Post Quantum Certificate Authority
Twelve years after Universal SSL made free certificates the default for millions of sites, Cloudflare announced that it intends to become a public certificate authority, and that this CA will issue Merkle Tree Certificates. Of everything shipped during the week, this is the one I keep coming back to, because it is not a feature; it is a structural change to how trust on the web is distributed, and it is the clearest move yet towards the trust layer I argued Cloudflare should be building, and Cloudflare is one of very few organisations with both the scale and the cryptographic depth to attempt it credibly.
The problem it addresses is easy to state and hard to solve. Post quantum signatures are roughly forty times larger than the classical signatures they replace, and Cloudflare notes that a typical TLS handshake today already carries five signatures and two public keys once you account for the certificate chain, revocation and certificate transparency. Simply swapping post quantum algorithms into that structure would make every handshake materially heavier, and it would inflate the storage burden on certificate transparency logs by a similar order of magnitude, which in turn makes it harder to sustain a diverse set of independent log operators.
The difference is easiest to see by comparing what has to cross the wire in each case.
flowchart TB
subgraph Today["Classical chain with post quantum signatures swapped in: five signatures, two keys"]
direction LR
T1["Leaf certificate: server key plus CA signature"] --> T2["Intermediate certificate: CA key plus root signature"]
T2 --> T3["Two or more SCT signatures from CT logs"]
T3 --> T4["TLS handshake signature"]
end
subgraph MTC["Landmark relative Merkle Tree Certificate"]
direction LR
M1["Server public key"] --> M2["Inclusion proof: a short list of hashes, under 1 kB"]
M2 --> M3["TLS handshake signature"]
M4["Signed landmark already held by the browser"] -.-> M2
endMerkle Tree Certificates, which are being standardised in the IETF PLANTS working group, take a different approach. Instead of signing each certificate individually and then logging it, the CA appends certificates to an append only Merkle tree and signs the tree head, so issuance and transparency become the same act rather than two separate steps. An independent mirroring cosigner verifies that each new tree state is consistent with the last one, which gives clients confidence that the CA is not showing different views of its issuance to different parts of the ecosystem. When a browser already holds a recent signed “landmark” for the tree, delivered out of band through its update mechanism, the server only needs to present a compact inclusion proof, a short sequence of hashes, rather than a chain of large signatures.
flowchart LR
A[Site requests certificate via ACME] --> B[CA validates domain control]
B --> C[CA appends entry to its issuance log]
C --> D[CA signs checkpoint over new tree state]
D --> E[Independent mirroring cosigner checks append only consistency and cosigns]
E --> F[CA returns MTC with inclusion proof]
F --> G{Client holds a recent landmark?}
G -- Yes --> H[Landmark relative cert: one key, one signature, small inclusion proof]
G -- No --> I[Standalone cert carrying cosigned tree head]What persuades me this is more than a whitepaper is that Cloudflare has already run it against real traffic. Earlier this year it operated a stub “bootstrap” CA with Chrome and served Merkle Tree Certificates for a selection of free plan domains to half of Chrome Beta 146 users. Cloudflare reports that in the landmark relative case the handshake carried one public key, one signature and an inclusion proof under one kilobyte, and that at the median these connections were about 9% faster than a classical signature chain. That figure needs to be read carefully, and Cloudflare is upfront about it: the experiment used classical signatures, and most of the gain came from eliminating the intermediate certificate rather than from anything post quantum. The more important result is that the mechanism worked at scale with billions of certificates served, and the expectation is that the advantage widens once the signatures being avoided are the large post quantum ones.
None of this is finished. Cloudflare is targeting early 2027 for inclusion in Chrome’s new quantum resistant root store, and it still has to pass that root program’s evaluation, build the facilities and compliance functions of a traditional CA, and see whether other CAs and independent mirrors emerge so the system has real diversity rather than a single operator. Standard MTC issuance is promised at no cost, which follows the same playbook as Universal SSL and makes the strongest available authentication the default rather than a premium option. For a bank, the practical implication is that the post quantum migration of the public web may arrive with far less handshake overhead than many of us had been budgeting for, provided the ecosystem around MTCs develops as planned.
It is also worth being precise about what kind of trust this delivers, because it is easy to overstate. A Merkle Tree Certificate gives a client efficient, transparent proof that a CA issued a certificate binding a key to a domain, and that the issuance was publicly logged and independently cosigned. It does not tell anyone whether the organisation behind that domain is trustworthy, whether an agent presenting it has been delegated any authority, or whether the content it serves is legitimate. In the language of my June article, MTCs strengthen cryptographic identity assurance, which is the foundation layer, rather than delivering the broader trust layer that sits on top of it. That distinction does not make the launch less important; it makes clear which piece of the problem Cloudflare is solving first, and why it is the right piece to start with.
3. EmDash 1.0, and Why It Stung a Little
I have a confession that makes this section personal. andrewbaker.ninja runs on WordPress, and I maintain several free WordPress plugins, including one built specifically to make analytics work correctly behind Cloudflare. So when Cloudflare shipped EmDash 1.0, its open source Astro based CMS, with a pitch built squarely around fixing the WordPress plugin security model, I read it as someone with skin in the game.
The argument is uncomfortable because it is correct. A WordPress plugin runs in the same PHP process as the rest of the site, with direct access to the database, the filesystem and the network, so a contact form plugin can technically read unpublished posts or post data to any host it likes, and site owners are trusting that neither the plugin nor any future update will do so. EmDash inverts that. Each sandboxed plugin runs in its own isolated runtime, as a Dynamic Worker on Cloudflare or as an isolated service inside workerd when self hosted on Node.js, and it gets no access to content, media, users, secrets or the network unless it declares the capability and an administrator approves it. Cloudflare compares the install experience to a mobile app permission prompt, and that comparison is about right.
The architectural difference is the whole story, so it is worth drawing.
flowchart LR
subgraph WP["WordPress: one shared PHP process"]
direction TB
WPP1["Contact form plugin"] --> WDB[("Database, including unpublished posts")]
WPP1 --> WFS["Filesystem"]
WPP1 --> WNET["Any network host"]
WPP2["Any other plugin"] --> WDB
end
subgraph ED["EmDash: one isolated runtime per plugin"]
direction TB
EP1["Contact form plugin in its own isolate"] -->|"approved: send email"| RT["EmDash runtime enforcing approved capabilities"]
EP2["Search plugin in its own isolate"] -->|"approved: read published content, call one search host"| RT
RT --> EDB[("Content, media, users")]
RT --> ENET["Approved hosts only"]
endTwo other design choices stood out to me. The plugin registry is built on the AT Protocol, so publishers keep their signed release records in their own accounts and the default catalogue is just one index over them rather than a gatekeeper that can delist or seize a plugin. And Cloudflare is running it in anger: the Cloudflare blog itself migrated to EmDash in August, which means the CMS is handling a high profile site with real traffic spikes and the occasional DDoS. The project reports more than 175 contributors and an MIT licence, which matters for anyone worried about lock in.
My honest assessment is that EmDash will not dent WordPress’s installed base quickly, because the value of WordPress is its ecosystem of themes, plugins and people who already know it, and migrations cost real time even when agents help. I would also be careful not to treat sandboxing as a complete answer. Isolation limits what a malicious or compromised plugin can reach, but it does not stop a site owner approving more capabilities than a plugin needs, it does not prevent a trusted publisher shipping a bad update within the permissions already granted, and the sandbox itself becomes attack surface that has to be maintained and patched. Supply chain risk shrinks; it does not disappear. Even so, the capability based plugin model is the right answer to a problem the WordPress world has largely accepted as a cost of doing business, and if I were starting a new content site for a regulated business tomorrow, I would at least evaluate it before defaulting to PHP.
4. Workers KV Instant: Quicksilver, Finally Exposed
Quicksilver is the key value store Cloudflare uses internally to push configuration to every location on its network, and almost every request Cloudflare serves touches it. Customers have been asking for direct access for years, and Workers KV Instant is that access, presented behind the familiar Workers KV API so existing code barely changes.
The numbers Cloudflare published are striking. At the 99th percentile, reads complete in 1.62 milliseconds compared with 287 milliseconds for classic Workers KV across all reads, and 99% of writes replicate to every edge location, more than 300 of them, in about 256 milliseconds, against 4.38 seconds at the same percentile for classic mode. It is worth being precise about what those replication numbers measure, because the two modes define them slightly differently in Cloudflare’s own table, but the direction is not in doubt.
{
"type": "bar",
"data": {
"labels": ["p99 read latency (all reads)", "p99 write replication"],
"datasets": [
{ "label": "Workers KV Instant (ms)", "data": [1.62, 256] },
{ "label": "Workers KV classic (ms)", "data": [287, 4380] }
]
},
"options": {
"plugins": { "title": { "display": true, "text": "Workers KV Instant vs classic, Cloudflare published figures (log scale)" } },
"scales": { "y": { "type": "logarithmic", "title": { "display": true, "text": "milliseconds" } } }
}
}The pricing tells you exactly what it is for. Reads are cheaper than classic KV, but storage is priced at $100 per megabyte per month, every write costs ten cents, a namespace is capped at one megabyte and 10,000 keys, and writes are limited to one per namespace per second. This is not a database; it is a fast propagating switchboard for small, hot, rarely changing values such as feature flags, routing tables and kill switches. For teams already using Workers to generate custom malware signals and block traffic on behavioural patterns, a store like this, if it performs in production the way the published figures suggest, is a natural home for the small set of flags and blocklist toggles that need to take effect everywhere within a fraction of a second. It is in private beta, so that remains an expectation rather than an experience.
That use case needs one important qualification, particularly for a bank. Fast global replication is not the same thing as strong consistency. A p99 replication figure of around 256 milliseconds describes how quickly most writes arrived in Cloudflare’s measurements; it does not guarantee that every location sees a change within that window, that all locations switch over atomically, or that a read immediately after a write will observe it everywhere. Cloudflare’s announcement describes replication speed rather than linearizability, and I would design on that basis. A security kill switch built on KV Instant should therefore fail safe: the default when a flag is missing or stale should be the protective behaviour, enforcement should not depend on every edge having received the update, and anything that genuinely requires ordered, consistent state belongs in Durable Objects or the system of record rather than a replicated cache. Used that way, KV Instant shrinks the window of exposure dramatically; it does not close it.
In practice that means the read path has to be designed so that a missing or stale value produces the safe outcome, not the permissive one.
flowchart TD
W["Operator writes kill switch once"] -. "p99 about 256 ms, not a guarantee" .-> K
R["Request reaches a Worker at an edge location"] --> K{"Read flag from KV Instant"}
K -->|"Flag says protect"| B["Apply protective control"]
K -->|"Flag missing, read error or version older than expected"| B
K -->|"Flag says normal"| S{"Does the action need ordered, consistent state?"}
S -->|"Yes"| DO["Check Durable Object or system of record"]
S -->|"No"| OK["Serve request"]5. Cloudflare Traces: Seeing the Whole Request Path
Cloudflare Traces is the launch I expect engineering teams to adopt fastest. Now in open beta, it produces a single request level trace showing how a request moved through security rules, transform rules, routing, cache decisions, Worker execution and origin handling, with timings for each span, and it does this without any agent or SDK once tracing is switched on for a domain.
The details that matter for an enterprise are all present. Sampling can be kept low by default and raised to 100% for a specific hostname, source IP or debug header using Trace Rules written in the normal Cloudflare rules language. Incoming W3C traceparent headers can be accepted, and a new traceparent can be forwarded to the origin, so Cloudflare’s spans join the same distributed trace as the rest of your stack. Spans export over OTLP to whatever OpenTelemetry backend you already run. Anyone who has tried to answer “was it the WAF, the cache or the origin?” during an incident bridge, by stitching together three log sources and a configuration export, will understand why this is a big deal.
The value is in seeing one connected trace across a boundary that has always been opaque.
sequenceDiagram
participant C as Client
participant CF as Cloudflare edge
participant O as Origin service
participant OT as OTLP backend
C->>CF: Request carrying W3C traceparent
Note over CF: Spans for security rules, transform rules, routing, cache lookup and Worker execution
CF->>O: Cache miss, forwards a new traceparent
O->>O: Application spans join the same trace
O-->>CF: Response
CF-->>C: Response
CF->>OT: Cloudflare spans exported over OTLP
O->>OT: Application spans exported over OTLP
Note over OT: One trace from client to databasePricing moves to the unified observability model from 1 December 2026, and the free plan includes half a gigabyte of ingestion per day with seven days of retention. That allowance is enough for a personal site or a proof of concept to learn the product properly before anyone signs a contract.
6. Charging Agents: HTTP 402 Gets a Job
The Wednesday announcements were the most speculative, and the most interesting to me as a banker. The Monetization Gateway, now in closed beta, lets a site owner put a price on any resource behind Cloudflare and collect payment from an agent inline with the request, using the long dormant HTTP 402 Payment Required status code and the x402 protocol. The agent receives payment instructions in the 402 response, signs an authorisation, and gets the resource once settlement completes, with no checkout redirect and no separate payments API.
The flow is short enough to fit in a single diagram, which is part of its appeal.
sequenceDiagram
participant A as Agent with wallet
participant MG as Cloudflare Monetization Gateway
participant F as x402 facilitator
participant S as Seller origin
A->>MG: Request for a priced resource
MG-->>A: 402 Payment Required with payment instructions
A->>A: Sign payment authorisation
A->>MG: Retry request with signed payment
MG->>F: Verify and settle in USDC on Base
F-->>MG: Settlement confirmed
MG->>S: Forward request
S-->>MG: Resource
MG-->>A: 200 OK with resourceToday that settlement runs through Coinbase’s x402 facilitator in USDC on the Base blockchain, and the beta is limited to eligible U.S. based sellers and buyers, with other geographies promised but undated. Cloudflare’s reasoning is that existing card rails assume large transactions, tolerant latency and an identifiable buyer, whereas agents want tiny, fast, frequent payments, and that stablecoin networks can serve that pattern now while other rails may follow. Whether stablecoins become the long term answer is a separate debate, and payment networks and banks have every incentive to compete for this flow, but the underlying observation about consumption based pricing for machine callers feels right.
From a banking perspective, though, moving the money is the easy part, and it is where I think the debate is currently looking in the wrong place. The hard questions in machine payments are about authority and liability. Who authorised this agent to spend, and on whose behalf? How are spending limits defined and enforced when an agent can make thousands of requests a minute? What does a dispute look like when the buyer is software and the purchase was a single API call? And who bears the loss when an autonomous agent buys the wrong thing, buys too much of it, or is manipulated into paying a malicious endpoint? HTTP 402 and x402 standardise the payment interaction, which is genuinely useful, but they do not answer any of those questions. Card networks and banks have spent decades building mandates, limits, chargebacks and liability rules for human initiated payments, and the equivalent framework for agent initiated payments does not yet exist. Whoever builds it, whether that is the payment networks, the banks or infrastructure providers like Cloudflare, will capture far more value than whoever simply moves the stablecoin.
Put side by side, the gap between what the protocol standardises and what a bank would need before relying on it is stark.
flowchart TB
subgraph Covered["Standardised by HTTP 402 and x402"]
direction LR
P1["Price discovered inline with the request"] --> P2["Signed payment authorisation"] --> P3["Settlement and delivery"]
end
subgraph Open["Not yet standardised for agent payments"]
direction LR
G1["Mandate: who authorised this agent, for what"]
G2["Spending limits across thousands of calls"]
G3["Disputes and refunds for one API call"]
G4["Liability when an agent is wrong or manipulated"]
end
Open -. "needed before regulated institutions can rely on it" .-> CoveredIf you want to see what a 402 handshake looks like, API2PDF is one of the launch customers and its unauthenticated endpoint now returns one. The script below sends the same request Cloudflare used in its announcement and decodes the payment instructions header so you can read them. It does not pay for anything.
cat > x402-probe.sh << 'EOF'
#!/usr/bin/env bash
# Probe an x402 enabled endpoint and decode the payment instructions.
# Sends one unauthenticated request; makes no payment.
set -euo pipefail
URL="${1:-https://v2.api2pdf.com/chrome/pdf/html}"
HEADERS=$(curl -s -o /dev/null -D - -X POST "$URL" \
--header "Content-Type: application/json" \
--data '{"html":"<p>Hello from an AI agent</p>"}')
STATUS=$(echo "$HEADERS" | head -n 1)
echo "Status: $STATUS"
PAYLOAD=$(echo "$HEADERS" | grep -i '^payment-required:' | cut -d' ' -f2- | tr -d '\r' || true)
if [ -z "$PAYLOAD" ]; then
echo "No payment-required header returned."
exit 0
fi
python3 - "$PAYLOAD" << 'PY'
import base64, json, sys
raw = sys.argv[1]
raw += "=" * (-len(raw) % 4)
try:
print(json.dumps(json.loads(base64.b64decode(raw)), indent=2))
except Exception as exc:
print(f"Could not decode payload: {exc}")
PY
EOF
chmod +x x402-probe.sh
./x402-probe.shFor South African businesses the immediate takeaway is simply to watch this space, because the beta is not available to us yet. The longer term point is that if agents become a meaningful share of API consumers, then pricing per request, inline, without an account or an API key, removes the signup friction that API2PDF says previously cost it more than half of its conversions.
7. The Performance Claim, Read Carefully
Cloudflare reports that it is now the fastest provider in 74% of the world’s 1,000 largest networks, up from 60% in April, measured as the trimean of TCP connection time from real user browsers against CloudFront, Google, Fastly and Akamai. That is a big jump in four months, and I would like it to be entirely true, because faster connection times are good for everybody behind the platform.
It is worth noticing, though, that the jump coincides with a change in methodology. Cloudflare added measurements collected from its Challenge Pages to the existing error page measurements, which substantially increases sample volume, and it says itself that in many networks the leading providers are separated by a millisecond or two, close enough for day to day noise to flip the ranking. More data should produce more stable rankings, and Cloudflare argues it produces a clearer signal where the race is close, but that argument cuts both ways. A ranking taken before a methodology change and a ranking taken after it are not measuring the same thing, so the move from 60% to 74% is not a clean measure of performance improvement, however plausible some real improvement may be. The honest reading is that Cloudflare is now the fastest provider in 74% of top networks under its new methodology, which is a self reported benchmark rather than an independent verdict, and the change since April cannot be cleanly attributed to faster infrastructure. I also did not see anything in the week’s announcements that speaks directly to private peering with the hyperscalers in South Africa, which remains a practical consideration for banks here.
8. Honourable Mentions
Several smaller launches deserve attention even though they did not make my top five:
- The new
cfCLI mirrors the entire Cloudflare API with JSON first output and typed configuration, and Cloudflare open sourced Forge, the pipeline that generates it along with the SDKs and documentation, which makes the platform far easier for both engineers and coding agents to drive consistently. - HTTP Analytics, Log Explorer and Logpush now show whether each request negotiated post quantum key exchange, giving security teams evidence they can report on rather than an assumption.
- Workers gained opt in native Web Crypto support for ML-KEM and ML-DSA, so developers no longer need to bundle their own post quantum implementations.
- Cloudflare helped develop an IETF extension that authenticates the full IKEv2 transcript, closing off downgrade attacks against post quantum IPsec tunnels.
- Threat Signals turns open source threat reporting into structured indicators that connect to WAF rules, and the Threat Events Platform is now available to every Cloudflare account, including free ones.
- AI Gateway’s Auto Router classifies each request at the edge and sends it to a suitable model to reduce spend, and User Insights flags where a smaller model would probably do the job.
- Basin, a serverless data platform built on Apache Iceberg and R2, reached general availability, alongside K2, a durable, ordered event stream on R2 that removes the need to run a broker cluster.
- Containers were rebuilt for agent sandboxes with faster startup and filesystem snapshots, and Protected Quick Tunnels now support email authentication so a local app can be shared with specific people without anyone needing a Cloudflare account.
- One year into the “enterprise for everyone” pledge, Logpush, multi account governance and higher platform limits are now available on more plans.
9. Conclusion
My argument in June was that Cloudflare should stop presenting itself as a security tool and start behaving like the Internet’s trust layer, and this wave of launches is the first time I have seen something that looks like a coordinated move in that direction. Cloudflare is assembling the infrastructure from which a new trust layer could emerge. Merkle Tree Certificates make strong authentication cheaper, EmDash makes software permissions explicit, Traces makes infrastructure decisions observable, and x402 makes machine to machine commerce mechanically possible. None of these establishes trust on its own, and it would be a mistake to confuse trust infrastructure with trust itself. Together, however, they suggest that Cloudflare is moving beyond protecting traffic towards helping define how machines establish identity, exchange value and verify one another.
Arranged as layers, the launches line up as a stack with a conspicuous gap at the top.
flowchart BT
L1["Cryptographic identity: Merkle Tree Certificates, post quantum TLS"] --> L2["Software integrity and permissions: signed EmDash plugins, capability sandboxing"]
L2 --> L3["Observable enforcement: Cloudflare Traces, post quantum visibility in logs"]
L3 --> L4["Machine commerce: Monetization Gateway and x402"]
L4 --> L5["Still missing: delegated authority, agent reputation and liability"]If I had to pick one launch that will matter most, it is the certificate authority, because Merkle Tree Certificates attack the hardest part of the post quantum migration, the size and cost of authentication, at the level of the web’s trust infrastructure rather than inside one company’s stack. If I had to pick the one that will matter most to my own weekends, it is EmDash, because it forces an honest conversation about how much risk we quietly accept every time we install a plugin. And the one I most want to see generally available is KV Instant, because a sub two millisecond global switchboard is exactly the primitive that edge security logic has been missing.
There is still a gap between the primitives and the product. None of these launches is framed to customers as a trust layer, several of the most important are betas with the usual caveats, the Monetization Gateway is not yet available in South Africa, and machine identity for agents, which I argued was the most urgent use case, is still spread across separate features rather than offered as one coherent service. The remaining question is whether Cloudflare recognises that these are components of a much larger product: one that joins cryptographic identity, delegated authority, observable enforcement and accountable payment into a single service that humans and agents can rely on. That deserves the attention of every architecture team, not just the ones that already use Cloudflare.
Andrew Baker is the Chief Information Officer at Capitec Bank in South Africa. He writes about enterprise architecture, cloud infrastructure, banking technology, and leadership at andrewbaker.ninja.