Today, Cloudflare is officially launching its new post-quantum geographically restricted key manager in closed beta, marking a significant expansion of its Data Localization Suite (DLS). Designed to serve as a cornerstone for modern data sovereignty solutions, the new PQ GeoKey Manager ensures that a customer’s decryption keys remain strictly accessible only within their chosen geography. The system achieves this by wrapping individual decryption keys in such a way that they can only be unlocked by Cloudflare servers physically located inside the pre-approved geographical boundary.
While general availability for the feature is targeted for the first quarter of 2027, the closed beta release represents a critical milestone in Cloudflare’s broader initiative. The company is actively working to support its enterprise customers’ rigorous data sovereignty objectives while simultaneously migrating all of its core products toward advanced post-quantum cryptography.
Governments, major financial institutions, healthcare providers, and defense organizations routinely process exceptionally sensitive data that can retain its confidentiality requirements for years or even decades after creation. Encryption is a baseline requirement to protect this sensitive information from prying eyes. However, when traditional public-key encryption is deployed, malicious actors do not necessarily need an operational quantum computer today to compromise security. Instead, adversaries can record and store encrypted ciphertext, retaining it until future quantum computers become powerful enough to break the underlying public-key cryptography—an aggressive intelligence-gathering strategy widely known as "harvest now, decrypt later."
For organizations bound by strict geographic compliance mandates, defending against this sophisticated threat vector is only half the operational challenge. At Cloudflare’s massive global scale, maintaining high availability requires replicating customer data across numerous servers distributed throughout its extensive anycast network. Conversely, many regulatory frameworks dictate that specific categories of data must be processed exclusively within designated geographical regions. Consequently, Cloudflare must guarantee that data remains end-to-end encrypted in transit, ensuring that only edge servers operating directly within the specified region hold the capability to access the plaintext.
The Evolution of GeoKey Manager
Cloudflare originally pioneered the concept of geo-restricted transport layer security (TLS) keys back in 2017 with the initial release of GeoKey Manager. That foundational tool granted customers direct control over the specific locations where their private TLS keys could be unwrapped across Cloudflare’s global network, offering stronger technical guarantees regarding where incoming requests were ultimately decrypted. For example, a customer could mandate that their private keys only be unwrapped in India, ensuring that TLS signing operations occurred exclusively within Cloudflare’s domestic network infrastructure there rather than across the entire global footprint.
The architecture evolved significantly in 2022 with the introduction of ciphertext policy attribute-based encryption (ABE). Rather than binding encrypted keys to a static, hardcoded set of data centers, ABE allowed engineers to express geographic requirements using flexible logical attributes, such as "region = European Union" or "region = Canada + United States + Mexico." This innovation meant that newly authorized servers could automatically receive matching decryption capabilities without forcing administrators to rewrap every individual customer key.
However, that flexibility also introduced both operational challenges and strategic opportunities for the ongoing transition to post-quantum cryptography. Because no production-ready post-quantum ABE scheme is currently available, and because typical enterprise customers generally do not require an unmanageable number of distinct regions, a streamlined design proved to be far more practical, secure, and maintainable. Cloudflare ultimately settled on a hybrid protection scheme utilizing ML-KEM-768 and X25519, backed by a dual-key hierarchy. ML-KEM-768 is a recognized NIST standard that provides robust security capable of satisfying the stringent demands of highly sensitive institutional clients. Within this architecture, a regional root key acts as a symmetric secret bound strictly to a single region, while application-specific key pairs are dynamically derived from it to service individual infrastructure components like Gateway or Tunnel. This sophisticated hierarchy effectively protects private-key material against harvest-now, decrypt-later threats while strictly preserving regional key-use boundaries.
Global Ciphertext, Regional Key Unwrapping
In its latest form, GeoKey Manager serves as the foundational pillar for Cloudflare’s comprehensive data sovereignty solutions. It precisely dictates which geographic regions can utilize protected decryption keys and under what exact conditions. While separate operational systems determine where networking tunnels terminate, where traffic inspection takes place, how data is routed, and where plaintext processing actually happens, all of these workflows fundamentally depend on the geographic boundaries governing where a customer’s private key can be unwrapped. Because TLS traffic can only be decrypted wherever the corresponding key is actively available, controlling the key controls the data sovereignty.
During system initialization, the edge key service—the specialized software component running on each Cloudflare edge server responsible for unwrapping customer private keys to handle requests—verifies that it has successfully loaded every regional root key mandated by its localized configuration. If a required key is missing, corrupted, or malformed, the service intentionally refuses to start. Following initialization, individual requests fail closed; Cloudflare rejects the traffic entirely rather than risking an unauthorized out-of-region key unwrap if metadata points to a regional root key that is not locally present in memory. For instance, if a request originating for Germany somehow attempted to decrypt in Spain or France, it would fail instantly because neither Spanish nor French edge nodes possess the regional root key assigned to Germany. This guarantees that regional root keys never leave their designated geographic boundaries under any circumstances.
Balancing high-performance content delivery with uncompromising data security at global scale is the core mandate of this new version of GeoKey Manager. By leveraging post-quantum cryptography to logically segment the network and restrict where private keys can be unwrapped, Cloudflare maintains exceptional processing speeds while enforcing strict regional isolation. Customers simply select their desired region, and Cloudflare manages the complex underlying mechanisms required to ensure their private keys are exclusively unwrapped within those legal and geographical boundaries.
How GeoKey Manager Ensures That Keys Are Only Available in a Region
GeoKey Manager strictly governs where wrapped private keys can be decrypted and utilized on the data plane. It does not dictate where network requests are routed or forwarded, where tunnels terminate, or where deep traffic inspection occurs, as those functions are handled separately by Regional Services.
To achieve this separation, GeoKey Manager decouples globally distributed wrapped private keys from the regional root keys required to unwrap them. Quicksilver, Cloudflare’s globally distributed configuration system, distributes wrapped private keys and their associated metadata across the entire network. However, Quicksilver does not distribute regional root keys. Instead, regional root keys follow an entirely separate, highly controlled provisioning path managed by an on-premises Vault infrastructure. On the data plane, a node’s physical and regional configuration determines precisely which regional root keys it is authorized to receive.
Every wrapped customer private key carries explicit metadata identifying its service context, approved regional boundary, and active epoch. The service context specifies the exact Cloudflare product utilizing the key, such as Cloudflare Tunnel or Gateway. The regional boundary defines the approved set of data centers where the key may be unwrapped, such as facilities located exclusively within Germany or the broader European Union. The epoch identifies the specific generation of the regional root key to which the key belongs, facilitating secure key rotations over time.
For example, a corporate client might maintain one key for Tunnel operations in Germany and an entirely separate key for Gateway services in Germany. Another enterprise might utilize a Tunnel key in Germany alongside a Gateway key spanning the entire European Union. Keys sharing the same service context, regional boundary, and epoch rely on the same application-specific key pair. Consequently, compromising a specific application-specific private key could expose related services within that exact scope, but it would leave keys in other regions or service contexts completely secure.
The regional root keys themselves are generated by the key management service whenever an administrator configures a region. These 256-bit symmetric secrets are associated with a regional boundary and epoch before being securely transmitted to the provisioning service for storage and distribution.
Before any edge server is permitted to receive a regional root key, the provisioning service evaluates multiple security inputs. Zinc, Cloudflare’s internal fleet management system, continuously updates membership records for every edge server as infrastructure scales, hardware is replaced, or data centers undergo maintenance. As physical locations are added or decommissioned, Zinc updates the precise definition of regional boundaries, rapidly propagating those changes network-wide via Quicksilver. Furthermore, Zinc links a cryptographically registered hardware identity—backed by a Trusted Platform Module (TPM) and strict FIPS 140-3 compliance standards—to each physical server and location.
Once authenticated, authorized edge servers load regional root keys directly into the Linux kernel keyring rather than persisting them insecurely on disk. Because this memory is strictly volatile, any machine reboot automatically purges the keys, requiring the server to re-authenticate and re-provision its authorized keys upon startup. This design introduces minor operational complexity in exchange for eliminating persistent key material that could otherwise serve as a potential attack vector.
When the key management service receives customer private key material alongside a designated service context and regional boundary, it queries the appropriate regional root key and current epoch. It then derives the corresponding asymmetric application key pair and uses the public component to wrap the customer’s private key. Quicksilver distributes this resulting wrapped key globally across the network. Because the wrapped key can only be decrypted by the matching regional root key, global distribution does not grant edge servers outside the approved region any ability to read the underlying private key.
Why We Chose This Cryptographic Design
Cloudflare’s cryptographic architecture relies on regional root keys consisting of 256-bit symmetric secrets, from which GeoKey Manager derives application-specific keys. For Cloudflare One workflows, the control plane’s key management service derives an application-specific Hybrid Public Key Encryption (HPKE) key pair in accordance with RFC 9180 standards.
The underlying key-encapsulation mechanism cleverly combines ML-KEM-768 with classical X25519, while HKDF-SHA-256 handles key derivation and AES-256-GCM provides authenticated encryption. By merging post-quantum and classical cryptographic components, Cloudflare ensures long-term confidentiality as long as at least one of the underlying algorithms remains secure against emerging attacks.
The architecture is explicitly designed to support seamless key rotation through two distinct methods: soft rotation and hard rotation. A soft rotation establishes a new epoch for a regional root key while maintaining controlled access to a limited number of previous generations. This allows newly wrapped customer keys to utilize the latest epoch while older wrapped keys remain temporarily functional during a transition period, preserving continuous uptime. A hard rotation, conversely, immediately rewraps affected customer keys under a new replacement epoch and revokes access to the previous epoch entirely, cutting off older keys for maximum immediate security.
Failing closed is a foundational and deliberate design principle throughout the architecture. Rather than unwrapping a key outside its authorized region when an error occurs, the system immediately rejects the request. By loading root keys directly into the volatile Linux kernel keyring at startup and restricting access through process-level controls, Cloudflare ensures that cross-region or out-of-region key unwrapping is mathematically and technically impossible.
Operating GeoKey Manager and Future Integration
Cloudflare’s global network is in a continuous state of flux. As servers are dynamically added, replaced, or retired, the fleet inventory updates regional memberships several times daily, automatically granting or revoking access to regional root keys without requiring any manual intervention from customers. When membership definitions change, the provisioning service instantly synchronizes the server’s Linux kernel keyring with the latest authorized keys, ensuring seamless operational continuity.
Building upon this robust foundation, GeoKey Manager will soon power an enhanced Regional Services offering for Cloudflare One, with official announcements expected in the coming months. Additionally, Cloudflare is actively developing a separate integration to bring this new post-quantum GeoKey Manager architecture to its legacy CDN certificate capabilities, with detailed testing and transition guidelines to be published as development concludes.
Current Data Localization Suite customers who are actively regionalizing their CDN traffic can register their intent to participate in the upcoming preview before general availability. This engineering milestone represents the culmination of an extensive, cross-functional collaboration spanning Cloudflare’s Data Localization Suite, Cloudflare One, and Cloudflare Research teams.
