Cloudflare announced a closed beta for post-quantum GeoKey Manager, intended to restrict protected key use to a customer-selected geography. General availability is planned for the first quarter of 2027. Cloudflare official announcement
Post-quantum cryptography addresses threats anticipated from future quantum computers. This feature focuses on where protected keys can be unwrapped and used. Cloudflare distinguishes that role from routing requests or choosing traffic-inspection locations.
On this page
Draw separate boundaries for keys and data
Encrypted data may be replicated across locations while the ability to decrypt a key is restricted to selected geography. That restriction does not, by itself, describe every network hop or log-storage location. Review ciphertext, key availability, plaintext processing, and diagnostics as separate items when mapping geographic requirements to a service design.
For example, a requirement to decrypt only in a particular region calls for identifying who unwraps a key and who can use the result. Separately map TLS termination, response inspection, and security-event storage. Match each requirement to the relevant product capability and configuration instead of treating one feature name as proof that the whole data-sovereignty requirement has been satisfied.
Post-quantum protection does not replace current access controls
Post-quantum cryptography is designed with attacks from sufficiently capable quantum computers in mind. Long-lived sensitive records can raise concerns about attackers collecting ciphertext now for possible decryption later. Addressing that cryptographic horizon is separate from reducing excessive account authority today. Key-access approval and auditing remain part of the operating design.
In a wrapped-key system, review the relationship between the protected key and the systems authorized to unwrap it. Identify who approves geographic-policy changes and what happens to existing and newly created keys after a change. Algorithm selection is one part of the review; lifecycle and policy-change behavior determine how the intended restriction is maintained over time.
Decide the recovery policy before a regional outage
Imagine a service operating in two regions but allowing key use in only one. If the permitted region fails, automatically broadening key access could conflict with the original restriction. Retaining the restriction could instead require suspending part of the service. Approve that availability-versus-location decision during design rather than improvising it during an outage.
A beta evaluation should examine policy changes, key rotation, and loss of an allowed region alongside normal requests. Ask which records can demonstrate key-use location. These are evaluation scenarios, not claims of tested beta behavior. Recheck participation conditions and the planned general-availability schedule against the official information available when making the actual deployment decision.
Separate geographic requirements
- Distinguish key storage, unwrapping, and use locations.
- Review network paths and plaintext inspection or processing separately.
- Check that regional failover remains inside the intended boundary.
Closed-beta access and future schedules may change. A planned GA date is not current availability.
Announcement reference date: 2026-10-23 · Checked: October 24, 2026
