Your Keys Can Only Wake Up in Germany: Inside Cloudflare's Post-Quantum GeoKey Manager

Key takeaways

• Cloudflare’s PQ GeoKey Manager, launched October 23, 2026 in closed beta with general availability planned for Q1 2027, wraps customer decryption keys so they can only be unwrapped on servers inside a customer-chosen geography. A request that lands anywhere else fails closed: it is rejected, not rerouted to a server that can help.
• The design answers two threats at once. Harvest now, decrypt later means an adversary can record encrypted traffic today and decrypt it once a quantum computer arrives. Geographic rules mean some data must never be decrypted outside a region at all. A key that can only wake up in Germany, and that resists quantum decryption, covers both.
• The mechanism is a hierarchy, not a single key. A 256-bit symmetric regional root key per region is used to derive application-specific key pairs for one service, one region, one epoch. The wrapped key travels globally through Cloudflare’s Quicksilver distribution system, but the root key never does. It reaches authorized edge servers only, through a separate provisioning path, and on edge servers it lives only in volatile kernel keyring memory, never on edge disk (the provisioning service stores the master copies in on-prem Vault).
• The wrapping itself is hybrid HPKE (Hybrid Public Key Encryption): ML-KEM-768 plus X25519, with HKDF-SHA-256 key derivation and AES-256-GCM authenticated encryption. Hybrid means the wrapping stays safe as long as at least one of the two key-encapsulation mechanisms holds, which is the honest posture while post-quantum algorithms are still young.
• For Canadian teams, the question to carry into vendor calls is not whether a vendor promises residency. It is what happens mechanically when a request lands in the wrong place, who holds the root keys, and what the vendor’s definition of a region includes. A promise that fails open is not a control.

Some data stays sensitive for a long time. A health record, a defence contract, a financial file: these can matter for decades after they are created. That long horizon is what makes harvest now, decrypt later a real threat rather than a thought experiment. An adversary does not need a quantum computer today. It needs a hard drive, patience, and a copy of your ciphertext. When the machine arrives, the recorded traffic opens.

Now add a second constraint, one that privacy teams in Canada know well. Some data must not be decrypted outside a chosen geography at all. Regulations, contracts, and client expectations draw lines on maps, and a global network that replicates data everywhere for availability crosses those lines by default. Cloudflare’s network is exactly that kind of network: anycast, everywhere, built to serve from wherever is closest. Squaring that architecture with a promise like “this key only works in Germany” is a genuine engineering problem, and it is the problem the company’s new post-quantum GeoKey Manager tries to solve.

Two threats, one key system

Start with the quantum half. Classical public-key cryptography, the RSA and elliptic-curve machinery that protects most key exchanges, breaks against a sufficiently powerful quantum computer running Shor’s algorithm. Nobody knows when such a machine arrives, and that uncertainty is the point. Data encrypted today with classical key exchange can be recorded today and decrypted later. The defence is to move to post-quantum algorithms standardized by NIST, and to do it before the harvest window matters. Cloudflare has been migrating its own products to post-quantum cryptography; this launch is the next step.

The geography half is older. Cloudflare pioneered geo-restricted TLS keys in 2017 with the original GeoKey Manager: a customer could say that its private TLS keys only unwrap in India, so TLS signing for its requests happens in the India network, not anywhere else on the anycast mesh. In 2022 the system evolved to ciphertext-policy attribute-based encryption, or ABE, which expressed geographic requirements as attributes, like “region equals European Union” or “region equals Canada plus United States plus Mexico.” Newly authorized servers could receive matching decryption capabilities without rewrapping every customer key.

That flexibility created the opening for the new design, and also its main tradeoff. No production-ready post-quantum ABE scheme exists today, and Cloudflare says customers do not need a large number of regions. So the new GeoKey Manager drops ABE and goes simpler: hybrid ML-KEM-768 and X25519 protection, with two kinds of keys. A regional root key is a symmetric secret tied to one region. An application-specific key pair is derived from it for a single service, such as Gateway or Tunnel. The result protects private-key material against harvest now, decrypt later while keeping regional key-use boundaries intact. Simpler to operate, easier to audit, and it gives up the attribute flexibility of ABE. That is a tradeoff to name plainly, not a detail to bury.

