Cloudflare has moved a post-quantum rebuild of GeoKey Manager into closed beta, adding a new key-protection design for customers who need geographically fenced decryption keys. The update replaces the service’s attribute-based encryption model with a hybrid of ML-KEM-768 and X25519, and Cloudflare says general availability is planned for the first quarter of 2027.
Cloudflare’s GeoKey Manager gets a post-quantum redesign
The beta opened on October 23 and is limited to existing Data Localization Suite customers. According to Cloudflare engineers Chetan Agrawal, Arka Nayan and Erik Engstrom, the redesign is meant to solve two problems at once: keeping plaintext processing inside a required region and reducing exposure to harvest-now, decrypt-later attacks.
GeoKey Manager itself is not new. Cloudflare first shipped it in 2017 for TLS keys, then moved to ciphertext-policy attribute-based encryption in 2022. The company now says that approach no longer fits the post-quantum roadmap, both because there is no production-ready post-quantum equivalent and because customers do not need the large number of regions that the older scheme was designed to describe.
What changed under the hood
In the closed beta, Cloudflare uses HPKE, the hybrid public-key encryption construction defined in RFC 9180. The key encapsulation mechanism combines ML-KEM-768 and X25519, alongside HKDF-SHA-256 and AES-256-GCM. Cloudflare says this lets it protect customer keys while moving away from the attribute-based policy model used before.
Two kinds of keys replace policy expressions
The new design introduces two key types:
- Regional root keys: 256-bit symmetric secrets, one per region.
- Application-specific key pairs: derived from a root for a single service, such as Tunnel or Gateway, and a single epoch, Cloudflare’s term for a key generation advanced by rotation.
The key-management service derives the application key pair and wraps customer private keys under the public component. Cloudflare frames this as a way to enforce region boundaries without relying on attribute-based encryption policy expressions.
How the regional key flow works
Cloudflare splits the movement of keys into two paths. Quicksilver, its globally replicated key-value store, carries wrapped keys and metadata everywhere. Regional root keys take a separate path through the provisioning service, which stores them in Vault.
Before an edge server can receive a root key, it has to clear three checks: TPM hardware identity verification, a lookup in Zinc, Cloudflare’s server inventory system that maps identity to a data center and location, and a provisioning-service decision about which roots that server may hold.
Authorized servers then load regional root keys into the kernel keyring rather than writing them to disk. Because the memory is volatile, a machine restart removes the keys and forces the server to authenticate again. Cloudflare also says regional membership refreshes several times a day as the network changes, independently of key rotation and without customer action.
Rotation without downtime, and what happens on failure
The announcement drew questions about how geo-fenced keys can be rotated without downtime. Cloudflare’s answer is its epoch model. A soft rotation creates a new epoch while a limited number of previous epochs remain usable, so service can continue during the transition. A hard rotation rewraps affected keys under a replacement epoch and removes access to the previous one.
That model also makes the service’s failure behavior explicit. If a check on service context, region or epoch fails, the request is rejected. At the edge, a missing or malformed key prevents the service from starting. Cloudflare describes failing closed as “a very intentional design choice.”
Why the fail-closed approach matters
That design limits the trust boundary to the key-management, provisioning and authorized edge key services. Quicksilver sits outside it because it only stores wrapped keys and metadata, not the root secrets themselves.
The same approach also raises the stakes for operational issues. If regional key provisioning, synchronization or rotation fails, the design could trigger a region-wide service outage. Cloudflare appears willing to accept that tradeoff in exchange for stronger control over where plaintext can exist.
Questions from the security community
The announcement prompted scrutiny from security practitioners. Dabeer Shaikh, a senior solutions engineer at HashiCorp, asked how geo-fenced keys can be rotated without downtime. Mark Tehrani, founder of CyberSeQ and a professor of cybersecurity, raised questions about the blast radius of a compromised regional root key, whether compromised infrastructure could hand keys to an out-of-region server, what protects keys exposed before rotation, and whether a compromised control plane could alter regional membership.
Those questions point to the key tradeoff in the design: Cloudflare is prioritizing geographic control and post-quantum resistance, but the system depends on multiple checks staying correct and available.
Part of Cloudflare’s broader post-quantum push
The GeoKey Manager beta fits into a wider pattern in Cloudflare’s post-quantum work. The company adopted hybrid ML-KEM for its IPsec service in March, when more than 60% of human-generated TLS traffic on its network already used it, and it has also laid out plans for a quantum-safe certificate authority.
Most regions will be covered at launch, though Cloudflare says product-specific caveats still apply. The closed beta will likely test not just the cryptography, but whether customers accept a system that is designed to refuse service rather than bend policy when a check fails.
Source: Original report
Was this helpful?
Explore more: Application Audit & Review More Cloud & DevOps Tech News
Last Modified: November 1, 2026 at 10:32 pm
2 views
