Cloudflare announced the closed beta launch of a post-quantum geographically restricted key manager as part of its Data Localization Suite (DLS). The PQ GeoKey Manager enforces data sovereignty by restricting access to customer decryption keys to servers located in approved geographic regions. General availability is targeted for Q1 2027.
The system addresses two distinct security challenges. Sensitive data held by governments, financial institutions, healthcare providers, and defense organizations can remain valuable to attackers for years or decades. Adversaries employing harvest-now-decrypt-later tactics can intercept encrypted traffic today and retain it until quantum computers become capable of breaking classical public-key cryptography. For organizations with geographic compliance requirements, the challenge multiplies: high availability demands data replication across global networks, yet regulations often mandate that certain data types be processed only within specific regions.
Evolution of geographic key management
Cloudflare introduced the original GeoKey Manager concept in 2017, giving customers control over which locations on Cloudflare's anycast network could unwrap their private TLS keys. A customer could restrict key unwrapping to a single country, such as India, ensuring TLS signing occurred only within that region's infrastructure.
The system evolved in 2022 with ciphertext policy attribute-based encryption (ABE), which expressed geographic boundaries using attributes rather than fixed data center lists. Policies could specify regions like "European Union" or "Canada + United States + Mexico," allowing newly authorized servers to gain decryption capabilities without requiring every customer key to be rewrapped.
The post-quantum transition prompted a design simplification. No production-ready post-quantum ABE scheme exists today, and customer requirements do not demand extensive regional configurations. Cloudflare adopted hybrid ML-KEM-768 and X25519 protection using two key types: a regional root key (a symmetric secret tied to one region) and application-specific key pairs derived from it for individual services such as Gateway or Tunnel. This approach protects against harvest-now-decrypt-later attacks while maintaining regional key-use boundaries.
Global distribution with regional unwrapping
GeoKey Manager now serves as the foundation for Cloudflare's data sovereignty solutions by controlling which regions can access protected decryption keys. While separate systems determine where tunnels terminate, where traffic is inspected, and how it is routed, all depend on the region where a customer's private key can be unwrapped, since TLS traffic decryption requires that key's availability.
The edge key service on each Cloudflare server verifies during initialization that it has loaded every required regional root key. If a configured key is missing or malformed, the service fails to start. During operation, requests fail closed—Cloudflare rejects them rather than risk unwrapping keys outside their authorized region. A request for Germany decryption would fail if routed to Spain or France, since those regions lack Germany's regional root key. This guarantee ensures regional root keys never leave their designated region.
Cloudflare maintains high performance while securing regionalized data at scale by using post-quantum cryptography to restrict where customer private keys are unwrapped. Most regions will be available for customers to regionalize workflows, though product-specific limitations may apply. Customers select a region and Cloudflare manages the infrastructure needed to unwrap private keys within that region's boundary.
Key hierarchy and application-specific keys
Each wrapped customer private key carries metadata identifying its service context, regional boundary, and epoch. The service context indicates which Cloudflare service uses the key—Tunnel or Gateway, for example. The regional boundary specifies the approved set of data centers where the key may be unwrapped, such as facilities in Germany or the European Union. The epoch identifies which generation of the regional root key the key belongs to; each rotation creates a new epoch.
Keys sharing the same service context, regional boundary, and epoch use the same application-specific key pair. Compromising a Tunnel-Germany application-specific private key could expose all Tunnel keys for that region but not Gateway keys. Compromising a regional root key could affect every application-specific key derived from it for the same epoch.
In the current architecture, the application-specific key pair is asymmetric. The public component wraps the customer's private key material, while the private component unwraps it. The resulting wrapped private key is distributed with its service context, region, and epoch.
Provisioning and authorization
When Cloudflare configures a region for a use case, the key management service creates a regional root key, associates it with a regional boundary and epoch, and sends it to the provisioning service for storage and distribution. The provisioning service uses Vault, managed on-premises by Cloudflare.
Before an edge server can receive a regional root key, the provisioning service evaluates three inputs: a Trusted Platform Module (TPM) proves the server possesses a registered hardware identity; Zinc, Cloudflare's server inventory system, maps that identity to a data center and location; and the provisioning service determines which regional root keys the server may access.
Zinc maintains membership records for each edge server through an asynchronous process that adds new servers as the network expands and removes decommissioned ones. When Cloudflare performs data center maintenance in Germany, the definition of which facilities belong to that region updates in Zinc and propagates rapidly through the network via Quicksilver. The same process applies when capacity is added: regional definitions update in Zinc and propagate network-wide. Zinc also associates registered hardware identities with server locations, supporting FIPS 140-3 compliance.
Each edge server contacts the control plane's provisioning service with its registered hardware identity. After verifying the server's identity and regional membership, the provisioning service issues a token permitting retrieval of only the regional root keys authorized for that location. Authorized edge servers load regional root keys into the kernel keyring rather than persisting them on disk. Process-level access controls limit which services can use them. Because this memory is volatile, a machine restart removes the keys and requires the server to authenticate and provision them again, reducing persistent key material that could serve as an attack vector.
Wrapping and unwrapping keys
When the key-management service receives a customer's private key material with a service context and regional boundary, it retrieves the regional root key and its latest configured epoch. It then derives the corresponding asymmetric application key pair and uses its public component to wrap the private key, producing a wrapped private key and its metadata.
Quicksilver distributes the wrapped private key and metadata across the network. Since the wrapped key requires the specified region to decrypt, global distribution does not grant edge servers global access to the private key because unwrapping still requires the corresponding regional root key and service context.
Cryptographic design rationale
Symmetric roots with asymmetric wrapping
Regional root keys are 256-bit symmetric secrets. GeoKey Manager derives application-specific keys from each regional root key. For the Cloudflare One path, the control plane's key management service derives an application-specific Hybrid Public Key Encryption (HPKE) key pair.
HPKE with hybrid post-quantum KEM
The Cloudflare One path uses HPKE as defined in RFC 9180. Its key-encapsulation mechanism combines ML-KEM-768 with X25519, while HKDF-SHA-256 provides key derivation and AES-256-GCM provides authenticated encryption. Combining post-quantum and classical components preserves confidentiality as long as at least one component remains secure.
Key rotation design
The design supports two rotation types. Soft rotation creates a new epoch for the regional root key while retaining controlled access to a limited number of previous epochs. Customer new private-key material wraps using the latest epoch, while older wrapped private keys remain usable during transition. This resembles a credit card company allowing previous card versions for recurring payments from authorized retailers. Hard rotation instead rewraps affected customers' wrapped private keys under a replacement epoch, removing access to the previous epoch entirely.
Security and availability tradeoffs
Failing closed is an intentional design choice. Failing open would mean unwrapping a customer's private key outside its allowed region rather than rejecting the request. Cloudflare never does that: if any required check fails—service context, region, epoch, or others—the request is rejected. At startup, each edge's key service loads every configured regional root key from its Linux kernel keyring. Missing or malformed root keys prevent initialization. Once running, the edge key service uses in-memory copies to prevent tampering and out-of-region or cross-region unwrapping. In practice, an edge server serves requests for a region only once its configuration and key provisioning are complete.
The trust boundary includes the key-management service, the provisioning service, and authorized edge key services, as each can access regional root keys. The key-management service uses them to derive application-specific keys, the provisioning service stores and distributes them, and edge key services use locally authorized copies. Quicksilver remains outside this boundary because it receives only wrapped private keys and associated metadata.
Operating GeoKey Manager
Cloudflare's network constantly changes as servers enter or leave service, requiring fleet inventory updates to regional membership. The list of data centers comprising a region like Spain is not static. GeoKey Manager's provisioning layer refreshes membership several times daily, granting or removing access to regional root keys as the network changes. This process is separate from key rotation and requires no customer action.
When regional membership changes, the provisioning service immediately synchronizes each server's Linux kernel keyring with the latest authorized regional root keys. The edge key service caches these keys in process memory until it restarts or the cache expires, then reloads the current authorized set from the kernel keyring.
Future integration plans
GeoKey Manager will form the basis for an improved Regional Services offering for Cloudflare One, with new capabilities to be announced in a few months.
Older GeoKey Manager versions already provide geographic controls for private keys associated with CDN certificates. Cloudflare is developing a separate integration to bring the new post-quantum GeoKey Manager to that existing CDN capability. Testing and transition details will be shared when that work is ready.
Current DLS customers who are regionalizing CDN traffic can register intent to test this feature before general availability for CDN traffic.