What Cloudflare's post-quantum GeoKey Manager changes

Cloudflare has launched a post-quantum version of GeoKey Manager, the system that decides where in its global network your decryption keys can be used. It is in closed beta, and according to Cloudflare’s announcement, general availability is planned for Q1 2027. The detail that matters most: your encrypted key is copied to servers worldwide, but the separate key needed to unlock it is delivered only to servers verified as being in your chosen region. If that unlocking key is not present, the request is rejected.

The background you need

Why location matters for keys. When your site or app sits behind Cloudflare, HTTPS traffic is usually decrypted on Cloudflare’s servers so it can be cached, filtered, or inspected. Decryption needs your TLS private key. TLS is the protocol behind the padlock in the browser. Whoever holds that key, wherever it is, can read the traffic. Cloudflare runs an anycast network, which means the same address is answered by whichever data center is nearest to the user. By default, any of those data centers may need your key.

That clashes with data sovereignty rules. These are laws or contracts that say certain data may only be processed inside a given country or bloc. If a request from a German user can be decrypted in Singapore, the plaintext existed outside Germany, even for a moment.

Key wrapping. The fix is to encrypt the key itself. Wrapping a key means locking it inside another layer of encryption. The wrapped copy is safe to ship anywhere, because it is useless without the unwrapping key. Think of a safe-deposit box you can mail to every branch of a bank, while the box key sits only in the Frankfurt branch. The analogy breaks in one place. A real box key can be photocopied or carried out the door. Cloudflare’s design tries to prevent that with hardware identity checks and by keeping keys only in memory, as described below.

The quantum problem. Most key exchange today uses public-key math that a large enough quantum computer could break. Nobody needs that computer today to cause harm. An attacker can record encrypted traffic now and decrypt it years later. Cloudflare calls this harvest now, decrypt later. For data that stays sensitive for decades, such as health, finance, or defense data, that is a present risk.

ML-KEM and hybrid mode. ML-KEM-768 is a post-quantum key-encapsulation method that, according to Cloudflare, is a NIST standard. A KEM is a way for two parties to agree on a shared secret. X25519 is the widely used classical method. Running both together, called hybrid mode, means an attacker has to break both. If ML-KEM turns out to have a flaw, X25519 still protects you, and the reverse also holds.

Failing closed. A system fails closed when it refuses to act if a check cannot be passed. A system fails open when it proceeds anyway. For a residency guarantee, failing open would mean quietly decrypting out of region.

What actually changed

GeoKey Manager is not new. According to Cloudflare, it introduced geo-restricted TLS keys in 2017. That version let a customer, for example, allow its keys to be unwrapped only in India. In 2022 the company moved to attribute-based encryption (ABE). With ABE, policies are written as attributes such as region equals European Union, so newly authorized servers could join without rewrapping every customer key.

Cloudflare says no production-ready post-quantum ABE scheme exists. It also says customers do not need a large number of regions. So it switched to a simpler design:

• Regional root keys. Each region gets a 256-bit symmetric secret.
• Application-specific key pairs. These are derived from the root key for a single service, such as Gateway, Tunnel, Access, or the Cloudflare One client. The public half wraps your private key. The private half is needed to unwrap it.
• Hybrid post-quantum wrapping. Wrapping uses HPKE (RFC 9180) with ML-KEM-768 combined with X25519, HKDF-SHA-256 for key derivation, and AES-256-GCM for encryption.
• Split distribution. Quicksilver, Cloudflare’s global configuration system, ships wrapped keys and their metadata everywhere. Root keys travel a separate path. A provisioning service checks a server’s TPM-backed hardware identity and region membership, then issues a token that lets the server fetch only its region’s root keys.
• Memory-only storage. Root keys live in the Linux kernel keyring, not on disk. A reboot wipes them, and the server must authenticate again.
• Fail closed at two points. A server whose configured root keys are missing or malformed will not start. A request whose metadata points to a root key that is not held locally is rejected. Cloudflare’s own example: a Germany request landing in Spain or France fails. The company states: “This guarantees that a regional root key never leaves its region, no matter what.”
• Rotation. Each root-key generation is an epoch. A soft rotation keeps a limited number of previous epochs usable during a transition. A hard rotation rewraps affected keys so the old epoch can be removed.

Region membership is refreshed several times a day as servers are added or retired, according to Cloudflare. This requires no customer action.

What it means for developers who run apps

The split-distribution design is the part to understand. It is why the guarantee holds even though your wrapped key sits on servers worldwide. The residency boundary depends on which servers hold the root key, not on where your key file is stored. Because requests fail closed, the risk you trade for that guarantee is availability. If the in-region servers lack a provisioned root key, your requests are rejected instead of being served from elsewhere.

The boundary is also narrower than the product name might suggest. Cloudflare is explicit that GeoKey Manager controls where wrapped private keys can be unwrapped and used. It does not control where requests are routed, where tunnels terminate, or where traffic is inspected. Those belong to Regional Services. If a compliance review asks where data was processed, GeoKey Manager answers only part of that question.

The blast-radius model is worth reading closely. Keys with the same service, region, and epoch share one application-specific key pair, and that sharing crosses customers. In Cloudflare’s own example, compromising the Tunnel-Germany application key could expose Tunnel keys belonging to two different companies. It would not expose Gateway keys. Compromising the Germany root key could affect every application key derived from it in that epoch.

What to watch next: whether the closed beta reaches general availability on the planned Q1 2027 timeline, and which regions and products are covered when it does.

What we don’t know yet

• Which regions. Cloudflare says most of its regions will be available and that there may be product-specific caveats. It does not list them.
• Beyond Cloudflare One. The post describes the Cloudflare One path. It does not say whether or when the same post-quantum design reaches the TLS keys of ordinary CDN customers who used earlier versions.
• Migration. There is no detail on how customers on the 2022 ABE-based system move over.
• Rotation policy. The post does not say how often rotations happen, how many old epochs a soft rotation keeps (its one-generation figure is given only as an example), or who triggers a hard rotation.
• Pricing and access. Nothing is said about cost or how to join the beta.