Quantum-safe SASE: Cloudflare closes the loop on post-quantum encryption
Earlier this year, Cloudflare shipped a post-quantum Secure Web Gateway (SWG) and Zero Trust solution — the first cloud-native offering of its kind. That covered the traffic path between end-user devices and the networks they reach. But the other half of the SASE equation, WAN and site-to-site traffic, remained on classical cryptography. That gap is now closed.
Cloudflare One is now the first SASE platform to support standards-based post-quantum encryption across its Secure Web Gateway and its Zero Trust and WAN on-ramps. Concretely, the platform supports hybrid ML-KEM (Module-Lattice-based Key-Encapsulation Mechanism) across all major entry and exit points.
Two additions complete the picture:
- Cloudflare IPsec — the cloud-native WAN-as-a-Service offering — now supports post-quantum encryption. IPsec establishes encrypted tunnels from a customer's network to Cloudflare's global network, with IP Anycast routing each tunnel to the nearest healthy data center automatically.
- Cloudflare One Appliance, the physical or virtual WAN appliance that establishes those IPsec connections, has been upgraded to version 2026.2.0, which is generally available. The Cloudflare IPsec post-quantum upgrade itself is in closed beta; interested customers can join the waitlist.
Why the migration can't wait until 2030
The clock on classical public-key cryptography is ticking. NIST set a 2030 deadline for deprecating RSA and Elliptic Curve Cryptography (ECC) in favor of quantum-resistant algorithms, and other agencies have echoed that timeline. Organizations that have not started the migration risk non-compliance and exposure.
History suggests the transition will not happen overnight. Cryptography has a long tail — MD5 was still causing problems two decades after its deprecation. Crypto agility, the ability to swap algorithms without rearchitecting a deployment, is the bottleneck. Baking post-quantum encryption directly into the SASE platform removes that friction for remote access and site-to-site connectivity.
The "Harvest Now, Decrypt Later" threat makes this urgent as well. Attackers can capture encrypted traffic today and store it until quantum computers can break it. Any data with a shelf life measured in years — financial records, health data, state secrets — is already at risk unless protected by post-quantum encryption.
Two separate migrations: keys and signatures
Moving network traffic to post-quantum cryptography requires changing two distinct primitives.
Key establishment is the first. ML-KEM has emerged as the industry-standard post-quantum key agreement protocol. It is deployed in TLS alongside classical Elliptic Curve Diffie Hellman (ECDHE), with the session key derived by mixing the outputs of both — a "hybrid ML-KEM" approach. Over 60% of human-generated TLS traffic to Cloudflare's network already uses it. The appeal is clear:
- It blocks harvest-now, decrypt-later attacks
- It needs no specialized hardware or dedicated physical connectivity, unlike quantum key distribution (QKD)
- It has minimal performance impact, even on short-lived TLS connections
Because ML-KEM runs in parallel with classical ECDHE, there is no security or compliance downgrade versus the classical-only approach.
Digital signatures are the second migration. They authenticate servers to clients and stop active adversaries. The problem: post-quantum signatures are much larger than classical ECC ones, which has slowed adoption. The urgency is lower, though — PQ signatures defend against active attackers already armed with powerful quantum computers, which do not exist yet. Cloudflare is contributing to PQ signature standardization, but the current IPsec upgrade focuses on the more pressing key-establishment migration. The U.S. Cybersecurity & Infrastructure Security Agency (CISA) drew the same distinction in its January 2026 publication on product categories for post-quantum cryptography standards.
IPsec’s detour through pre-shared keys and QKD
Post-quantum progress in IPsec has followed a different path than TLS. TLS secures public internet traffic at Layer 4, where interoperability is paramount. IPsec operates at Layer 3 and often links devices from the same vendor, making cross-vendor compatibility less of a historical priority. That distinction shaped how the protocol community approached quantum resistance.
The first attempt, RFC 8784 from May 2020, updated IKEv2 to mix a pre-shared key (PSK) with a key from classical Diffie-Hellman (DHE). This hybrid approach does block harvest-now-decrypt-later attacks, but it sacrifices the forward secrecy that standard key agreement protocols are expected to provide. If an adversary harvests encrypted traffic and later obtains the long-lived PSK, a future quantum computer could break the DHE component and decrypt everything.
RFC 8784 also permits replacing the classical component with a key derived from quantum key distribution (QKD). That option is impractical for most internet use: QKD requires specialized hardware or dedicated physical links, making it unusable for scenarios like a laptop connecting to a remote server over Wi-Fi. Cloudflare never deployed QKD for its IPsec products, and the NSA, Germany’s BSI, and the UK NCSC have all cautioned against relying on it exclusively.
Standards, ciphersuite bloat, and a better draft
In May 2023, RFC 9370 moved IPsec toward hybrid key agreement, but it left too much open. The standard permits up to seven different key agreements running in parallel with classical DHE, and it remains silent on which algorithms vendors should implement. The result has been fragmentation: some vendors ship multiple post-quantum ciphersuites that do not interoperate with other vendors’ equipment, and in some cases use algorithms NIST has not yet standardized.
TLS went the other direction. TLS 1.3 reduced ciphersuites from hundreds to roughly five, an approach echoed in NIST SP 800 52. Fewer ciphersuites mean better cross-vendor interoperability, fewer downgrade attacks, lower misconfiguration risk, and a smaller codebase to audit for flaws. That philosophy explains why Cloudflare did not initially implement RFC 9370.
The IPsec community’s draft-ietf-ipsecme-ikev2-mlkem aligns with TLS practice. It specifies hybrid ML-KEM as the additional key exchange alongside classical Diffie-Hellman in IKEv2.
Hybrid ML-KEM in Cloudflare IPsec
Cloudflare IPsec is a WAN Network-as-a-Service product that connects data centers, branch offices, and cloud VPCs to Cloudflare’s anycast network. The Cloudflare edge acts as the IKEv2 Responder, accepting sessions from branch connector initiators including Cloudflare’s own appliance and devices from Cisco, Juniper, Palo Alto Networks, Fortinet, Aruba, and others.
The implementation follows draft-ietf-ipsecme-ikev2-mlkem: a classical DHE exchange runs first and derives a key, that key encrypts the second ML-KEM exchange, then the outputs of both exchanges are mixed to secure the data plane in ESP mode. ESP uses symmetric cryptography, so the data plane is already quantum-safe without further changes. Cloudflare tested its Responder implementation against the initiator in the strongSwan reference stack. This ciphersuite appears in the IPsec logs.
Cloudflare deliberately chose hybrid ML-KEM over pure ML-KEM for two reasons. Every other Cloudflare product uses hybrid ML-KEM, consistent with the broader TLS community. It also provides defense in depth: ML-KEM protects against quantum harvest-now-decrypt-later attacks, while DHE remains a battle-tested defense against conventional adversaries.
Cloudflare One Appliance takes the TLS route
The Cloudflare One Appliance does not use IKEv2 for key establishment. Instead, the appliance opens a TLS handshake with the Cloudflare edge, derives a symmetric secret over that connection, and injects the secret into the IPsec ESP layer for data-plane encryption. That architecture lets Cloudflare reuse its TLS libraries instead of building IKEv2 initiator logic.
Making the appliance post-quantum was therefore straightforward: a TLS 1.2 to TLS 1.3 upgrade with hybrid ML-KEM, a routine change across Cloudflare products.
Availability and interoperability
The post-quantum upgrade to Cloudflare IPsec costs customers nothing extra, in line with Cloudflare’s policy of shipping PQC across products without specialized hardware or additional fees. Appliance users received the upgrade automatically in version 2026.2.0, released 2026-02-11, during each device’s configured interrupt window. No customer action is required.
Full value depends on interoperability. Cloudflare is inviting vendors building IPsec initiator support per draft-ietf-ipsecme-ikev2-mlkem to test against its implementation. Customers testing third-party branch connectors in the closed beta can sign up and request interoperability with a specific vendor as more support comes online.
The complete post-quantum path
With the addition of Cloudflare IPsec and the Cloudflare One Appliance, organizations can now route private network traffic over tunnels secured by hybrid ML-KEM. That covers the full journey: from an on-ramp like the Cloudflare One Client or an IPsec gateway to an off-ramp such as Cloudflare Tunnel or a Cloudflare One Appliance. Because the encryption is applied at the tunnel level, traffic is protected against harvest-now-decrypt-later attacks even when the underlying applications have not yet been upgraded to post-quantum cryptography.
The on-ramps supported include:
- Clientless access via TLS 1.3 with hybrid ML-KEM, assuming browser support
- Cloudflare One Client using MASQUE over TLS 1.3 with hybrid ML-KEM
- Cloudflare IPsec on-ramp
The corresponding off-ramps are:
- Cloudflare Tunnel off-ramp using TLS 1.3 with hybrid ML-KEM
- Cloudflare IPsec off-ramp
In a typical configuration, an end user's device connects to the Cloudflare network via MASQUE with hybrid ML-KEM (link 1). Traffic then traverses Cloudflare's global backbone over TLS 1.3 with hybrid ML-KEM (link 2), before exiting through a post-quantum IPsec tunnel to a Cloudflare One Appliance on the customer's premises (link 3). The final hop to an internal server is unprotected only because it never travels over the public Internet—yet the entire external path is encrypted with post-quantum cryptography, regardless of whether the destination server supports it.
Post-quantum secure web gateway
Traffic that egresses to the public Internet through Cloudflare One is also covered. The post-quantum Cloudflare Gateway, the Secure Web Gateway (SWG), supports hybrid ML-KEM on the segment from the SWG to the origin server and on the client-to-SWG leg, provided both endpoints support it. But even when a browser does not yet implement hybrid ML-KEM, traffic on-ramping via a device with the Cloudflare One Client remains protected by the post-quantum MASQUE tunnel the client establishes. The same holds for traffic that arrives at the SWG through a post-quantum IPsec tunnel. This effectively extends end-to-end post-quantum protection to all third-party web applications, independent of browser capabilities.
Standards over proprietary shortcuts
With Cloudflare IPsec and the Cloudflare One Appliance, post-quantum encryption now spans every major on-ramp and off-ramp on the platform—TLS, MASQUE, and IPsec—for both private network traffic and web egress via the SWG. The design leans on hybrid ML-KEM, the approach endorsed by the IETF and NIST, rather than proprietary ciphersuite extensions or hardware refreshes. That choice keeps implementations interoperable and avoids the fragmentation that typically accompanies cryptographic transitions.
The result is a SASE platform that delivers post-quantum encryption where legacy architectures cannot. Whether the traffic originates from a remote worker's browser or a multi-gigabit data center link, it is shielded from harvest-now-decrypt-later threats. The Cloudflare IPsec capability is currently available in closed beta; Cloudflare also offers a full demonstration of post-quantum capabilities across the Cloudflare One platform.
