Post-Quantum Key Wrapping Keeps Decryption Keys Inside Approved Regions

Cloudflare has put a post-quantum geographically restricted key manager into closed beta as part of its Data Localization Suite (DLS). The system, called PQ GeoKey Manager, ensures a customer's decryption keys can only be unwrapped by Cloudflare servers located in the geography the customer chose. General availability is planned for Q1 2027. What makes this more than a routing feature is the cryptography underneath it: the key material is protected against future quantum attacks while its use is confined to a region.

Why the two problems have to be solved together

Some data stays sensitive for years or decades. Financial records, health data and material held by organizations with high-security requirements all fall into this category. Classical public-key encryption protects that data today, but an adversary doesn't need a quantum computer right now to threaten it. They can record ciphertext today and wait until quantum machines can break the public-key layer. That's the harvest now, decrypt later pattern, and it's the reason post-quantum migration has moved from theory to planning.

Geography adds a second constraint. At Cloudflare's scale, high availability means replicating customer data across many servers in the global network. Many data sovereignty requirements, though, say certain data may only be processed inside a particular region. Replication and localization pull in opposite directions. The only way to reconcile them is end-to-end encryption in which only servers inside the region can ever see plaintext. The new system is Cloudflare's answer to that requirement, and it has to satisfy both the quantum threat and the locality rule at once.

Three generations of regional key control

Cloudflare first introduced geo-restricted TLS keys in 2017 with GeoKey Manager. Customers could choose where their private TLS keys could be unwrapped on the anycast network. A customer could, for example, require that unwrapping happen only in India, so TLS signing for their requests ran on the India network rather than anywhere in the global fleet.

In 2022, the system moved to ciphertext-policy attribute-based encryption (ABE). Rather than binding encrypted keys to a fixed list of data centers, ABE expressed requirements as attributes such as country or region, with policies like "region = European Union" or "region = Canada + United States + Mexico." The payoff was flexibility: newly authorized servers could receive matching decryption capabilities without every customer key being rewrapped.

That flexibility is exactly what complicates the post-quantum move. As far as the source describes, no production-ready post-quantum ABE scheme exists yet. Cloudflare also observed that customers don't need a large number of regions. That observation changed the design. Instead of waiting for a post-quantum ABE scheme, the team chose a simpler construction that meets the actual requirement and is easier to maintain and operate. My read is that this trade is the most instructive part of the design: the team picked the cryptography that exists and built the policy model around customer needs, rather than the other way around.

Global ciphertext, regional unwrapping

In its new form, GeoKey Manager is the foundation of Cloudflare's data sovereignty features. It decides which region protected decryption keys can be used from and when. Other workstreams decide where tunnels terminate, where traffic is inspected, how traffic is routed and where plaintext processing happens. All of them depend on one thing: where a customer's private key can be unwrapped, because TLS traffic can only be decrypted where that key is available.

The enforcement points are the edge key service and its startup checks. That service runs on each edge server, unwraps customer private keys and uses them to serve requests. At initialization, it confirms that every regional root key its configuration requires has been loaded. If a key is missing or malformed, the service doesn't start. After initialization, each request is checked too. If a request's metadata names a regional root key the server doesn't hold locally, the request fails. Cloudflare describes this as failing closed: it rejects the request rather than risk unwrapping a key out of region.

Here's a concrete case. A request that should decrypt in Germany but lands on a server in Spain or France fails, because neither of those locations holds Germany's regional root key. The design means a regional root key never leaves its region, regardless of how traffic is routed or what fails elsewhere.

The next version of GeoKey Manager keeps performance high while making the network logically separated by region. Most regions will be selectable for regionalized workflows, though some product-specific caveats apply. Customers pick a region, and Cloudflare handles everything else needed to unwrap their keys inside that boundary.

Key hierarchy: roots, epochs and application keys

The system separates three things that are easy to conflate. GeoKey Manager controls where wrapped private keys can be unwrapped and used on the data plane. It doesn't control request forwarding or routing, tunnel termination or traffic inspection; those belong to Regional Services. Keeping that scope narrow lets the key system do one job precisely.

Wrapped private keys are distributed globally through Quicksilver, Cloudflare's configuration distribution system. Regional root keys take a different path. They never go through Quicksilver. A separate provisioning service stores them and delivers them only to edge servers authorized for each region. On the data plane, a node's regional configuration, meaning which region the node belongs to, determines which nodes can receive which root keys.

Every wrapped customer key carries three pieces of metadata: a service context, a regional boundary and an epoch. The service context is the Cloudflare product using the key, such as Tunnel or Gateway. The regional boundary is the approved set of data centers where the key can be unwrapped, for example Germany or the European Union. The epoch identifies which generation of the regional root key the key belongs to, and each rotation starts a new epoch.

Take two hypothetical customers. Acme Co. has one key for Tunnel in Germany and another for Gateway in Germany. Road Runner Inc. has a Tunnel key in Germany and a Gateway key scoped to the European Union. Keys that share a service context, regional boundary and epoch use the same application-specific key pair. That sharing has a direct security consequence. Compromising the Tunnel-Germany application-specific private key would expose both Acme's and Road Runner's Germany Tunnel keys, but not the Gateway keys. Compromising the Germany regional root key is worse: it could affect every application-specific key derived from that root for the same epoch. The hierarchy limits blast radius, but it doesn't remove the need to protect the root.

In the current architecture, each application-specific key pair is asymmetric. The public component wraps customer private key material, and the private component is needed to unwrap it.

