Cloudflare has announced the closed beta launch of its post-quantum geographically restricted key manager, a major development designed to support the company’s Data Localization Suite. Dubbed the PQ GeoKey Manager, the new offering serves as a cornerstone for Cloudflare’s evolving data sovereignty solutions, ensuring that customer decryption keys remain strictly accessible only within a chosen geographic territory. The system implements these restrictions by wrapping each decryption key in such a way that it can exclusively be unwrapped and utilized by Cloudflare servers physically located inside the allowed region.
While general availability for the product is slated for the first quarter of 2027, the closed beta release marks a critical milestone in Cloudflare’s ongoing efforts to help customers achieve their data sovereignty goals. Simultaneously, the launch advances the company’s broader roadmap to migrate all Cloudflare products to robust post-quantum cryptography.
Modern Threat Landscape: Harvest Now, Decrypt Later
Governments, financial institutions, healthcare providers, and defense organizations routinely process exceptionally sensitive data that can retain its confidentiality value for years or even decades after creation. Encryption remains the primary mechanism for protecting this information. However, when classical public-key encryption is deployed, adversaries do not necessarily require a functioning quantum computer today to compromise security. Instead, malicious actors can capture and store ciphertext now, retaining it until future quantum computers become powerful enough to break the underlying public key cryptography. This emerging threat strategy is widely known as "harvest now, decrypt later."
For enterprises bound by strict geographic regulations, defending against this long-term threat represents only half of the challenge. At Cloudflare’s global scale, maintaining high availability necessitates replicating customer data across a vast array of servers spanning the entire worldwide network. Conversely, many regulatory compliance frameworks mandate that specific data categories must be processed strictly within defined geographical borders. To reconcile these competing demands, Cloudflare must ensure that data remains end-to-end encrypted so that only servers inside the designated region possess access to the underlying plaintext.
The Evolution of GeoKey Manager
Cloudflare pioneered the concept of geo-restricted Transport Layer Security keys back in 2017 with the original release of GeoKey Manager. That initial capability granted customers administrative control over the exact physical locations where their private TLS keys could be unwrapped across Cloudflare’s anycast network, delivering stronger technical guarantees regarding the regions where their requests were decrypted. For instance, a customer could configure their system to unwrap private keys exclusively within India, ensuring that TLS signing operations for every request occurred locally on the India network rather than across the global infrastructure.
GeoKey Manager underwent a significant architectural evolution in 2022 with the introduction of ciphertext policy attribute-based encryption. Rather than tying encrypted keys to a fixed set of specific data centers, this approach expressed geographic requirements using flexible attributes such as country or regional identifiers, including parameters like "region equals European Union" or "region equals Canada plus United States plus Mexico." This innovation allowed newly authorized servers to receive matching decryption capabilities dynamically without requiring the rewrapping of every individual customer key.
However, that operational flexibility introduced new complexities in the context of the post-quantum transition. Because no production-ready post-quantum attribute-based encryption scheme is currently available, and because most enterprise customers do not require an unmanageably large number of distinct regions, a streamlined design proved more practical to maintain and operate. Consequently, Cloudflare adopted a hybrid protection model combining ML-KEM-768 and X25519 protocols utilizing two distinct tiers of keys. ML-KEM-768 is a National Institute of Standards and Technology standard that opens secure pathways for highly sensitive enterprise customers. Under this structure, a regional root key serves as a symmetric secret tied to a single geographic area, while application-specific key pairs are derived from that root for individual services such as Cloudflare Gateway or Cloudflare Tunnel. This architecture effectively shields private key material against harvest-now, decrypt-later attacks while strictly preserving regional key-use boundaries.
Global Ciphertext and Regional Key Unwrapping
In its updated architecture, GeoKey Manager acts as the foundational layer for Cloudflare’s data sovereignty solutions. It precisely dictates the regions from which protected decryption keys can be utilized and when those actions are permitted. While separate operational workflows determine where network tunnels terminate, where traffic inspection occurs, how data is routed, and where plaintext processing takes place, all of these functions ultimately rely on the region where a customer’s private key can be unwrapped. Because TLS traffic can only be decrypted wherever the corresponding key is available, the key manager exerts decisive control over data boundaries.
During the system initialization phase, the edge key service—the specific component running on each Cloudflare edge server that unwraps customer private keys to serve incoming requests—verifies that it has successfully loaded every regional root key required by its local configuration. If a configured key is missing or malformed, the edge service halts initialization and refuses to start. Once operational, individual requests fail closed if their associated metadata points to a regional root key that is not locally present. Under this fail-closed policy, Cloudflare rejects a request rather than taking any risk of unwrapping a key outside its approved region. For example, a request originating for Germany would immediately fail if processed in Spain or France, as neither nation houses the regional root key designated for Germany. This guarantees that regional root keys never leave their assigned geographic territory under any circumstances.
Maintaining high network performance while securing regionalized data at scale forms the primary objective of this new architecture. By leveraging post-quantum cryptography to restrict where customer private keys are unwrapped, Cloudflare achieves logical network separation without sacrificing speed. Most global regions will be available for customers to regionalize their workflows, subject to specific product-level caveats. Customers simply select their desired region, and Cloudflare manages the underlying mechanics required to unwrap private keys strictly within those geographic boundaries.
Architectural Design of Key Distribution
GeoKey Manager specifically controls where wrapped private keys can be unwrapped and utilized on the data plane. It does not dictate where network requests are routed, where tunnels terminate, or where traffic inspection occurs, as those functions are managed separately by Regional Services.
The system achieves security by cleanly separating globally distributed wrapped private keys from the regional root keys required to unwrap them. Quicksilver, Cloudflare’s proprietary global configuration distribution 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 are handled through a distinct provisioning service that stores them securely and delivers them exclusively to edge servers authorized for each specific region. These regional root keys follow an isolated, heavily controlled distribution path, and a node’s regional configuration ultimately determines which servers are permitted to receive specific regional root keys.
Every wrapped customer private key carries explicit metadata identifying its service context, regional boundary, and epoch. The service context defines the specific Cloudflare service utilizing the key, such as Cloudflare Access, Gateway, Tunnel, or the Cloudflare One client. The regional boundary outlines the approved set of Cloudflare data centers where the key may be unwrapped, such as facilities located within Germany or across the European Union. The epoch indicates the active generational cycle of the regional root key, as each routine key rotation generates a new epoch.
Keys sharing the exact same service context, regional boundary, and epoch rely on a common application-specific key pair. Consequently, the compromise of a specific application private key could expose matching services within that region, but it would leave other services unaffected. Similarly, compromising a regional root key could impact all application-specific keys derived from that root for the current epoch, while preserving the integrity of keys in other regions or epochs.
Provisioning Regional Root Keys and Authorizing Edge Servers
When administrators configure a region for a specific use case, Cloudflare’s key management service generates a regional root key, associates it with the appropriate regional boundary and epoch, and transmits it to the provisioning service for secure storage and distribution. This provisioning backend relies on an on-premises deployment of HashiCorp Vault.
Before an edge server is permitted to receive any regional root key, the provisioning service evaluates multiple security inputs. Cloudflare maintains a fleet inventory database that continuously updates membership records for every edge server across the global network. This asynchronous process integrates newly added servers as capacity expands and removes decommissioned hardware during routine maintenance cycles. As data centers are updated or added in regions like Germany, those infrastructure definitions propagate swiftly across the network via Quicksilver.
Furthermore, the inventory system associates a registered hardware identity with every server and physical location, supporting rigorous compliance standards such as FIPS 140-3. Trusted Platform Module-backed identities, server inventory records, and regional configurations collectively determine which region an edge server belongs to and which regional root keys it is authorized to access.
When an edge server contacts the control plane provisioning service, it presents its verified hardware identity. Upon successful validation of both hardware identity and regional membership, the provisioning service issues a cryptographic token permitting the server to retrieve exclusively the regional root keys authorized for its physical location. Authorized edge servers load these retrieved keys directly into the Linux kernel keyring rather than writing them to persistent disk storage. Because this memory storage is volatile, any machine restart clears the keys, requiring the server to re-authenticate and provision them anew upon reboot. While this approach introduces minor operational complexity, it eliminates persistent key material that could otherwise serve as a potential attack vector for adversaries.
Wrapping Private Keys and Data Plane Unwrapping
When the key management service receives customer private key material accompanied by a service context and regional boundary, it references the regional boundary to retrieve the corresponding regional root key and its latest configured epoch. It then derives an asymmetric application key pair and utilizes the public component to wrap the customer’s private key. The resulting package consists of the wrapped private key and its accompanying metadata.
Quicksilver then distributes this wrapped private key and metadata globally across Cloudflare’s network. Because the wrapped key strictly requires the specified regional root key to decrypt, global distribution does not grant edge servers outside the target region any ability to read the private key. Unwrapping remains entirely dependent upon the presence of the localized regional root key and the correct service context within authorized data centers.
Choosing the Cryptographic Design
Regional root keys are implemented as 256-bit symmetric secrets from which GeoKey Manager derives application-specific keys. For the Cloudflare One pathway, the control plane key management service generates an application-specific Hybrid Public Key Encryption key pair as defined in RFC 9180. The key-encapsulation mechanism combines ML-KEM-768 with X25519, while HKDF-SHA-256 handles key derivation and AES-256-GCM provides authenticated encryption. Blending post-quantum and classical cryptographic components ensures that confidentiality remains intact as long as at least one of the underlying algorithms remains secure.
The architecture is specifically designed to accommodate two distinct forms of key rotation: soft rotation and hard rotation. A soft rotation generates a new epoch for the regional root key while maintaining controlled access to a limited number of previous epochs during a transitional period. This allows a customer’s new private key material to be wrapped using the latest epoch while older wrapped keys remain temporarily usable, preserving continuous service uptime while customers transition. In contrast, a hard rotation immediately rewraps affected customer keys under a replacement epoch and revokes access to the previous epoch entirely.
Security and availability trade-offs heavily favor failing closed as an intentional design choice. Rather than risking the unauthorization of a customer private key outside its designated region during a failure, the system rejects requests outright if any validation check fails. At startup, each edge server loads all configured regional root keys into its Linux kernel keyring, and any missing or malformed keys prevent the service from initializing. Once running, the edge service maintains in-memory copies to prevent tampering and block cross-region unwrapping attempts.
Operating the infrastructure requires continuous synchronization. As servers join or leave the network, fleet inventory updates regional memberships multiple times per day. The provisioning layer dynamically refreshes access to regional root keys without requiring any direct customer intervention.
Future Integrations and Getting Started
Following the closed beta launch for Data Localization Suite customers, Cloudflare plans to extend the new post-quantum GeoKey Manager architecture to its existing CDN certificate capabilities, with further testing and transition details to be shared as development progresses. Current DLS customers regionalizing CDN traffic can register their intent to test the feature prior to general availability through Cloudflare’s designated sign-up channels.
