Cloudflare’s Post-Quantum GeoKey Manager Swaps Attribute Policies for a Catalog of Regional Root Keys, and CDN Keys Wait for a Separate Integration

On Friday, October 23, Cloudflare launched a post-quantum GeoKey Manager in closed beta, with general availability planned for the first quarter of 2027. The post, by Chetan Agrawal, Arka Nayan and Erik Engstrom, says the service is “making sure that a customer’s decryption keys are only accessible in their chosen geography,” and that it does so by wrapping each key so that only Cloudflare servers in the allowed geography can unwrap it.

I read it against Cloudflare’s January 2023 account of the design it replaces, the Geo Key Manager documentation as it stands today, the IANA registry for the HPKE key encapsulation methods, and the current X-Wing draft. Then I built a small model of the key hierarchy and ran the post’s own example through it. Four things came out of that.

• The design trades flexible policies for a catalog of regional root keys. The post says why, and Cloudflare’s own documentation shows what is given up: its current API documentation includes an example titled “Store private keys in the E.U., but not in France.”
• The key-management service sits inside the trust boundary, because it derives the key pairs from the regional roots. In 2023 Cloudflare listed it as an advantage that wrapping a customer key needed no secret key material.
• Each wrapped key grows by 1,088 bytes compared with an X25519 wrap, and every node that holds the key pays that cost.
• The first keys covered are the Cloudflare One ones. The CDN keys wait for “a separate integration,” with no date.

What the post describes

The hierarchy has three levels. A regional root key is “a symmetric secret tied to one region,” and the post says these are 256-bit values. From a root, the key-management service derives “an application-specific key pair” for one service context (the post names Access, Gateway, Tunnel and the Cloudflare One client), one regional boundary and one epoch, which is the generation of the root. The public half wraps the customer’s private key. Quicksilver, Cloudflare’s global configuration distribution system, then carries the wrapped key and its metadata across the network. Because unwrapping still needs the matching root and service context, the post says, that global distribution “does not grant edge servers global access to the private key.”

The cryptography is HPKE (RFC 9180) with a hybrid key encapsulation method that “combines ML-KEM-768 with X25519,” plus HKDF with SHA-256 and AES-256-GCM. The motivation is harvest now, decrypt later: the wrapped keys are copied to every server, so someone who records them today could try to open them once a large enough quantum computer exists.

A server gets a root only after the provisioning service looks at three inputs: a TPM-backed hardware identity, Zinc (Cloudflare’s server inventory system), which maps that identity to a data center and location, and the provisioning policy for “which regional root keys the server may access.” The root then lives in the Linux kernel keyring and in the edge key service’s memory, not on disk. Failure is meant to be closed: “if any required check fails (service context, region, epoch, etc.), the request is rejected,” and an edge key service whose configured root is missing or malformed does not start.

Rotation comes in two kinds. A soft rotation creates a new epoch while “retaining controlled access to a limited number of previous regional root-key epochs,” and the post offers “one previous generation, as an example.” A hard rotation “rewraps affected customers’ wrapped private keys under a replacement epoch so access to the previous epoch can be removed.”

From policies to a catalog of roots

Cloudflare’s earlier Geo Key Manager was built for policies. In January 2023 Tanya Verma explained that version 1, “launched as a research project in 2017,” had its regions and data centers “baked into the system” at setup, and that version 2 moved to ciphertext-policy attribute-based encryption so a customer could write policies such as “country: JP or (not region: EU).” The same post had rejected the simpler idea of one key pair per policy. Giving each data center keys for “country: US,” “country: US or region: EU,” “not country: RU” and so on was “rather unwieldy,” and “every time a new data center is provisioned, all policies must be re-evaluated and the appropriate keys assigned.” The attribute-based implementation relied on pairing operations, and its benchmark table, run at a deliberately high attribute size of 50, listed a 33,416-byte secret key and 19,419 bytes of ciphertext overhead.

The 2026 post drops that machinery in two sentences: “No production-ready post-quantum ABE scheme is available today, and customers do not need a large number of regions. A simpler design meets the requirement and is easier to maintain and operate.” The customer’s side becomes “Customers select a region and Cloudflare manages everything else,” and “most of our regions will be available for customers to regionalize their workflow, and there may be product specific caveats.”