Provisioning regional roots and authorizing edge servers

Regional root keys are created when Cloudflare configures a region for a Cloudflare One use case. The key management service creates the root, associates it with a regional boundary and epoch, and hands it to the provisioning service. Storage and distribution run on Vault, which Cloudflare manages on premises.

Before an edge server can receive a root key, the provisioning service checks three things. First, a Trusted Platform Module (TPM) proves the server holds a registered hardware identity. Second, Zinc, Cloudflare's server inventory system, maps that identity to a data center and physical location. Third, the provisioning service decides which regional root keys that server is allowed to access.

Region membership isn't static. Zinc updates membership as servers are added or decommissioned. When Cloudflare does maintenance in German data centers, the definition of which facilities belong to Germany changes in Zinc, and Quicksilver propagates that change through the network. Capacity additions work the same way in reverse. Zinc also ties a hardware identity to a server and location, which supports FIPS 140-3 compliance goals. TPM-backed identity, inventory data and regional configuration together decide which region a server belongs to and which root keys it can hold.

The flow runs like this. Each edge server calls the control plane's provisioning service and presents its hardware identity. Once the identity and regional membership check out, the service issues a token that permits retrieval of only the root keys authorized for that location. The server uses the token to fetch its keys.

Storage on the server is deliberate too. Authorized edge servers load regional root keys into the Linux kernel keyring instead of writing them to disk. Process-level access controls restrict which services can use them. Because keyring memory is volatile, a restart clears the keys, and the server has to authenticate and provision again. That adds operational work, but it removes persistent key material, which could otherwise become an attack vector.

Wrapping and unwrapping

When the key management service receives a customer's private key with a service context and regional boundary, it looks up the regional root key and its latest configured epoch. It derives the matching asymmetric application key pair and uses the public component to wrap the private key. The output is a wrapped key plus its metadata.

Quicksilver distributes that wrapped key across the network. Global distribution doesn't give every edge server access to the plaintext key. Unwrapping still requires the correct regional root key and a matching service context.

Why this cryptographic design

Regional root keys are 256-bit symmetric secrets. GeoKey Manager derives application-specific keys from each root. On the current Cloudflare One path, the key management service derives an application-specific Hybrid Public Key Encryption (HPKE) key pair.

The Cloudflare One path uses HPKE as defined in RFC 9180. Its key encapsulation mechanism combines ML-KEM-768, a NIST-standardized post-quantum KEM, with X25519, a classical elliptic-curve key exchange. HKDF-SHA-256 handles key derivation, and AES-256-GCM provides authenticated encryption. The hybrid pairing is the point. Combining a post-quantum component with a classical one keeps confidentiality intact as long as at least one of the two remains secure. That's the right hedge while the post-quantum primitives are still new in production, and it's the reason the design doesn't rely on ML-KEM alone.

Designing for rotation

The validated design supports two kinds of rotation, and they answer different operational needs.

A soft rotation creates a new epoch for the regional root key while keeping controlled access to a limited number of earlier epochs. The source uses one previous generation as its example. Newly wrapped private key material uses the latest epoch, while older wrapped keys stay usable during the transition. Think of it like a card company that still accepts your old card number for recurring charges from a merchant you've authorized. The number of retained epochs sets how many old "cards" still work. Customers keep their service running while they move over.

A hard rotation rewraps the affected customer keys under a replacement epoch, then removes access to the previous one. That's the equivalent of the card company declining the old number for every transaction. Hard rotation is the response when you need to cut off an epoch entirely.

Failure modes and trade-offs

Failing closed is a deliberate choice. Failing open would mean unwrapping a private key outside its allowed region instead of rejecting the request. Cloudflare says it never does that. If any required check fails, whether service context, region or epoch, the request is rejected.

Once running, the edge key service works from in-memory copies of the keys, which makes tampering harder and blocks out-of-region or cross-region unwrapping. An edge server only starts serving a region after its configuration and key provisioning are complete. That means a region can have fewer serving nodes during provisioning or after a restart, and operators will feel that as a capacity question.

The trust boundary covers every service that can reach a regional root key. That includes the key management service, which derives application keys from roots; the provisioning service, which stores and distributes them; and authorized edge key services, which hold local copies. Quicksilver sits outside that boundary, since it only ever carries wrapped keys and metadata. Keeping the distribution layer outside the boundary is what allows global replication without widening exposure to plaintext-capable keys.

Keeping membership current

The list of data centers in a region such as Spain isn't fixed. Cloudflare's fleet inventory changes as servers come and go. GeoKey Manager's provisioning layer refreshes regional membership several times a day, granting or revoking root key access as the network changes. That process is separate from key rotation, and it requires no customer action.

When membership changes, the provisioning service immediately syncs the server's kernel keyring with the current set of authorized root keys. The edge key service caches keys in process memory until it restarts or the cache expires, then reloads the authorized set from the keyring.

What's next

GeoKey Manager is the basis for an improved Regional Services offering for Cloudflare One. Cloudflare says those capabilities will be announced in a few months. Separately, the older GeoKey Manager already provides geographic controls for private keys tied to CDN certificates. Cloudflare is building an integration that brings this post-quantum version to that CDN capability and will share testing and transition details when it's ready.

For current DLS customers who want to regionalize CDN traffic, Cloudflare is taking intent to test before CDN support reaches general availability, through this form. The open questions to watch are how the CDN integration handles existing certificates during transition, and how region membership changes affect long-running customers. The design makes the second question manageable in principle. Whether it holds up at production scale is what the beta will test.