Cloudflare recently implemented a new standardized approach to Post-Quantum IPsec, moving away from previous ‘ciphersuite bloat’ in favor of a hybrid ML-KEM exchange. The move signals a shift in how wide-area networks (WANs) will meet the NIST 2030 deadline for quantum-resistant encryption without requiring specialized hardware
The company brings hybrid Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM) to Cloudflare IPsec and the Cloudflare One Appliance, wrapping up what Cloudflare calls the “post-quantum SASE equation” allowing organizations to finally lock down private network traffic end-to-end against “harvest now, decrypt later” attacks, the ones in which bad actors grab encrypted data today and sit on it until quantum computers are powerful enough to crack it open.
Matthew Prince, Cloudflare’s CEO and co-founder, put it bluntly:
Securing the Internet against future threats shouldn’t be a complex burden. Since 2017, we’ve been doing the heavy lifting to bake post-quantum standards directly into the fabric of our network. By bringing this protection to our entire SASE platform, we’re making post-quantum security the default—no hardware upgrades, no complex configurations, and no added cost.
Earlier, NIST set a hard 2030 deadline for ditching RSA and Elliptic Curve Cryptography in favor of quantum-resistant algorithms. Late 2024 brought a clear signal that the days of classical public-key cryptography are numbered. Germany’s BSI and the UK’s NCSC have been saying the same thing.
Cloudflare’s approach follows draft-ietf-ipsecme-ikev2-mlkem, which standardizes post-quantum key exchange for IPsec in the same way TLS has. The hybrid setup runs ML-KEM in parallel with classical Diffie-Hellman. Think of it as belt-and-suspenders security: ML-KEM handles quantum threats, Diffie-Hellman covers classical attacks.
IPsec’s road to post-quantum looked nothing like TLS’s journey. Early attempts with RFC 8784 leaned on pre-shared keys or quantum key distribution, neither of which worked well in practice. Pre-shared keys don’t offer forward secrecy against quantum adversaries. QKD needs specialized hardware, which is a non-starter for most deployments. Then RFC 9370 came along and allowed up to seven different algorithms running at once. Cloudflare called this “ciphersuite bloat.” Palo Alto Networks went all-in with seven-plus PQC ciphersuites, most of which don’t play nice with other vendors.
The draft-ietf-ipsecme-ikev2-mlkem spec finally got IPsec aligned with how TLS does things. Cloudflare built production hybrid ML-KEM support into its IPsec IKEv2 Responder and ran tests against the strongSwan reference implementation to ensure it works.
The Cloudflare One Appliance got the upgrade automatically on February 11th via version 2026.2.0. Since the appliance uses TLS instead of IKEv2, the update was pretty straightforward—just a jump from TLS 1.2 to TLS 1.3 with hybrid ML-KEM baked in.
Cloudflare IPsec is still in closed beta while the company works on interoperability with third-party branch connector vendors. Security Brief Australia noted the changes slot into Cloudflare’s global network with high-availability routing that automatically reroutes traffic if a data center goes down.
The full picture now includes post-quantum encryption across TLS, MASQUE, and IPsec on-ramps and off-ramps. Over 60% of human-generated TLS traffic hitting Cloudflare’s network already uses hybrid ML-KEM, according to Cloudflare Radar data.
None of this costs extra. CISA recognized the split between key agreement and digital signature migrations in its January 2026 publication. Cloudflare’s current push focuses on key establishment through hybrid ML-KEM. Digital signatures are less urgent since they’re designed to stop active adversaries with quantum computers, which don’t exist yet.