What that gives up is visible in Cloudflare’s current setup documentation, last updated May 5, 2026. The version 2 beta takes a policy field with “allow and block lists of countries or regions,” and one of its two examples is titled “Store private keys in the E.U., but not in France,” with the policy (region: EU) and (not country: FR). The supported options page lists ten region codes (AFR, APAC, EEUR, ENAM, EU, ME, OC, SAM, WEUR and WNAM) plus individual countries by ISO code. Single units like these map naturally onto one root each. Set arithmetic does not. A node holds one root for every region it belongs to, so if customers could choose arbitrary sets of countries, the number of roots on each node would double with every country added. With n countries there are 2ⁿ minus 1 non-empty sets, and half of them, 2^{n minus 1}, contain any given country:

A fixed catalog is the straightforward way to keep that bounded, which is consistent with the post’s “customers do not need a large number of regions.” Negation is the awkward case. A catalog can add a dedicated region for the EU without France, or a layer in front of it could wrap the key once for each allowed member state. By my arithmetic, the other 26 member states at 1,136 bytes of overhead per wrap (a 1,120-byte encapsulation plus a 16-byte tag, as shown below) come to 29,536 bytes for one key, against 1,136 for a single regional wrap. The post describes neither approach. It does not mention negation, and it describes customers selecting “a region,” not combinations.

What the catalog buys is small secrets. An edge node’s share of the design is 32 bytes per region root, where the 2023 benchmark’s attribute-based secret key was 33,416 bytes (at that deliberately high attribute size), and adding a server to a region means delivering roots instead of issuing it a pairing-based key. The primitives are also standard parts: ML-KEM-768 is, in the post’s words, “a NIST standard.”

What the new wrap costs in bytes

The post gives no sizes or timings, only that Cloudflare is “enabling fast performance,” where the 2023 post carried a benchmark table. So I measured the sizes. The post says the KEM “combines ML-KEM-768 with X25519” but does not name it. The IANA HPKE registry, last updated April 16, 2026, holds two such hybrids, X25519Kyber768Draft00 (0x0030) and X-Wing (0x647A), and both list a 1,120-byte encapsulation. RFC 9180 itself defines only Diffie-Hellman KEMs (its Table 2 has no ML-KEM or hybrid entry), so both come from Internet-Drafts. The X-Wing draft is at revision 11, dated September 2026, and Cloudflare’s open-source CIRCL library lists both KEM IDs in its HPKE package. I used X-Wing because its decapsulation key is a 32-byte seed, which fits a design that derives key pairs from a 32-byte root. That fit is my reasoning, not something the post says. For the surrounding pieces, see my earlier notes on Cloudflare’s OHTTP Gateway (HPKE in practice) and a hybrid X25519 and ML-KEM key exchange in Python.

The script below builds X-Wing from the draft on top of the ML-KEM-768 and X25519 classes in the Python cryptography package, then prints what wrapping three common kinds of private key would cost. It was run on Python 3.13.14 with cryptography 50.0.1.

python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
python -m pip install "cryptography==50.0.1"
python wrap_sizes.py

# wrap_sizes.py
# wrap_sizes.py: what wrapping a private key with the X-Wing hybrid KEM costs in bytes
# Python 3.13, cryptography 50.0.1 (ML-KEM-768 and X25519), X-Wing as in draft-connolly-cfrg-xwing-kem-11
import hashlib
import os

from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import ec, ed25519, rsa
from cryptography.hazmat.primitives.asymmetric.mlkem import MLKEM768PrivateKey, MLKEM768PublicKey
from cryptography.hazmat.primitives.asymmetric.x25519 import X25519PrivateKey, X25519PublicKey

LABEL = bytes.fromhex("5c2e2f2f5e5c")  # the 6 byte XWingLabel
TAG = 16  # AES-256-GCM authentication tag (IANA HPKE AEAD registry, Nt for 0x0002)


def x_pub(sk):
    return X25519PrivateKey.from_private_bytes(sk).public_key().public_bytes_raw()


def xwing_public_key(sk):  # sk is the 32 byte X-Wing decapsulation key
    e = hashlib.shake_256(sk).digest(96)
    m = MLKEM768PrivateKey.from_seed_bytes(e[:64])
    return m.public_key().public_bytes_raw() + x_pub(e[64:96])


def xwing_encapsulate(pk):
    ek = os.urandom(32)
    ss_x = X25519PrivateKey.from_private_bytes(ek).exchange(X25519PublicKey.from_public_bytes(pk[1184:]))
    ss_m, ct_m = MLKEM768PublicKey.from_public_bytes(pk[:1184]).encapsulate()
    ct_x = x_pub(ek)
    return hashlib.sha3_256(ss_m + ss_x + ct_x + pk[1184:] + LABEL).digest(), ct_m + ct_x


