Skip to main content

Cloudflare Tunnel: post-quantum by default, not by guarantee

· 16 min read
Vadim Nicolai
Vadim Nicolai
Senior Software Engineer

The Cloudflare Tunnel overview states its promise in a single line: connect your origin servers, APIs, and services to Cloudflare "with post-quantum encrypted tunnels — no public IPs required."

That sentence describes the software's default behaviour. One level down, in the run-parameter reference, the same documentation explains what happens when the default does not hold. cloudflared connects over QUIC using post-quantum cryptography, the docs say, "but will fall back to non-PQ if there are issues connecting."

Both statements are accurate. The distance between them is one flag wide, and Cloudflare's own roadmap explains why that distance matters: "Adding support for PQ cryptography is not enough. Systems must disable support for quantum-vulnerable cryptography to be secure against downgrade attacks." The tunnel ships the support. The flag is how you disable the fallback.

What "post-quantum encrypted tunnel" covers​

A Cloudflare Tunnel is an outbound-only connection. You install cloudflared on a server, it dials out to Cloudflare's network, and you map public hostnames to local services — the documentation's own example maps app.example.com to http://localhost:8080. Nothing listens on an inbound port, so there is no public origin IP to scan, and CDN caching, WAF, Bot Management and DDoS protection apply to traffic arriving through the tunnel.

The connection model matters. Each cloudflared instance holds four long-lived connections to at least two distinct Cloudflare data centers. A replica is another cloudflared instance on the same tunnel, adding four more connections. You can run up to 25 replicas, or 100 connections, per tunnel, routed to the geographically closest replica. Connections leave on port 7844 to cftunnel.com over TCP or UDP and to quic.cftunnel.com over UDP.

One entry in that allowlist is a tell: alongside the production endpoints sits pqtunnels.cloudflareresearch.com, labelled post-quantum error reporting. Post-quantum handshakes fail in ways classical ones do not, and Cloudflare instruments for them.

The documented fallback: connecting beats staying post-quantum​

Here is the mechanism, from the run parameters. The --protocol flag takes auto, http2, or quic, and defaults to auto — which selects QUIC, and falls back to HTTP/2 if cloudflared cannot establish UDP connections at all.

--post-quantum is the flag that matters. Without it, the QUIC connection is post-quantum encrypted but permitted to negotiate something weaker should problems arise. With it, the documentation states, "quic connections are only allowed to use PQ key agreements, with no fallback to non-PQ."

cloudflared tunnel run --post-quantum <UUID or NAME>

The environment variable TUNNEL_POST_QUANTUM does the same job for container deployments.

The flag's history explains the documentation's phrasing. It shipped in cloudflared 2022.9.1 as a beta restricted to QUIC, and was then the only way to get post-quantum at all; Cloudflare later made post-quantum the default, which redefined the flag from enable to require. The trade-off is explicit: a tunnel that must be post-quantum cannot degrade to a classical handshake to stay up, so a negotiation failure becomes an outage instead of a silent downgrade. For anyone whose reason for caring is an adversary recording ciphertext today to decrypt later, that is the correct default. A connection that quietly fell back to X25519 is precisely the traffic that gets harvested.

HTTP/2 has no post-quantum key agreement at all​

There is a second way to lose the property, and it does not announce itself. The same reference page states, in one line, that post-quantum key agreements are not supported when using the http2 protocol.

Combine that with the auto default and the failure mode is easy to construct. An egress firewall that permits TCP 7844 but drops outbound UDP leaves cloudflared unable to establish QUIC; it falls back to HTTP/2; the tunnel comes up, serves traffic, and passes every health check you have. It is also not post-quantum, and no error is raised, because nothing went wrong — the software did exactly what it is documented to do.

Cloudflare's own requirement narrows this further. Post-quantum key agreement on Cloudflare "is only supported in protocols based on TLS 1.3 (including HTTP/3)", per the PQC overview. HTTP/2 in this context is not a slower route to the same security property. It is a route without it.

Why key agreement shipped years before signatures​

To see why a tunnel can be post-quantum today while browsers wait, split the TLS handshake into the three algorithms it has always needed:

  • Symmetric ciphers encrypt the data. Already post-quantum secure.
  • Key agreement lets client and server derive a shared secret. Broken by Shor's algorithm in its classical form.
  • Signatures authenticate the certificate. Also broken by Shor's algorithm.

Symmetric encryption being settled means two migrations remain, and they are not equally difficult. Cloudflare deployed hybrid post-quantum key agreement — X25519MLKEM768, TLS identifier 0x11ec, standardized in August 2026 as RFC 10024 — and has supported it for every website and API served over TLS 1.3 since October 2022.

