Cloudflare beta limits where customer keys can be unwrapped to a chosen region

A rule that says data must stay in Germany is easy to write and hard to prove. In a post published October 23, Cloudflare describes a different tactic. Control the key instead of chasing the data. Wrapped copies of customer keys travel across its whole network. Only servers in the approved region can unwrap them. That is a claim about keys. It is not a claim about where traffic goes or where it is inspected.

Cloudflare's design treats residency as a question of where a key can be opened. Restricting key location is not new for the company. It began in 2017. What is new is the post-quantum rebuild.

What Cloudflare launched

Cloudflare has opened a closed beta of a post-quantum GeoKey Manager. It belongs to the company's Data Localization Suite. Each customer key is wrapped so that only Cloudflare servers in the chosen geography can unwrap it. General availability is planned for Q1 2027.

Cloudflare aims the product at government agencies, banks, hospitals and defense bodies. Their records can stay sensitive for years or decades. The company describes an attack called harvest now, decrypt later. An adversary stores encrypted traffic today. Later, a quantum computer breaks the public-key cryptography that protected it.

Cloudflare calls that only half the problem. To stay available, it copies customer data across many servers. Many sovereignty rules allow certain data to be processed only inside one region. So only servers in that region should be able to read it.

How the fence works

The design separates two things that usually travel together. The wrapped customer key goes everywhere. The secret that opens it stays regional.

Cloudflare's configuration system, Quicksilver, spreads wrapped keys and their metadata across the network. The secret that opens them is the regional root key. It takes a different road. A dedicated provisioning service holds it and releases it only to machines cleared for that region. Cloudflare says that service uses Vault, managed on its own premises.

How does a server prove where it is? Cloudflare says an internal system called Zinc keeps membership records. It links a registered hardware identity to each server and its physical location. A TPM, a security chip in the machine, backs that identity. The server presents it and receives a token. The token allows it to fetch only the root keys for its location.

Servers load those keys into the Linux kernel keyring, not onto disk. A restart wipes them. The server must then prove itself again. Cloudflare says this adds operational work but leaves less stored key material for an attacker to target.

The system also fails closed. A server missing a configured root key does not start its key service. A request that points to a root key the server lacks is rejected. In Cloudflare's example, a request for Germany cannot be decrypted in Spain or France. Neither holds Germany's root key.

The post-quantum part

In 2022, Cloudflare moved to attribute-based encryption. It described regions as rules, such as "region = European Union". Cloudflare says no production-ready post-quantum version of that scheme exists. It also says customers do not need many regions. So it chose a simpler design.

Each region gets a 256-bit symmetric root key. From it, Cloudflare derives a key pair for each service, such as Tunnel or Gateway. For the current Cloudflare One path, the scheme follows RFC 9180. It combines ML-KEM-768, a NIST standard, with the classical X25519. It adds HKDF-SHA-256 and AES-256-GCM. Cloudflare says data stays confidential as long as one of the two components holds.

What the design concentrates

This is the trade-off in the simpler design. Sharing one key pair per service, region and epoch widens what a single compromise exposes. An epoch is one generation of the root key.

Cloudflare's own example shows the scale. Compromising a Tunnel-Germany application key could expose two sample customers' Tunnel keys. Their Gateway keys would stay safe. Compromising the Germany root key could affect every key derived from it for the same epoch.

Cloudflare lists the services that can reach root keys. They are key management, provisioning and the authorized edge key services. Quicksilver sits outside that group. It sees only wrapped keys and metadata.

Rotation carries a trade-off. A soft rotation keeps limited access to earlier epochs, so services stay up during the change. A hard rotation rewraps keys so old-epoch access can be removed.

What it does not cover

Cloudflare states the limits plainly. GeoKey Manager does not control where requests are routed, where tunnels end or where traffic is inspected. Cloudflare says Regional Services handles routing and inspection. It says separate workstreams decide where tunnels terminate. It also says most regions will be available, with possible product-specific caveats.

This is Cloudflare's own description of its design, in a closed beta. It is not an independent audit.

Questions to put to your team

Which of our products and regions are covered, and what are the caveats? Who handles routing, tunnel endpoints and inspection, and does that match our residency duties? Do we want soft or hard rotation, and what outage can we tolerate? What evidence will an auditor accept that a key stayed in region?

A fenced key answers one residency question. Your auditor will ask several.

Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.