def pkcs8(key):
    return key.private_bytes(serialization.Encoding.DER, serialization.PrivateFormat.PKCS8, serialization.NoEncryption())


pk = xwing_public_key(os.urandom(32))
ss, enc = xwing_encapsulate(pk)
print(f"X-Wing: public key {len(pk)} B, enc {len(enc)} B, shared secret {len(ss)} B")
keys = [("RSA-2048", rsa.generate_private_key(65537, 2048)),
        ("ECDSA P-256", ec.generate_private_key(ec.SECP256R1())),
        ("Ed25519", ed25519.Ed25519PrivateKey.generate())]
for name, key in keys:
    n = len(pkcs8(key))
    print(f"{name:12} key {n:>5} B   X25519 wrap {n + 32 + TAG:>5} B   X-Wing wrap {n + len(enc) + TAG:>5} B")
print(f"extra bytes per wrapped key: {len(enc) - 32}")

X-Wing: public key 1216 B, enc 1120 B, shared secret 32 B
RSA-2048     key  1218 B   X25519 wrap  1266 B   X-Wing wrap  2354 B
ECDSA P-256  key   138 B   X25519 wrap   186 B   X-Wing wrap  1274 B
Ed25519      key    48 B   X25519 wrap    96 B   X-Wing wrap  1184 B
extra bytes per wrapped key: 1088

RSA-2048 lengths vary by a few bytes between keys (1,216 to 1,219 across 20 keys in my runs). The extra 1,088 bytes are the ML-KEM-768 ciphertext, since the X25519 half is 32 bytes either way. The 2023 post’s benchmark lists 48 bytes of overhead for X25519, which matches a 32-byte public key plus a 16-byte tag, so the comparison column agrees with Cloudflare’s own figure. That post also explained why the growth is multiplied: the control plane writes each encrypted key into Quicksilver, and “every machine in each data center has a copy of every customer’s private key,” in encrypted form. The 2026 post gives no count of wrapped keys. As arithmetic only, a million wrapped keys would add about 1.01 GiB on every node.

Before using the model for the experiments below I checked its parts against published vectors. The X-Wing code reproduced the public key and the decapsulated secret for all three test vectors in the draft, the HPKE key schedule and first AES-GCM ciphertext matched RFC 9180 Appendix A.1.1, and OpenSSL 3.5.7 confirmed the ML-KEM-768 sizes (a 1,088-byte ciphertext and a 32-byte shared secret).

A fence made of distribution decisions

The cryptography enforces one thing: a server without the right root cannot unwrap. Everything about geography sits upstream of that, in which servers get which roots. In my model, a Berlin node holding the Germany and European Union roots opened a key wrapped for Germany. A Madrid node, which holds the EU root, and a Dallas node both failed closed. Relabeling the blob as an EU key failed authentication in Madrid, because in my model the boundary is bound into the key derivation and the HPKE info. That is the behavior the post claims, and it follows from the design.

What decides membership is Cloudflare’s inventory. The post says Zinc “maps that identity to a data center and location,” that the definition of a region changes as data centers go through maintenance or gain capacity, and that “GeoKey Manager’s provisioning layer refreshes that membership several times each day, granting or removing access to regional root keys as the network changes.” When it changes, the provisioning service “immediately synchronizes the server’s Linux kernel keyring,” but “the edge key service caches these keys in process memory until it restarts or the cache expires.” The post does not give the cache lifetime, so there is no stated bound on how long a server that has left a region keeps serving from it. It also separates the remedies: the keyring tracks membership, while the post ties removing “access to the previous epoch” to a hard rotation, which matters for any root that was copied while the server was a member.

The trust boundary is stated bluntly: “all services that can access the regional root key” include “the key-management service, the provisioning service, and authorized edge key services,” while Quicksilver stays outside it. So the fence constrains the data plane. The control-plane services that create, derive from and store the roots are not described as region-bound, and the post does not say where they run. It does say the vault behind provisioning is “managed by us on-premises.” For a customer whose requirement is about who can decrypt, that is a question about the operator’s own control plane, not about the edge.

It is also a change from 2023, when the post presented asymmetric policy keys with the advantage that “the central service doesn’t need access to secret key material to encrypt customer keys.” The 2026 post says the key-management service will “derive the corresponding asymmetric application key pair” from the root. A service that derives a key pair from a secret root has the private half available while it does so. Whether it keeps the private halves is not stated.

Blast radius on the post’s own example