The word hybrid is load-bearing. The classical X25519 exchange still happens alongside ML-KEM, so a future break in the post-quantum half does not by itself expose the session. Hybrid deployment also changes nothing in the trust model: no certificate is reissued, no root store is updated, no validator learns a new object. Client and server negotiate an extra key share and carry on.

Signatures are a different kind of change, because they live inside certificates and trust anchors. Migrating them means moving an entire public-key infrastructure at once. Cloudflare's 2025 status report describes the resulting stalemate precisely: "We are in an interesting in-between time, where a lot of Internet traffic is protected by post-quantum key agreement, but not a single public post-quantum certificate is used."

That is why the product status table reads the way it does. For the connection from visitors to Cloudflare, post-quantum signatures are "planned via Merkle Tree Certificates". For Cloudflare's internal network, they are "not yet". For the Cloudflare Tunnel, key agreement is deployed and signatures are "not yet".

The one place signatures already work is the connection from Cloudflare to an origin server, where ML-DSA arrived via Authenticated Origin Pulls and Custom Origin Trust Store — announced on 29 July 2026. That leg is tractable for the same reason the tunnel is: both ends of the connection are few and known, rather than the open web.

The 2,420-byte problem​

Post-quantum signatures are large, and size is what breaks things.

Cloudflare put a number on this in a September 2026 post about DNSSEC: each ML-DSA-44 signature is 2,420 bytes — about nine and a half times an RSA-2048 signature and thirty-eight times an Ed25519 one. In DNS, the post notes, that exceeds common UDP limits before the response contains anything else.

A TLS certificate chain carries several signatures. Cloudflare's 2025 status report estimates that replacing every signature with ML-DSA-44 adds roughly 15 kB of handshake data, and records the practical ceiling: some clients and middleboxes misbehave beyond a 10 kB certificate chain, an earlier experiment measured about a 15% handshake slowdown from 9 kB of extra data, and Chrome — which reports a 4% slowdown from post-quantum key agreement alone — targets a maximum 10% regression.

Merkle Tree Certificates are the proposed escape: instead of shipping a chain of post-quantum signatures, a server proves inclusion in a Merkle tree with a proof Cloudflare describes as under 800 bytes in the common case, replacing every signature except the handshake signature itself. Cloudflare expects the first ML-DSA certificates in the WebPKI in early 2027, with Merkle Tree Certificates targeting initial deployment the same year.

Key agreement pays a smaller version of the same cost. An X25519MLKEM768 key share is 1,216 bytes in the ClientHello where X25519's is 32, the sizes RFC 10024 fixes, which typically pushes the hello across two packets. That is exactly the protocol ossification risk Cloudflare measured: testing the fast approach of sending the post-quantum key share immediately, 0.05% of origin connections broke. "That's too high to enable the fast method by default," the company concluded, and it shipped a slower method that costs a HelloRetryRequest round trip instead.

That cost is being engineered away. Automatic Key Exchange, announced on 8 September 2026, probes each origin to learn which key agreement it prefers instead of guessing. X25519 was suboptimal for roughly 30% of origin connections measured; HelloRetryRequests fell from about 52% to 3.7%; p90 handshake latency dropped by more than 150 ms.

For browsers, the certificate problem still has no shipped answer. Chrome is not planning to add standard X.509 post-quantum certificates to its public root store, developing Merkle Tree Certificates in the IETF PLANTS working group instead, currently in a feasibility study with Cloudflare. Every browser in Cloudflare's support matrix — Chrome and Edge 131+, Firefox 132+, Safari 26+ and the rest — ships post-quantum key agreement by default and post-quantum signatures as "not yet".

The 2029 deadline is about authentication​

The 2029 target is not about the half already shipped, and Cloudflare says so directly: "We now target 2029 to be fully post-quantum (PQ) secure including, crucially, post-quantum authentication." Its earlier work is described as encryption-only, mitigating harvest-now-decrypt-later. US Executive Order 14412, signed in June 2026, gives federal agencies until the end of 2030 for post-quantum key establishment and the end of 2031 for digital signatures.

The published milestones break the remainder down by hop. Post-quantum authentication for Cloudflare-to-origin connections was due mid-2026 and has landed. Post-quantum authentication from visitors to Cloudflare, using Merkle Tree Certificates, is slated for mid-2027. Cloudflare One adds it in early 2028. Full coverage is the 2029 target. Those markers are coarse and Cloudflare notes they are subject to change, but they answer the question a tunnel operator actually has: nothing on the tunnel's authentication path is scheduled ahead of the visitor-to-edge work, because the same certificate problem gates both.

