Cloudflare has announced the closed beta launch of its new post-quantum geographically restricted key manager, a major architectural milestone designed to support the company’s Data Localization Suite. Dubbed the PQ GeoKey Manager, the system serves as a cornerstone for Cloudflare’s evolving data sovereignty solutions, ensuring that a customer’s decryption keys remain strictly accessible only within their chosen geographic boundaries. By wrapping each decryption key in a way that requires verification by servers physically located inside the allowed territory, Cloudflare aims to bridge the gap between global network availability and strict regional compliance.
While general availability for the service is not planned until the first quarter of 2027, the introduction of the closed beta represents a critical step forward. It allows organizations to meet rigorous data localization goals while simultaneously helping migrate Cloudflare’s infrastructure toward post-quantum cryptography.
The Growing Threat of Harvest Now, Decrypt Later
For modern institutions—including governments, financial entities, healthcare providers, and defense organizations—protecting highly sensitive information is paramount. Much of this data retains its sensitive nature for years or even decades after creation, making robust long-term encryption mandatory. However, when traditional, classical public-key cryptography is deployed, malicious actors do not necessarily need an operational quantum computer today to compromise security. Instead, adversaries can record and store encrypted traffic, retaining the ciphertexts until future quantum computing capabilities advance sufficiently to break the underlying public-key algorithms. This methodology, widely known in the cybersecurity industry as "harvest now, decrypt later," presents a persistent latent risk to long-lived secrets.
For organizations bound by strict geographic mandates, defending against this long-term threat introduces complex operational challenges. At Cloudflare’s massive global scale, maintaining high availability typically relies on replicating customer data across numerous servers distributed worldwide. Conversely, many data sovereignty regulations explicitly require that specific categories of data be processed exclusively within defined geographical regions. To comply, cloud providers must ensure that data remains end-to-end encrypted so that only servers operating inside the designated region possess the necessary capabilities to access the plaintext.
The Evolution of GeoKey Manager
Cloudflare first pioneered the concept of geo-restricted transport layer security keys back in 2017 with the original release of GeoKey Manager. That initial iteration granted customers explicit control over the specific locations where their private TLS keys could be unwrapped across Cloudflare’s anycast network, providing verifiable technical guarantees regarding where incoming requests were decrypted. For example, a customer could mandate that private keys only be unwrapped in India, ensuring TLS signing for their requests occurred exclusively within the local network infrastructure rather than across the entire global footprint.
The architecture underwent a significant evolution in 2022 with the introduction of ciphertext policy attribute-based encryption. Rather than tying encrypted keys to a fixed, hardcoded set of data centers, attribute-based encryption allowed security teams to express geographic requirements using flexible attributes, such as "region = European Union" or specific multi-country combinations. This flexibility enabled newly authorized servers to receive matching decryption capabilities dynamically without requiring the rewrapping of every individual customer key.
As cryptographic standards shifted toward the post-quantum era, Cloudflare evaluated existing attribute-based encryption frameworks and determined that no production-ready post-quantum alternatives currently exist. Furthermore, because customers typically require straightforward, distinct regional boundaries rather than complex combinations, a simplified design offers superior maintainability and operational efficiency. Consequently, the new PQ GeoKey Manager utilizes hybrid ML-KEM-768 and X25519 protection, incorporating ML-KEM-768 as a NIST-standardized algorithm designed to satisfy the security requirements of highly sensitive enterprises. The system employs two distinct tiers of keys: a regional root key, which is a symmetric secret bound exclusively to a single region, and an application-specific key pair derived from it to serve individual services like Cloudflare Gateway or Cloudflare Tunnel.
Global Ciphertext, Regional Key Unwrapping
In its latest form, the key manager functions as the foundational mechanism for Cloudflare’s broader data sovereignty framework. While separate operational workflows dictate where tunnels terminate, where traffic is inspected, how packets are routed, and where plaintext processing occurs, all of these processes ultimately depend on the geographic boundaries governing private key unwrapping. Because TLS traffic can only be decrypted wherever the corresponding private key is available, controlling key access effectively enforces regional data residency.
During system initialization, the edge key service—the software component residing on every 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 configuration. If a configured key is missing, corrupted, or malformed, the edge service halts initialization and refuses to start. Once running, the service operates on a strict fail-closed principle. If an incoming request references a regional root key that is not locally present on the server, Cloudflare rejects the request outright rather than risking an out-of-region or cross-region decryption attempt. For instance, a request destined for Germany cannot be decrypted on a server in France or Spain, as neither location possesses the regional root key tied to Germany.
To achieve this level of isolation without sacrificing network performance, the architecture logically segments Cloudflare’s network by leveraging post-quantum cryptography to restrict where private keys can be unwrapped. Customers select their desired region, and Cloudflare manages the underlying infrastructure necessary to ensure keys are unsealed exclusively within those geographic limits.
Architecture and Distribution of Regional Keys
The operational design of GeoKey Manager cleanly separates the distribution of globally cached wrapped private keys from the restricted provisioning of regional root keys. Quicksilver, Cloudflare’s global configuration distribution system, efficiently distributes wrapped private keys and associated metadata across the entire network. However, Quicksilver never handles regional root keys. Instead, a separate, highly controlled provisioning service stores regional root keys and delivers them exclusively to edge servers explicitly authorized for each specific region based on their hardware and physical location.
Every wrapped customer private key carries explicit metadata identifying its service context, regional boundary, and epoch. The service context denotes the specific Cloudflare product utilizing the key, such as Cloudflare Access, Gateway, Tunnel, or the Cloudflare One client. The regional boundary outlines the approved set of data centers permitted to unwrap the key, while the epoch tracks the generational lifecycle of the regional root key following routine key rotations.
Application-specific key pairs are derived from these regional roots. Keys sharing the same service context, regional boundary, and epoch rely on the same underlying application-specific key pair. While this design means that compromising a specific application-specific key could expose similarly situated services within that region, it strictly limits the blast radius, preventing cross-region compromise or exposure of unrelated services.
Regional root keys are provisioned through a dedicated administrative workflow. When a region is configured for a specific use case, the key management service generates a regional root key, associates it with the designated geographic boundary and epoch, and transmits it to the provisioning service, which utilizes on-premises instances of HashiCorp Vault for secure storage and distribution.
Before any edge server is permitted to receive a regional root key, the provisioning service evaluates server inventory records, hardware identities, and regional configurations managed by Zinc, Cloudflare’s internal inventory and membership system. Zinc tracks membership changes asynchronously as servers join or leave the network, adapting dynamically to routine data center maintenance and capacity expansions. Furthermore, Zinc associates each server with a registered hardware identity backed by a Trusted Platform Module to support FIPS 140-3 compliance. Once the hardware identity and regional membership are verified, the server receives a scoped token allowing it to fetch only the regional root keys authorized for its physical location.
Authorized servers load these regional root keys directly into the Linux kernel keyring rather than writing them to persistent disk storage. Because the keyring resides in volatile memory, any machine reboot automatically purges the keys, requiring the server to re-authenticate and provision them anew. This design trade-off introduces minor operational complexity in exchange for eliminating persistent key material that could otherwise serve as an attack vector for sophisticated adversaries.
Cryptographic Design Choices and Operational Management
The cryptographic foundation of the new GeoKey Manager relies on 256-bit symmetric regional root keys from which application-specific key pairs are derived. For Cloudflare One pathways, the key management service generates Hybrid Public Key Encryption key pairs conforming to RFC 9180. The underlying key-encapsulation mechanism pairs ML-KEM-768 with X25519, while HKDF-SHA-256 handles key derivation and AES-256-GCM provides authenticated encryption. This hybrid construction ensures that confidentiality remains protected as long as at least one of the classical or post-quantum components remains secure.
The system is engineered to support two distinct rotation methodologies: soft rotations and hard rotations. A soft rotation introduces a new epoch for a regional root key while maintaining backward compatibility with a limited number of previous key generations. This enables customers to maintain continuous service uptime during transitions, as newly wrapped key material uses the latest epoch while older wrapped keys remain temporarily valid for ongoing operations. Conversely, a hard rotation immediately rewraps affected customer keys under a replacement epoch and revokes access to previous generations entirely.
Operating a globally distributed edge network requires continuous adaptation as hardware enters and leaves service. The provisioning layer refreshes server membership rosters multiple times daily, automatically granting or revoking access to regional root keys as network topologies shift, all without requiring direct customer intervention. When membership updates occur, the provisioning service synchronizes the Linux kernel keyring on affected edge nodes almost instantly.
Following the initial closed beta launch for Data Localization Suite customers regionalizing CDN and Cloudflare One traffic, Cloudflare plans to extend the architecture to its broader CDN certificate offerings ahead of general availability. Current DLS customers interested in evaluating the technology prior to its broader rollout can register their intent through Cloudflare’s early access channels.
