Geographic key pinning meets post-quantum protection
Cloudflare has launched, in closed beta, a post-quantum geographically restricted key manager supporting its Data Localization Suite (DLS). The PQ GeoKey Manager wraps each customer decryption key so that only Cloudflare servers inside the permitted geography can decrypt it. General availability is planned for Q1 2027; the beta is a step toward both data sovereignty and the migration of all Cloudflare products to post-quantum (PQ) cryptography.
The threat model spans more than the quantum transition. Organizations in government, finance, healthcare and defense hold data that stays sensitive for years or decades, and classical public-key encryption exposes it to "harvest now, decrypt later": adversaries can store ciphertext until a quantum computer can break the public-key protection. Geographic rules add a second constraint. Serving data at Cloudflare's scale means replicating it across many servers worldwide, while many sovereignty regulations require certain data to be processed only in a given region, so the data must be end-to-end encrypted such that only in-region servers ever see the plaintext.
From attribute-based encryption to a simpler hierarchy
Cloudflare introduced geo-restricted TLS keys in 2017 with GeoKey Manager, letting customers choose where their private TLS keys may be unwrapped on the anycast network — for example, requiring that TLS signing for each request happen only in the India network. A 2022 revision replaced fixed data-center sets with ciphertext policy attribute-based encryption (ABE), expressing requirements as attributes such as "region = European Union" or "region = Canada + United States + Mexico," so newly authorized servers could gain matching decryption capability without rewrapping every customer key.
The PQ transition removed ABE's rationale: no production-ready post-quantum ABE scheme exists today, and customers do not need a large number of regions, so a simpler design is easier to maintain and operate.
The new design applies hybrid ML-KEM-768 and X25519 protection with two kinds of keys. A regional root key is a symmetric secret tied to one region; an application-specific key pair is derived from it for a single service such as Gateway or Tunnel. ML-KEM-768, a NIST standard, also keeps the door open to highly sensitive customers. The result protects private-key material against harvest now, decrypt later while preserving regional key-use boundaries.
What the key manager does — and does not — control
GeoKey Manager governs where wrapped private keys can be unwrapped and used on the data plane. Routing and forwarding of requests, tunnel termination and traffic inspection are handled elsewhere — by Regional Services — but all of those workstreams depend on the unwrapping region, because TLS traffic can only be decrypted where the key is available.
The system separates globally distributed wrapped private keys from the regional root key needed to unwrap them. Quicksilver, Cloudflare's global configuration distribution system, spreads wrapped keys and their metadata across the network but never distributes regional root keys. Those travel a separate, controlled path: a dedicated provisioning service stores them and delivers them only to edge servers authorized for each region, and a node's regional configuration determines which nodes may receive which root keys.
Key metadata and the two-level hierarchy
Every wrapped customer private key carries metadata identifying its service context (the Cloudflare service that uses it, such as Tunnel or Gateway), its regional boundary (the approved set of data centers, such as Germany or the European Union), and its epoch — the generation of the regional root key, incremented on each rotation. One customer might hold a Tunnel key for Germany (acme0001) and a Gateway key for Germany (acme0002); another might hold a Tunnel key for Germany (runner0001) and a Gateway key for the European Union (runner0002).
Keys sharing service context, regional boundary and epoch use the same application-specific key pair. Compromising the Tunnel-Germany application-specific private key could therefore expose both acme0001 and runner0001, but not the Gateway keys; compromising the Germany regional root key could affect every application-specific key derived from that root for the same epoch, including acme0001, acme0002 and runner0001. The application-specific pair is asymmetric: the public component wraps the customer's private key material and the private component unwraps it, and the wrapped key is distributed together with its service context (Access, Gateway, Tunnel, Cloudflare One client), region and epoch.
Provisioning and authorization of edge servers
When Cloudflare/Admin configures a region for a Cloudflare One use case, the key management service — which also derives application-specific key pairs and wraps customer private keys — creates a regional root key, associates it with a regional boundary and epoch, and hands it to the provisioning service for storage and distribution. Under the hood that service uses self-managed, on-premises Vault.
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;
- the provisioning service determines which regional root keys the server may access.
Zinc updates membership records asynchronously, adding servers as the network grows and removing them at decommissioning. When maintenance changes which data centers count as Germany — or new capacity is added to a region — the definition changes in Zinc and propagates quickly through Quicksilver. Zinc's binding of a hardware identity to a physical location also supports FIPS 140-3 compliance.
Each edge server calls the control plane's provisioning service with its registered hardware identity. Once identity and regional membership are verified, the service issues a token permitting retrieval of only the regional root keys authorized for that location, and the server fetches them. Authorized servers load the root keys into the kernel keyring rather than persisting them on disk, with process-level access controls limiting which services may use them. Because this memory is volatile, a restart clears the keys and the server must authenticate and provision them again — added operational complexity that reduces persistent key material available to an attacker.
Wrapping, distributing and unwrapping
When the key management service receives a customer's private key material along with a service context and regional boundary, it looks up the regional root key and its latest configured epoch, derives the corresponding asymmetric application key pair, and wraps the private key with its public component. The output is a wrapped private key plus metadata.
Quicksilver then distributes the wrapped key and metadata across the network. Because the wrapped key requires its specified region to decrypt — unwrapping demands the matching regional root key and service context — global distribution does not grant edge servers global access to the private key.
Fail-closed behavior backs the whole scheme. At initialization, the edge key service — the component on each edge server that unwraps customer private keys and uses them to serve requests — verifies that it has loaded every regional root key required by its configuration and refuses to start if a configured key is missing or malformed. At runtime, a request whose metadata names a regional root key not locally available also fails closed: a request for Germany cannot be decrypted in Spain or France, since neither holds the Germany root key. A regional root key never leaves its region.
Most Cloudflare regions will be available for customers to regionalize their workflows, subject to product-specific caveats. Customers select a region and Cloudflare handles the rest of unwrapping their private keys within the region's boundary.
Cryptographic foundations
Each regional root key is a 256-bit symmetric secret. GeoKey Manager derives application-specific keys from that root. On the Cloudflare One path, the control plane's key management service uses the root to derive an application-specific Hybrid Public Key Encryption (HPKE) key pair.
Primitives in the Cloudflare One path
- HPKE, as specified in RFC 9180.
- KEM: ML-KEM-768 combined with X25519.
- Key derivation: HKDF-SHA-256.
- Authenticated encryption: AES-256-GCM.
Pairing a post-quantum KEM with a classical one means confidentiality holds as long as at least one of the two components remains unbroken.
Two modes of key rotation
The validated design distinguishes between soft and hard rotation.
A soft rotation opens a new epoch for the regional root key while keeping controlled access to a limited number of earlier epochs — one previous generation, for instance. New private-key material is wrapped under the latest epoch, but previously wrapped private keys stay usable through the transition. The analogy is a card issuer that still honors an old card for recurring payments from an authorized merchant: the number of epochs supported sets how many generations of wrapped keys remain valid. The goal is to protect uptime while customers migrate.
A hard rotation rewraps affected customers' private keys under a replacement epoch, after which access to the previous epoch can be withdrawn entirely — comparable to a card issuer refusing the old card outright.
Failing closed, and where the trust boundary sits
Rejecting the request is deliberate: whenever a required check fails — service context, region, epoch, and so on — the request is denied. The system never fails open by unwrapping a private key outside its permitted region.
On startup, each edge's key service loads all configured regional root keys from the Linux kernel keyring; if a root key is missing or malformed, the edge key service will not initialize. After startup it works from in-memory copies, which cannot be tampered with, blocking out-of-region and cross-region unwrapping. An edge server begins serving a region's requests only once configuration and key provisioning are complete.
The trust boundary — every service able to reach a regional root key — comprises:
- the key-management service, which derives application-specific keys;
- the provisioning service, which stores and distributes the root keys;
- authorized edge key services, which hold locally authorized copies.
Quicksilver stays outside this boundary: it only ever receives wrapped private keys and associated metadata.
Living with a changing fleet
Regional membership is not fixed. As servers join or leave service, fleet inventory updates which data centers belong to a region — Spain, for example — and the provisioning layer refreshes that membership several times a day, granting or removing access to regional root keys. This runs independently of key rotation and needs nothing from customers.
When membership changes, the provisioning service immediately syncs the server's Linux kernel keyring with the currently authorized regional root keys. The edge key service keeps a copy in process memory until it restarts or the cache expires, then reloads the authorized set from the kernel keyring.
Roadmap
GeoKey Manager underpins an improved Regional Services offering for Cloudflare One, with new capabilities to be announced in a few months.
Earlier GeoKey Manager versions already apply geographic controls to private keys for CDN certificates. A separate integration is in development to bring this post-quantum GeoKey Manager to that existing CDN capability; testing and transition details will follow when the work is ready.
Trying it
DLS customers who regionalize CDN traffic can register intent to test the feature before it is generally available for CDN traffic via the linked form.
The result reflects a large joint effort across the Data Localization Suite, Cloudflare One, and Cloudflare Research teams.