The hierarchy: roots, application keys, epochs

Every wrapped customer private key carries metadata with three fields: service context, regional boundary, and epoch. The service context is the Cloudflare service that uses the key, Tunnel or Gateway, for example. The regional boundary is the approved set of data centers where the key may be unwrapped and used, data centers in Germany or in the European Union, for example. The epoch identifies which generation of the regional root key the key belongs to. Each rotation creates a new epoch.

Keys that share a service context, regional boundary, and epoch share an application-specific key pair. Cloudflare’s own example makes the blast radius concrete. Acme Co. has one key for Tunnel in Germany and another for Gateway in Germany. Road Runner Inc. has one key for Tunnel in Germany and another for Gateway in the European Union. Compromising the Tunnel-Germany application-specific private key could expose both Acme’s and Road Runner’s Tunnel-Germany keys, but not their Gateway keys. Compromising the Germany regional root key could affect every application-specific key derived from that root for the same epoch. That is the hierarchy doing its job: damage stays inside the box it happened in, and the boxes are drawn along lines a customer can reason about.

The current architecture uses asymmetric application-specific key pairs. The public component wraps the customer’s private key material. The private component is required to unwrap it. The wrapped private key is then distributed with its service context, region, and epoch attached as metadata.

Two distribution paths, and why the split matters

Here is the part of the design that deserves the most attention, because it is where most “sovereignty” marketing falls apart. GeoKey Manager separates two things that other systems mix: the globally distributed wrapped keys, and the regional root keys that can unwrap them.

Quicksilver, Cloudflare’s global configuration distribution system, carries wrapped private keys and their metadata across the whole network. It never carries regional root keys. Those travel a separate provisioning path: a provisioning service stores them, backed by Vault managed on premises, and delivers them only to edge servers authorized for each region.

Authorization is where hardware meets inventory. Before an edge server can receive a regional root key, the provisioning service checks three inputs. First, a Trusted Platform Module proves the server holds a registered hardware identity. Second, Zinc, Cloudflare’s server inventory system, maps that identity to a data center and a physical location. Third, the provisioning service decides which regional root keys that server may access. The server presents its hardware identity, receives a token that permits only the regional root keys authorized for its location, and fetches those keys.

Then the keys are loaded into the Linux kernel keyring, not written to disk. Process-level access controls limit which services can use them. Because the memory is volatile, a machine restart wipes the keys, and the server must authenticate and provision them again. That is operational complexity bought on purpose: less persistent key material lying around for an adversary to find.

Membership is not static either. As servers enter or leave service, Zinc updates which data centers make up a region, the provisioning layer refreshes that membership several times a day, and the updated definition propagates swiftly through Quicksilver. When regional membership changes, the provisioning service synchronizes each server’s kernel keyring with the latest authorized set. A region, in this system, is a living inventory list, not a line drawn once on a map. Keep that in mind the next time a vendor says “your data stays in region X” without saying what region X contains this week.

Fail closed, or it is not a control

The design choice that matters most for a privacy team is the failure mode. GeoKey Manager fails closed, deliberately and at two levels.

At startup, the edge key service, the component on each edge server that unwraps customer private keys and serves requests, verifies that it has loaded every regional root key its configuration requires. If a configured key is missing or malformed, the service does not start. It does not limp along and hope.

At request time, if a request’s metadata identifies a regional root key that is not locally available, the request fails. Cloudflare’s example: a request for Germany that somehow tries to decrypt in Spain or France fails, because neither Spain nor France holds the regional root key for Germany. The guarantee is stated absolutely: a regional root key never leaves its region, no matter what.

Failing open would mean unwrapping a customer’s private key outside its allowed region rather than rejecting the request. Cloudflare says it never does that. If any required check fails, service context, region, epoch, the request is rejected. An edge server serves requests for a region only once its configuration and key provisioning are complete.

