Skip to content

StoriesCloudflare

Cloudflare opens closed beta of post-quantum GeoKey Manager using ML-KEM-768 and X25519

Cloudflare rebuilt GeoKey Manager around hybrid ML-KEM-768 and X25519, dropped attribute-based encryption, and set general availability for Q1 2027.

ContentBuffer · Built from 12 sources · Updated · 6 min read

TL;DR

Yes, for Cloudflare Data Localization Suite customers, in closed beta. The rebuilt GeoKey Manager wraps region-locked keys with hybrid ML-KEM-768 and X25519, replaces attribute-based encryption, and fails closed when checks fail. Cloudflare plans general availability for the first quarter of 2027.

Press image from infoq.com
Image: infoq.com (press-kit)

What shipped

The short version

Are your region-locked encryption keys safe from a quantum computer? For Cloudflare customers, that answer just got a beta. The service now protects geographically fenced decryption keys with a hybrid of ML-KEM-768 and X25519 (lavx.hu). It throws out the scheme it adopted in 2022.

The beta is open to Data Localization Suite customers, with general availability planned for Q1 2027 (daily.dev). So this isn't a product you can click on today unless you're already in that program.

Today, Cloudflare is launching a post-quantum geographically restricted key manager

Cloudflare engineering blog, vendor announcement Today, Cloudflare is launching a post-quantum geographically restricted key manager in support of our Data Localization Suite (DLS) in closed beta.

What it actually does

The new GeoKey Manager wraps each customer decryption key so it can only be unwrapped by Cloudflare servers located in an approved geography (daily.dev). That's the whole point. Your key works in the EU, say, and nowhere else.

The crypto stack is a standard one. Combining post-quantum and classical components keeps data confidential as long as at least one component remains secure (daily.dev).

The operational details

Here's where it gets interesting for people who run infrastructure.

  • Regional root keys are 256-bit symmetric secrets stored in a server's kernel keyring rather than on disk (daily.dev).
  • They live only in volatile kernel memory on verified servers, so a restart wipes them and forces re-authentication (daily.dev).
  • The system supports soft and hard key rotation for transitioning between key epochs (daily.dev).
  • Edge servers fail closed if a required regional root key is missing (daily.dev).

That last one is the design's defining choice. Any failed region, epoch or service check causes the system to reject the request (daily.dev). Security teams will like it. Your on-call rotation might not.

Why the old scheme died

GeoKey Manager shipped in 2017 for TLS keys before moving to attribute-based encryption in 2022 (lavx.hu). Cloudflare gives two reasons for dropping that approach. No production-ready post-quantum variant exists, and customers don't need the large number of regions it was built to express (infoq.com). That's a blunt admission. The fancy policy engine was overbuilt for what people actually bought.

How it compares

Against Cloudflare's own edge

The key manager follows a pattern Cloudflare has been running for a while. Cloudflare adopted hybrid ML-KEM for its IPsec service in March, when over 60% of human-generated TLS traffic on its network already used it (infoq.com). The same hybrid recipe now covers key storage as well as transport.

The traffic numbers have kept climbing. That's the visitor-to-Cloudflare leg. The other leg looks very different. Just about 15% of origins that Cloudflare connects to use hybrid ML-KEM (cloudflare.com).

Connection legPost-quantum share (Cloudflare figures)
Browser to Cloudflareabout 70%
Cloudflare to originabout 15%

Against the old way

GeoKey Manager's previous design leaned on ciphertext-policy attribute-based encryption. That approach could express complex access rules. It had no post-quantum version ready for production, so Cloudflare replaced it with something simpler and standardized.

The new construction is boring on purpose. HPKE is an RFC. ML-KEM is specified by NIST FIPS 203, which defines ML-KEM-512, ML-KEM-768 and ML-KEM-1024 (aicybr.com). Cloudflare picked the middle parameter set.

Against the rest of the market

Other vendors are moving too. Google Cloud has introduced quantum-safe key encapsulation mechanisms within Cloud Key Management Service, enabling hybrid-classical post-quantum key establishment (arxiv.org). AWS has rolled ML-KEM support into KMS, ACM, Secrets Manager, S3, and Transfer Family (shattered.io).

The difference is the geographic fence. Those offerings protect key establishment. Cloudflare is tying post-quantum protection to a sovereignty control. That control is where customer keys can be unwrapped (runtimewire.com). I haven't seen a rival bundle the two the same way, though I only checked the sources above.

The cost of ML-KEM