The post gives two examples of what a compromise exposes. Acme Co. has a Tunnel key (acme0001) and a Gateway key (acme0002) for Germany, and Road Runner Inc. has a Tunnel key for Germany (runner0001) and a Gateway key for the European Union (runner0002). Compromising the Tunnel and Germany application key “could expose both acme0001 and runner0001, but not the Gateway keys,” and compromising the Germany root “could affect every application-specific key derived from that root for the same epoch, including acme0001, acme0002, and runner0001.” I wrapped four random 138-byte stand-ins for those keys with the model and tried each secret against each blob.

The model agrees with both of the post’s statements and adds a third column that the post leaves implicit: the EU root is a separate secret, so it opens only the EU-boundary key. A Berlin node holds both the Germany and the EU roots, so the narrower boundary has the smaller blast radius per compromise at the price of one more root on each node inside it.

Rotation behaved as the post describes it, with one limit worth stating. An edge that kept only the epoch 2 root failed closed on an epoch 1 blob, an edge that retained both epochs opened it, and after a hard rotation (rewrapping under epoch 2) the epoch 1 root no longer opened the new blob. But an adversary who had recorded the epoch 1 blob and stolen the epoch 1 root still recovered the customer’s key. A rotation can stop an old root from opening the rewrapped blob, but it cannot take back a key that someone already unwrapped, and that still means replacing the customer’s own key or certificate.

Cloudflare One first, CDN later

The post describes “the current Cloudflare One path,” and says GeoKey Manager “is the basis for an improved Regional Services offering for Cloudflare One; these new capabilities will be announced in a few months.” For web traffic it says: “Older versions of GeoKey Manager already provide geographic controls for private keys associated with CDN certificates. We are developing a separate integration that will bring this new post-quantum GeoKey Manager described here to that existing CDN capability. We will share testing and transition details when that work is ready.” Current Data Localization Suite customers who regionalize CDN traffic can “register intent to test.”

The documentation for the existing product, last updated April 16, 2026, says: “Currently, Geo Key Manager is limited to custom certificates and available only through the Cloudflare API.” The setup page still describes version 1 with three regions (U.S., E.U. and the highest-security data centers) and version 2 as a beta. Until the CDN integration ships, CDN keys stay on those older versions, which the post does not describe as post-quantum. This sits inside Cloudflare’s April 7 roadmap, which says “We now target 2029 to be fully post-quantum (PQ) secure including, crucially, post-quantum authentication.” Wrapping stored keys addresses confidentiality, the harvest now, decrypt later risk, and not authentication. My post on Cloudflare’s post-quantum visibility logs covers how uneven post-quantum key exchange is across the visitor and origin hops.

Questions to put to Cloudflare before relying on it

• Which hybrid KEM and which draft does the Cloudflare One path use, and how will it move when the drafts become RFCs?
• How long does the edge key service cache a root, and what is the longest time between a server leaving a region and its losing the ability to unwrap?
• How many previous epochs does a soft rotation keep by default, who can trigger a hard rotation, and how quickly does one finish?
• Where do the key-management service and the provisioning vault run, which regions’ roots can each reach, and does the key-management service keep the derived private halves?
• Which regions will exist, can a customer combine them or exclude a country the way the current documentation’s example does, and what replaces the 2023 policy language?
• When will the CDN integration ship, and what protects CDN keys until then?
• What evidence can a customer get that an unwrap happened inside the chosen region, such as logs or attestations? The post mentions neither.

Sources and method

• Cloudflare, Bringing post-quantum cryptography to geographically fenced key management, published October 23, 2026.
• Cloudflare, Inside Geo Key Manager v2: re-imagining access control for distributed systems, January 27, 2023.
• Cloudflare Docs, Geo Key Manager (overview, updated April 16, 2026), setup and supported options (both updated May 5, 2026).
• IANA, Hybrid Public Key Encryption (HPKE) registry; RFC 9180; draft-connolly-cfrg-xwing-kem, revision 11.
• Cloudflare, Zinc, post-quantum roadmap (April 7, 2026) and the CIRCL HPKE package.

I read the pages on October 24, 2026. The model uses Python 3.13.14, cryptography 50.0.1 and OpenSSL 3.5.7. It assumes X-Wing as the KEM, an HKDF derivation of the application key from the root with the service, boundary and epoch as input, and the key identifier plus those fields as HPKE info. The post names none of these, so the model shows consequences of the design as described and does not test Cloudflare’s service, which is in closed beta. The sizes, the 1.01 GiB figure, the 29,536-byte figure and the set counts are my own arithmetic or measurements, not Cloudflare’s numbers.