Cloudflare post-quantum Geo Key Manager enters beta: ML-KEM-768 + X25519

Cloudflare has put a post-quantum version of its Geo Key Manager into closed beta. The service decides in which countries or regions a customer's private keys can be unwrapped and used, and the new version protects those keys with a hybrid of ML-KEM-768 and X25519 so that stolen ciphertext cannot simply be stored and cracked later by a quantum computer. General availability is planned for Q1 2027, according to Cloudflare. For anyone who has to keep data inside a legal border, it is a useful look at how that promise is enforced in code.

Key points

• Cloudflare announced on 23 October 2026 a closed beta of a post-quantum Geo Key Manager (GeoKey Manager) for its Data Localization Suite (DLS); general availability is planned for Q1 2027.
• Customer private keys are wrapped with hybrid HPKE using ML-KEM-768 plus X25519, so they stay protected if either algorithm later fails.
• A regional root key never leaves its region: servers that lack it cannot unwrap a key, and requests that name a missing key are rejected ("fail closed").
• Current DLS customers who regionalise CDN traffic can register to test the feature before general availability; Cloudflare One support is to be announced in a few months.

What to do

This is a product announcement, not a vulnerability or an update you must install. If you are a Cloudflare DLS customer who regionalises CDN traffic, Cloudflare says you can register your intent to test the new feature through the link in its post. If you use GeoKey Manager for Cloudflare One (Gateway, Tunnel, Access), Cloudflare says an improved Regional Services offering built on it will be announced in a few months. Nothing changes for you today. If you hold data that must stay in one jurisdiction for years, the practical question for your next vendor review is whether the keys protecting that data are wrapped with a post-quantum algorithm, not just a classical one.

What happened

On 23 October 2026 Cloudflare published "Bringing post-quantum cryptography to geographically fenced key management." It says the service is "a cornerstone" of its data sovereignty offering and works by "wrapping each decryption key" so that only Cloudflare servers in the allowed geography can unwrap it.

The problem it solves is a tension. To stay available, Cloudflare replicates data and configuration across servers worldwide. But many data-sovereignty rules require that certain data is processed only in a given region. The answer is to distribute encrypted material everywhere and give the ability to decrypt it only to servers in the permitted place.

Background

Cloudflare first shipped geo-restricted TLS keys in 2017, letting a customer choose, for example, that private keys could be unwrapped only in India, so that TLS signing for requests happens in that country's network. In 2022 the system moved to ciphertext-policy attribute-based encryption (ABE), expressing rules as attributes such as "region = European Union" so that new servers could receive access without rewrapping every key.

That design hit a wall with post-quantum cryptography. Cloudflare says no production-ready post-quantum ABE scheme exists today, and that customers do not need many regions, so a simpler design is enough and easier to run.

The threat model is "harvest now, decrypt later": an adversary records encrypted data or wrapped keys today and waits for a quantum computer able to break public-key algorithms. ML-KEM, the key-encapsulation mechanism chosen here, was standardised by NIST as FIPS 203, published on 13 August 2024. NIST's page also carries a note dated 17 November 2025 that an issue was identified and will be corrected in a future revision; we have not seen the details.

How it works

Cloudflare describes a key hierarchy with three parts.

Regional root keys. Each region has a 256-bit symmetric secret, tied to an epoch, a generation number that increases each time the root key is rotated. From a root key, the control plane derives an application-specific key pair for one service context, such as Gateway or Tunnel.

Wrapping. The public half of the application-specific pair wraps the customer's private key. For the Cloudflare One path this uses Hybrid Public Key Encryption (HPKE, RFC 9180) whose key-encapsulation step combines ML-KEM-768 with X25519, with HKDF-SHA-256 for key derivation and AES-256-GCM for encryption. Combining the post-quantum and classical parts means confidentiality holds as long as at least one of them stays secure.

Distribution. Wrapped keys and metadata (service context, region, epoch) travel across the whole network through Quicksilver, Cloudflare's configuration system. The regional root keys do not; they follow a separate path through a provisioning service backed by Vault.

Before an edge server can fetch a regional root key, the provisioning service checks three things: a TPM proves the server has a registered hardware identity, Cloudflare's inventory system (Zinc) maps that identity to a data centre and location, and the service decides which regional keys that location may have. Authorised servers load the keys into the Linux kernel keyring instead of writing them to disk, so a restart removes them and the server must authenticate again.

Failure handling is deliberately strict. If a configured root key is missing or malformed, the edge key service does not start. If a request names a root key the server does not hold, it is rejected. Cloudflare's example: a request for Germany that somehow lands in Spain or France fails, because neither holds Germany's root key.

Rotation comes in two kinds. A soft rotation creates a new epoch and keeps access to a limited number of older ones, so existing wrapped keys keep working during the transition. A hard rotation rewraps affected keys under the new epoch so the old one can be removed entirely.

Region membership is not static. Cloudflare says the provisioning layer refreshes membership several times a day as servers enter or leave service, adding or removing root-key access without customer action.

What it means

Who benefits. Governments, financial institutions, healthcare providers and defence organisations that Cloudflare names as customers hold data that stays sensitive for years. For them, a post-quantum wrap on the keys is a stated requirement rather than an extra.

The honest limits. Cloudflare is explicit about scope. GeoKey Manager controls where wrapped private keys can be unwrapped. It does not control where requests are forwarded or routed, where tunnels terminate or where traffic is inspected; those belong to Regional Services and other workstreams. A customer buying "data stays in Germany" still needs those other pieces.

The trust boundary. The key-management service, the provisioning service and the authorised edge key services can all reach regional root keys; Quicksilver cannot. Cloudflare notes a consequence: compromising a regional root key could affect every application-specific key derived from it for that epoch, and compromising one application-specific private key could expose all customer keys wrapped under it for that service and region. Its Acme and Road Runner example makes the same point. That is a smaller blast radius than a global key, but not zero.

What we don't know yet

• Pricing and exact regions. Cloudflare says most regions will be available and that there may be product-specific caveats; it does not list them.
• Performance. The post says the design keeps performance high but gives no latency numbers.
• Independent review. Cloudflare says its design was validated internally; we found no outside audit.
• Cloudflare One and CDN timing. The CDN integration is "being developed" with no date; Cloudflare One capabilities are due in "a few months".

What to watch next

Watch for the Q1 2027 general availability date, the Cloudflare One Regional Services announcement, and details of the CDN integration. Also watch whether competitors offering regional key control publish equivalent hybrid designs, and for the corrected FIPS 203 revision NIST has flagged.

Sources

• Cloudflare: Bringing post-quantum cryptography to geographically fenced key management (primary source)
• NIST: FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard
• IETF: RFC 9180, Hybrid Public Key Encryption