Fail-Closed Key Release, Explained
When a security check fails, the request dies — and that's the design.
Reviewed by Abhijith N M · 24 October 2026 · Editorial standards
Cloudflare has moved a post-quantum rebuild of GeoKey Manager into closed beta. The older version, in place since 2022, used attribute-based encryption: the key itself carried rules about who could decrypt it. The rebuild replaces that with a hybrid ML-KEM-768 and X25519 scheme. ML-KEM is a post-quantum key encapsulation mechanism — a way for two parties to agree on a shared secret, built on lattice problems believed hard for quantum computers. X25519 is the elliptic-curve method used today. Combining both shared secrets through a key-derivation function means the result stays secure as long as at least one of the two algorithms holds up — so a future quantum break of X25519 alone doesn't expose the key. Separately, the keys live only in kernel memory on verified regional servers. Kernel memory is memory the OS kernel controls; ordinary user-space processes cannot read it without a kernel bug or elevated access. The evidence says the servers are verified but does not spell out the verification mechanism, so treat attestation as a plausible example rather than a confirmed detail. Now the tradeoff. If any check fails — verification, region, whatever the gate is — the request is rejected. That's fail-closed. Compare fail-open, where a broken check lets traffic through and you fix it later. Fail-closed is the right default for key material, because a key released to the wrong machine is a breach you can't undo. The worry practitioners raised is availability. If a check breaks in one region — a bad update, a config drift — every request there is denied. That looks like an outage even though nothing crashed. The evidence reports that practitioners raised this concern; whether it materializes in practice is analysis, not a confirmed Cloudflare behavior. According to InfoQ's reporting, general availability is planned for Q1 2027, so the closed beta is where that tension gets tested.
Fail-Closed Key Release, Explained — Visual Breakdown
# Pseudocode — illustrative only, not runnable.
# Real hybrid KDFs (e.g. RFC 9370-style combiners) specify exact
# input ordering, labels, and lengths; follow your library's spec.
import logging
log = logging.getLogger(__name__)
def release_key(server, region, our_private_key, kdf):
# Fail-closed: any failed check returns None, never a key.
if not server.verification_ok():
log.warning("verification failed", extra={"server": server.id})
return None
if server.region != region:
log.warning("region mismatch", extra={"server": server.id})
return None
# Hybrid: encapsulate to the server's ML-KEM public key.
# The ciphertext must be sent to the server so it can decapsulate
# and derive the same shared secret.
ct_pq, ss_pq = ml_kem_768_encapsulate(server.pq_public_key)
send_to_server(server, ct_pq)
# X25519 key exchange: both sides compute the same shared secret.
ss_x = x25519(our_private_key, server.x_public_key)
# Combine both secrets through a KDF; the result stays secure
# as long as at least one of the two algorithms holds up.
return kdf(ss_pq, ss_x, info=b"geokey-release")
# Caller side: no key means no service, not a fallback.
key = release_key(srv, "eu-west", our_private_key, kdf)
if key is None:
raise ServiceUnavailable("key release denied")Quick Concept Check
Test your understanding in 15 seconds
A server in an approved region fails verification under a fail-closed key release policy. What happens?
Related Concepts
Written and edited by the nexGenCoders team. Spotted a mistake? Tell us and we will fix it.