Cloudflare is introducing a post-quantum GeoKey Manager, which is part of its Data Localization Suite (DLS) and is currently in closed beta. This PQ GeoKey Manager ensures that a client's decryption keys remain accessible only within the geography the client selects.
The system achieves this by wrapping every decryption key so that only Cloudflare servers situated in the approved territory can decrypt it. While general availability is slated for Q1 2027, this launch marks a significant step toward supporting client data sovereignty goals and migrating all Cloudflare products to post-quantum (PQ) cryptography.
Sensitive data processed by governmental, financial, healthcare, and defense organizations can remain sensitive for many years. When classical public-key encryption is employed, adversaries do not need a quantum computer presently to endanger this data; they can store the ciphertext until quantum computers can break the public key cryptography protecting it—a strategy known as "harvest now, decrypt later."
For organizations with geographic mandates, countering this threat involves more than just protection. Given Cloudflare's operational scale, maintaining high availability necessitates replicating customer data across numerous servers globally. Nonetheless, many data sovereignty regulations mandate that certain data types must be processed solely within a specific geographic area.
Cloudflare previously pioneered geo-restricted transport layer security (TLS) keys with GeoKey Manager in 2017, allowing clients to control where their private TLS keys could be unwrapped across Cloudflare’s anycast network. For instance, a client could mandate key unwrapping only occur in India, ensuring TLS signing for each request happens within the India network.
In 2022, GeoKey Manager advanced using ciphertext policy attribute based encryption (ABE). This allowed geographic requirements to be defined via attributes like "region = European Union" or "region = Canada + United States + Mexico," rather than linking keys to fixed data centers.
The transition to post-quantum cryptography presented a challenge, as no production-ready PQ ABE scheme exists, and clients do not require numerous regions. Cloudflare adopted a simpler design utilizing hybrid ML-KEM-768 and X25519 protection with two key types: a regional root key (a symmetric secret tied to one region) and an application-specific key pair derived from it for a service like Gateway or Tunnel. This method defends against "harvest now, decrypt later" while maintaining regional key-use boundaries.
The new GeoKey Manager serves as the core for Cloudflare’s data sovereignty solutions, dictating where protected decryption keys can be utilized from and when. While separate workstreams handle tunnel termination, traffic inspection, and routing, all depend on the region where the customer's private key can be unwrapped, as TLS traffic can only be decrypted where that key resides.
During initialization, the edge key service on each Cloudflare edge server confirms it has loaded all necessary regional root keys according to its configuration; otherwise, the service will not start. Subsequently, an individual request fails closed—meaning Cloudflare rejects it rather than risking an out-of-region key unwrap—if its metadata indicates a regional root key not locally available. This ensures a regional root key never leaves its designated area.
This evolution enables high performance while logically segmenting the network using PQ cryptography to restrict private key unwrapping locations. Customers select a region, and Cloudflare manages the necessary steps to unwrap their private keys within that region’s boundary.
GeoKey Manager governs where wrapped private keys can be unwrapped and used on the data plane, distinct from where requests are forwarded or traffic inspection occurs (which are Regional Services). It separates globally distributed wrapped private keys from the regional root key needed for unwrapping. Quicksilver, the global configuration distribution system, spreads wrapped private keys and metadata, but regional root keys are delivered only via a separate provisioning service authorized for specific regions.
Each wrapped customer private key contains metadata specifying its service context (e.g., Tunnel or Gateway), regional boundary (approved data centers), and epoch (key generation rotation). For example, Acme Co. might have one Tunnel key in Germany (acme0001) and another Gateway key in Germany (acme0002).
Compromising the Tunnel-Germany application-specific private key could expose both acme0001 and runner0001, but not the Gateway keys. Conversely, compromising the Germany regional root key could impact every application-specific key derived from that root for the same epoch, including acme0001, acme0002, and runner0001.
The current architecture uses an asymmetric application-specific key pair: the public component wraps the customer's private key material, and the private component is needed for unwrapping. The resulting wrapped private key is distributed with its service context, region, and epoch.
When Cloudflare/Admin configures a region for a CF1 use case, the key management service generates a regional root key, associates it with a boundary and epoch, and sends it to the provisioning service, which uses our on-premises Vault for storage and distribution.
Before an edge server receives a regional root key, the provisioning service checks three factors: a Trusted Platform Module (TPM) verifies the server's registered hardware identity, Zinc maps that identity to a data center and location, and the provisioning service determines which regional root keys the server can access.
This asynchronous process manages network expansion and decommissioning. When definitions in Zinc change, such as altering which data centers constitute Germany during maintenance, Quicksilver swiftly propagates these updates across the network. Zinc also links hardware identity to physical location, supporting FIPS 140-3 compliance.
TPM-backed identity, server inventory data, and regional configurations collectively determine an edge server’s regional assignment and the regional root keys it can access. Every edge server contacts the control plane’s provisioning service, supplying its registered hardware identity for verification.
