Cloudflare launched a closed beta of its post-quantum GeoKey Manager on 23 October, moving the geographic key-fencing system to a hybrid cryptographic setup. Organisations using the Data Localization Suite can test the system ahead of a full public release set for the first quarter of 2027.
Key points
- Cloudflare opened a closed beta for its post-quantum GeoKey Manager on 23 October.
- The rebuild replaces attribute-based encryption with a hybrid combination of ML-KEM-768 and X25519.
- Edge servers verify location through onboard TPM chips and store decryption keys solely in volatile kernel memory.
- A strict fail-closed policy blocks traffic rather than risking key exposure if hardware or synchronisation checks fail.
Replacing attribute-based encryption
Cloudflare engineers Chetan Agrawal, Arka Nayan and Erik Engstrom described the redesign as an answer to two operational challenges: regional data sovereignty mandates and harvest-now, decrypt-later threats. In those attacks, hostile groups capture encrypted web traffic today to decipher it once sufficiently capable quantum machines exist.
Cloudflare introduced GeoKey Manager in 2017 to restrict where edge nodes could hold private TLS keys. In 2022, the company shifted the mechanism to ciphertext-policy attribute-based encryption. That architecture let administrators set complex rules to govern key access across thousands of distributed servers.
Cloudflare discarded attribute-based encryption during the post-quantum rewrite for two practical reasons. Engineers found no production-ready post-quantum variant of the scheme. Corporate customers also rarely needed the intricate policy expressions that the framework was built to support.
How the hybrid cryptography works
The revised platform implements hybrid public-key encryption under RFC 9180. The implementation combines the post-quantum ML-KEM-768 mechanism with classical X25519 elliptic-curve cryptography, using HKDF-SHA-256 for key derivation and AES-256-GCM for payload encryption.
Two tiers of cryptographic keys replace the former policy rules. Regional root keys act as 256-bit symmetric secrets, assigned one to each geographical zone. Downstream systems such as Cloudflare Tunnel and Cloudflare Gateway derive application-specific key pairs directly from those regional roots.
Every derived key pair corresponds to an epoch, Cloudflare’s designation for a key generation cycle. The central key-management service generates the application pair and wraps customer private keys using the corresponding public component.
Hardware identity and the edge perimeter
The system separates how wrapped keys and root keys travel across the network. Quicksilver, Cloudflare’s globally replicated key-value database, distributes wrapped customer keys and their metadata to every edge node. Regional root secrets never enter that database.
Regional root keys travel instead through an isolated provisioning pipeline that stores them in HashiCorp Vault. An edge server must clear three sequential validation steps before receiving any regional secret.
The provisioning system first verifies the machine’s hardware identity using an onboard Trusted Platform Module chip. It then queries Zinc, Cloudflare’s internal server catalogue, to map that hardware profile to a verified physical facility. Once the location is confirmed, the provisioning service decides whether that specific server is authorised to hold the requested regional keys.
Authorised edge machines load regional root keys directly into the operating system kernel keyring, bypassing solid-state drives and hard disks entirely. Because this memory is volatile, “a machine restart removes the keys,” forcing the server to authenticate again following any reboot.
Regional server rosters update several times a day to reflect routing changes and ongoing network maintenance. The platform carries out these adjustments automatically without client input.
Key rotation and the fail-closed choice
The epoch architecture protects uptime during routine key updates. Under a soft rotation, the platform generates a new epoch while continuing to accept keys from a set number of previous generations. This overlap allows customer services to process incoming traffic without dropping active connections.
An emergency hard rotation operates differently. The system rewraps affected keys under a replacement epoch and revokes access to the older generation immediately, shutting off compromised paths during security incidents.
The redesign prompted technical discussion among security specialists. Dabeer Shaikh, a senior solutions engineer at HashiCorp, raised questions about zero-downtime key rotation, which the epoch model addresses. Mark Tehrani, a cybersecurity professor and founder of CyberSeQ, raised five questions regarding system exposure. His points covered the potential blast radius of a leaked regional root, the risk of a compromised inventory service distributing keys outside an approved area, and the protection of keys exposed prior to rotation.
Tehrani also asked whether a breakdown in key provisioning, synchronisation or rotation could trigger a region-wide service outage. Cloudflare confirmed that the system is engineered to fail closed. If an edge node encounters a mismatched epoch, an unapproved region, an invalid service context or a missing key, it rejects the decryption request immediately and halts the relevant service. The authors described failing closed as “a very intentional design choice” to ensure geographic fences remain intact.
The update follows Cloudflare’s deployment of hybrid ML-KEM for IPsec traffic in March, alongside ongoing work on a quantum-safe certificate authority. The beta will test how well the strict fail-closed design holds up across varied regional networks before the service reaches general availability early next year.