This is the test to apply to any vendor’s residency claim. Ask what happens when the check fails. If the answer is that traffic reroutes, retries elsewhere, or degrades gracefully to a server that can help, the residency promise is a routing preference, not a control. A control refuses.

Run the key check yourself

The hierarchy is easier to feel than to read. Below is a simulator built from the mechanism described above. Pick a wrapped key’s metadata, a region policy, a service, an epoch, and a wrapping algorithm, then run requests against edge servers in five cities and watch which ones can unwrap the key and which ones fail closed. The per-server notes name the check that decided it.

Three things to notice if you ran it with the defaults. First, the wrapped key itself travels everywhere. Global distribution is not the leak; unwrapping is the gated step, and the gate is the regional root key. Second, change the service from Tunnel to Gateway and watch Frankfurt fail: same region, same epoch, wrong service context, and the application-specific key does not match. The boxes are drawn per service as well as per map. Third, switch the wrapping to classical X25519 only and read the harvest panel: the same wrapped key that is safe today becomes an IOU payable to the first adversary with a quantum computer and a hard drive full of recorded traffic. Hybrid wrapping is what removes that IOU.

Also try the stale epoch. A previous-epoch key still unwraps during a soft rotation, because the old epoch stays available for a controlled transition. That is a feature with a cost: old epochs are old attack surface. A hard rotation rewraps affected keys under a replacement epoch so the previous epoch can be removed entirely. Rotation policy is where the theory meets the operations calendar, and it is worth asking a vendor which kind they run by default.

The cryptography: hybrid HPKE, stated plainly

For the Cloudflare One path, the control plane’s key management service derives an application-specific HPKE key pair, following RFC 9180. The key-encapsulation mechanism combines ML-KEM-768 with X25519. HKDF-SHA-256 provides key derivation. AES-256-GCM provides authenticated encryption.

The hybrid construction is doing specific work. Combining a post-quantum algorithm with a classical one preserves confidentiality as long as at least one component remains secure. That matters because ML-KEM is young. It is a NIST standard, FIPS 203, and it opens doors to highly sensitive customers who require standardized post-quantum algorithms. But young standards carry implementation and cryptanalysis risk, and X25519 is the battle-tested backstop. If ML-KEM breaks, X25519 still holds. If X25519 falls to a quantum computer, ML-KEM still holds. The combination is the conservative choice, and conservatism is the right posture for keys that must survive decades.

One honest caveat travels with this. Hybrid protection covers the wrapping layer described here. It does not by itself make every other part of a customer’s traffic post-quantum safe. TLS configurations, stored ciphertext elsewhere in the stack, and the customer’s own systems each have their own migration timelines. A geo-fenced, quantum-resistant key manager is one component, not a finished migration.

Rotation, and the trust boundary

The validated design supports two rotation modes. A soft rotation creates a new epoch for the regional root key while retaining controlled access to a limited number of previous epochs, one previous generation as Cloudflare’s example. New private-key material is wrapped using the latest epoch, while older wrapped keys stay usable during the transition. The analogy offered is a credit card company letting you use a previous card number for recurring payments from an authorized retailer. Service keeps running while the transition completes.

A hard rotation rewraps affected customers’ wrapped private keys under a replacement epoch so access to the previous epoch can be removed. The previous card stops working everywhere, immediately. Hard rotation is the incident-response mode: it costs operational effort and it is how you actually retire a compromised or outdated epoch.

The trust boundary is worth stating exactly, because it tells you who could break the promise. It includes the key-management service, the provisioning service, and authorized edge key services, because each can access regional root keys. Quicksilver stays outside the boundary: it receives only wrapped private keys and associated metadata. So the guarantee rests on three systems behaving, not one. That is a smaller surface than “the whole cloud,” and it is still a surface. A vendor that claims its residency guarantee has no trusted components is selling you something else.

The honest limits

A vendor describing its own cryptography program deserves a skeptical read, and there are four places to press.

First, this is a closed beta. General availability is planned for Q1 2027, and the CDN integration that would bring this new manager to the existing CDN geo-key capability is still being developed. If your use case is CDN certificates rather than Cloudflare One, what is described here is a roadmap, not a feature you can buy today. The announcement is careful about that distinction. Your procurement timeline should be too.