Hybrid isn't free. An ML-KEM-768 public key is 1,184 bytes versus 32 bytes for X25519 (jacar.es). For TLS handshakes, that bloat matters. For a key-wrapping service that unwraps keys occasionally, it's noise. That's a good fit for the algorithm.

Who it hurts

Teams that never planned for this

The pain lands on specific people. If you're a Data Localization Suite customer who depends on the old attribute-based scheme, your key wrapping is changing under you. Cloudflare made the call that most customers didn't need what that scheme offered. If you did need it, you're now the exception.

Anyone with exotic region expressions loses flexibility. The replacement is region-based and simple. Check your configuration before general availability, not after.

On-call engineers

Fail-closed is the real operational cost. One commenter questioned whether the failure behavior could trigger a regional outage (daily.dev). That's a fair worry. If a required regional root key goes missing, the edge server stops serving.

Volatile keys compound it. A restart wipes the keys and forces re-authentication (daily.dev). Reboots become events. Plan for them.

The beta will test whether customers accept a design that refuses to serve when checks fail (lavx.hu). I'd bet most regulated customers say yes. They asked for sovereignty, and this is what enforcement looks like.

Origins that lag behind

The geo-fence doesn't fix the other half of your exposure. The gap is usually the server's OpenSSL version (privatedevops.com). OpenSSL added ML-KEM in version 3.5.0, released on April 8, 2025, and made the hybrid group part of its defaults (privatedevops.com).

If your origin runs something older, traffic from Cloudflare to your server isn't post-quantum, however well your keys are wrapped. Harvest-now, decrypt-later attackers record that leg today.

Scope limits

Don't assume every product is covered. The compatibility matrix describes DLS product compatibility generally, and isn't an assertion that each listed product already supports the new post-quantum beta (aicybr.com). Ask your account team which services are in the beta before you plan around it.

What to watch

The Q1 2027 date

A public release is scheduled for the first quarter of 2027 (forklog.com). That's a firm target from several reports. Watch whether it moves, and whether "public" means open to all plans or still DLS only.

Fail-closed in the wild

The beta is a test of operations as much as cryptography. Watch for incident reports tied to missing regional root keys. A single regional outage caused by this design would set the tone for how customers judge it. If the beta stays quiet, the choice looks right.

Origin adoption

The 15% origin figure is the one to track. That's real growth. It's also still the weak leg.

Cloudflare also published tooling for this. You can check logs to see if you're using post-quantum encryption on the Cloudflare-to-origin connection (cloudflare.com). Run that check this week.

The wider post-quantum stack

Key exchange is the easy part. Digital signatures remain classical, and post-quantum certificates remain rare (jacar.es). Cloudflare has since set out plans for a quantum-safe certificate authority (infoq.com). Watch that next. GeoKey Manager covers key confidentiality. It does nothing for authentication.

  • Watch for the beta's expansion beyond DLS customers.
  • Watch for Cloudflare's post-incident writeups.
  • Watch for competitors adding geographic fencing to their own post-quantum key services.

What this means

My take

This is a small product with a sharp signal. Cloudflare didn't chase novelty. It dropped a clever 2022 design because it couldn't be made post-quantum, and swapped in an RFC-based construction anyone can audit. I like that. Boring crypto ages well.

The harvest-now, decrypt-later threat is why this exists. The hybrid scheme protects against harvest now, decrypt later attacks (daily.dev). Data encrypted today with keys that quantum machines can later break is the risk. Wrapped keys are the crown jewels of that risk, so protecting them first is the right order.

What to do

If you're a DLS customer, ask for beta access and test your failure paths. Kill a regional root key in staging. See what your users see. Fail-closed only works if you've practiced it.

If you're not a DLS customer, the lesson is still useful. Your visitors are mostly covered. Only about 15 percent of the origin servers Cloudflare connects to use post-quantum encryption (privatedevops.com). Upgrade OpenSSL on your origins and turn on the hybrid group.

The honest caveat

I can't tell you how the beta performs. The sources describe design and intent, not benchmarks or customer results. Cloudflare hasn't published latency or outage data for GeoKey Manager, and none of the coverage I found has any. Treat the Q1 2027 date as a plan, not a promise.

The sovereignty angle will probably matter more than the quantum angle for buyers in regulated industries. They already needed region-locked keys. Post-quantum is now a checkbox attached to a requirement they already had.

Stories like this, before they trend.

One email a day. Sources listed. Free.

Join 3,568 builders reading daily.

Also get

Sources