One reason the target moved is an error-correction result — one estimate among several, not a settled date. A March 2026 preprint, Shor's algorithm is possible with as few as 10,000 reconfigurable atomic qubits, estimated that P-256 could fall to roughly 10,000 reconfigurable atomic qubits, because neutral-atom machines need on the order of three to four physical qubits per logical qubit where superconducting designs need around a thousand. Cloudflare's reading is that "Q-Day has been pulled forward significantly from typical 2035+ timelines, with neutral atoms in the lead."

Estimates vary widely, and the spread is the honest context for the 2029 deadline. NIST's draft transition guidance says plainly that "there are significant uncertainties in estimating the security strengths of post-quantum cryptosystems", and the G7 cyber expert group points to 2035 as an overall migration target, with the most critical systems addressed in 2030–32.

The migration itself is measurable and partly done. Cloudflare reported in April 2026 that over 65% of human traffic to its network is post-quantum encrypted, up from over 50% in October 2025, with client support rising from under 3% at the start of 2024 to over 60% by February 2026. Origin support is the laggard: around 10% of origins could benefit from a post-quantum-preferred key agreement as of that February, up from under 1% at the start of 2025.

That gap — most traffic in, a tenth of origins ready — is the argument for the tunnel. The visitor-to-edge hop became post-quantum automatically, because browsers shipped it. The origin hop needs someone to upgrade a server, and most have not. A tunnel sidesteps the server upgrade entirely.

What the tunnel does not protect​

The flag encodes a trade-off worth making explicit:

--post-quantumTransport acceptedOn a post-quantum negotiation failure
off (default)QUIC, falling back to HTTP/2falls back to a non-PQ handshake
onQUIC onlythe connection fails; no downgrade

Three limits are worth stating plainly, because the marketing sentence does not carry them.

The tunnel ends at the daemon. cloudflared is the post-quantum endpoint, and the hop from cloudflared to your application is a local connection — usually plain HTTP on loopback, exactly as the getting-started example shows. Post-quantum protection is a property of the wide-area leg. If your threat model includes that last hop, it is a separate problem.

There is no post-quantum authentication on the tunnel path yet. The docs are explicit that post-quantum signatures are not yet used for authentication between cloudflared and Cloudflare's network. The tunnel hardens confidentiality against harvest-now-decrypt-later. It does not protect authentication against a future quantum adversary, and the milestone ladder suggests it will not before 2027 at the earliest.

A Cloudflare-side tick is not end-to-end security. The product table carries its own caveat: a Cloudflare-side entry "only delivers end-to-end post-quantum protection when the party on the other side of the connection also supports the same post-quantum algorithms." On the tunnel leg that party is cloudflared, Cloudflare's own software — one reason this leg is the easiest in the stack to secure, unlike the browser leg, where Cloudflare controls only one end.

Keep the threat in proportion, too. Harvest-now-decrypt-later is a confidentiality threat over a long horizon, not a claim that today's traffic is readable today. Cloudflare's DNSSEC post says directly that "quantum computers capable of carrying out these attacks do not exist today", and presents 2029 as its own target and 2030 as a possibility it prepares for rather than a known date. The reason to migrate now is not that the machine exists. It is that the coordination takes years, and recorded ciphertext does not expire.

Five checks on your own tunnel​

  1. Confirm the transport is QUIC. If outbound UDP to port 7844 is blocked, cloudflared falls back to HTTP/2 and the tunnel loses post-quantum key agreement entirely. Ensure UDP egress to cftunnel.com and quic.cftunnel.com is permitted.
  2. Pin the flag. Add --post-quantum, or set TUNNEL_POST_QUANTUM, so a downgrade fails loudly instead of succeeding quietly. Accept that this converts some recoverable connection problems into outages — that is the intended trade.
  3. Check the hop after the daemon. Decide deliberately whether plain HTTP from cloudflared to your service is acceptable, and terminate TLS locally if it is not.
  4. Track signatures separately. The tunnel's key agreement is deployed; its signatures are not. If your requirement includes post-quantum authentication, the tunnel does not meet it yet, and neither does any browser.
  5. Read the status table, not the announcement. Cloudflare's PQC in Cloudflare products page is updated per leg and is the only place the key-agreement and signature columns are kept apart.

The tunnel is the cheapest post-quantum upgrade available to most operators today, precisely because it asks only for the half of the migration that has already shipped. What it does not do is make the decision for you: the default keeps working either way, and only the flag tells you which tunnel you actually got.

Sources and further reading​