Second, the ABE flexibility is gone. The 2022 system could express policies as attributes across many regions without rewrapping keys. The new system uses one regional root key per region and derived application keys. Cloudflare says customers do not need a large number of regions, and for most customers that is probably true. But if your policy needs fine-grained attribute combinations, check that the simpler model expresses what you need before assuming it does.

Third, the region is an inventory list that changes several times a day. That is good engineering, since the network changes constantly, and it means “Germany” is a maintained definition, not a fixed fact. Ask how region membership changes are audited, and whether a customer is notified when the data centers in its region change. A guarantee whose scope shifts silently is weaker than one whose shifts are logged.

Fourth, the guarantee covers where keys unwrap, not where everything else happens. Cloudflare is explicit: separate workstreams determine where tunnels terminate, where traffic is inspected, how it is routed, and where plaintext processing occurs. All of them depend on the unwrapping region, because TLS traffic can only be decrypted where the key is available, but they are separate controls with their own configurations. GeoKey Manager is the key foundation of the sovereignty story, not the whole story. A residency review that stops at key unwrapping is incomplete.

The Canadian due-diligence read

If you buy, build, or oversee systems for a Canadian organization, here is how to convert this announcement into questions.

Start with the failure mode. What happens, mechanically, when a request lands where its key cannot unwrap? Walk one scenario: a Germany-bound key, a request that reaches a server in France. Does the system reject, or does it find another way? If the vendor cannot describe the reject path, the residency claim is a routing preference.

Then the root keys. Who holds them, where do they live, and what is the provisioning path? Ask whether wrapped keys and root keys travel the same distribution system. If they do, one compromise bridges the gap the whole design exists to maintain. Ask whether root keys ever touch disk, and what happens on server restart. Volatile memory with re-authentication is the pattern to look for.

Then the region definition. What exactly is inside your region, how often does that change, and how is the change audited? Under Quebec’s Law 25, organizations carry accountability for personal information they transfer and for the safeguards around it, and a region promise you cannot audit is hard to document in a privacy impact assessment. The same applies to PIPEDA’s accountability principle: you stay responsible for what your processors do, including where they decrypt.

Two more, specific to the quantum half. First, the timeline. Harvest now, decrypt later means the migration clock started when the data was first recorded, not when the quantum computer arrives. Ask vendors for their post-quantum migration dates per component, not a single corporate date. Second, the hybrid question. Is the wrapping hybrid, or single-algorithm? A single post-quantum algorithm is a bet on one standard’s youth. A hybrid is a hedge, and for keys that must survive decades, the hedge is the point.

Cloudflare deserves credit for the shape of this design: a small trust boundary, a fail-closed failure mode, volatile root keys, and a hybrid algorithm choice that refuses to bet everything on one new standard. Those are the properties to demand from any vendor making a region promise, whether or not the vendor is Cloudflare.

The open question

The announcement closes with a form where current Data Localization Suite customers can register intent to test the feature for CDN traffic before general availability. That is the right next step for a team whose threat model includes both a quantum adversary and a geographic rule. But it leaves the harder question open, and it is a question for the whole industry.

Every sovereignty promise rests on someone’s definition of a region, someone’s inventory of servers, and someone’s provisioning path. Those are operational facts, not mathematical ones, and they change several times a day. Cryptography can make the guarantee precise: this key unwraps here and nowhere else, under these checks, or not at all. What cryptography cannot do is make the definition of “here” stable, auditable, and agreed upon across vendors, regulators, and customers. The next round of this story is not a better algorithm. It is a shared language for what a region means, and an audit trail when it changes. Until that exists, the right posture is Cloudflare’s own: fail closed, document the boundary, and verify the reject path yourself.

Primary sources

1. Bringing post-quantum cryptography to geographically fenced key management (Cloudflare)
2. GeoKey Manager (Cloudflare Developers)
3. HPKE: Hybrid Public Key Encryption (RFC 9180) (IETF)
4. ML-KEM (FIPS 203) (NIST)