Cloudflare Ships Post-Quantum IPsec With Cisco and Fortinet Interoperability
April 30, 2026 — Cloudflare today announced general availability of post-quantum encryption for its IPsec service. The implementation uses hybrid ML-KEM (FIPS 203) cryptography and has been tested for interoperability with branch connectors from Cisco and Fortinet.
The release extends Cloudflare’s post-quantum cryptography deployment beyond TLS web traffic into enterprise wide-area networks (WANs), addressing harvest-now-decrypt-later threats against site-to-site connections, VPN tunnels, and data center interconnects. The company reports that while two-thirds of human-generated TLS traffic to its network already uses post-quantum protection, the IPsec ecosystem has lagged approximately four years behind.
Cloudflare’s implementation follows the draft-ietf-ipsecme-ikev2-mlkem specification, which combines classical Diffie-Hellman key exchange with ML-KEM in a single handshake; Cloudflare’s changelog lists Diffie-Hellman group 20 paired with ML-KEM-768 or ML-KEM-1024. The classical exchange runs first, encrypts a second ML-KEM exchange, and both outputs are mixed into session keys that secure ESP protocol traffic.
According to Cloudflare, customers using Cisco 8000 Series Secure Routers on IOS XR 26.1.1 can establish post-quantum tunnels with its network, as can customers on Fortinet FortiOS 7.6.6 and later. Both implementations follow the same IETF draft specification.
The announcement comes three weeks after Cloudflare moved its target for complete post-quantum security forward to 2029, citing recent advances in quantum computing hardware. The IPsec release represents one component of that accelerated timeline.
Cloudflare attributed the four-year gap between TLS and IPsec post-quantum adoption to the IPsec community’s continued interest in Quantum Key Distribution (QKD), as codified in RFC 8784. The company reiterated its position against QKD, citing requirements for specialized hardware, dedicated physical links, and lack of authentication capabilities.
My Analysis
This announcement matters because IPsec protects fundamentally different traffic than TLS. When I talk to security teams about post-quantum migration, they often focus on web traffic first. That makes sense—browsers update automatically, TLS libraries are well-maintained, and Cloudflare already protects the majority of their TLS traffic with PQC. But IPsec? That’s your corporate backbone.
IPsec tunnels carry the traffic between your data centers. They secure the connections from branch offices back to headquarters. They protect VPN traffic from remote workers accessing internal systems. This traffic often includes database replication, internal API calls, backup streams, and other sensitive operational data that never touches a web browser. If you’re worried about harvest-now-decrypt-later attacks, this internal traffic presents a particularly juicy target.
The Cisco and Fortinet interoperability changes the equation for enterprise deployment. Previously, if you wanted post-quantum IPsec, you faced vendor lock-in or proprietary implementations. Now you can use existing Cisco 8000 series routers or FortiGate appliances. No forklift upgrades. No specialized quantum hardware. Just a software update to protect against future quantum threats.
What strikes me about Cloudflare’s approach is their explicit rejection of QKD. The IPsec community spent years chasing quantum key distribution—a technology that requires dedicated fiber links between endpoints. I’ve watched enterprises struggle with QKD pilots that work great in a lab but fall apart when you need to connect offices across the public internet. QKD also lacks authentication. You still need classical or post-quantum crypto to verify you’re talking to the right endpoint.
The four-year delay between TLS and IPsec PQC adoption tells us something important about how cryptographic transitions actually happen. TLS moved fast because the community quickly converged on a single approach. Browser vendors, CDN providers, and web servers all implemented the same hybrid key exchange. The IPsec world fragmented. Some vendors pushed QKD. Others implemented RFC 9370 with proprietary ciphersuites before the ML-KEM draft existed.
I find the timing significant. Cloudflare announced their accelerated 2029 timeline for full post-quantum security just three weeks ago. Now they’re shipping a critical piece of that puzzle. This suggests they’re serious about the timeline and have concrete plans to execute.
The Enterprise Security Implications
For enterprise security teams, this release creates both opportunity and pressure. The opportunity: you can now protect site-to-site traffic with quantum-resistant encryption using equipment you probably already own. The pressure: if Cloudflare hits their 2029 target while your WAN traffic remains vulnerable, you’ve created an asymmetric risk profile.
Think about it this way. An attacker harvesting traffic today needs to capture and store everything, hoping Q-Day arrives while the data still has value. But they don’t harvest uniformly. They target high-value streams. If your web traffic uses post-quantum TLS but your site-to-site connections don’t, guess where they’ll focus their collection efforts?
The implementation details matter here. Cloudflare uses hybrid cryptography, combining classical Diffie-Hellman with ML-KEM. This hedges against both quantum attacks and potential weaknesses in the new algorithms. NIST standardized ML-KEM (formerly CRYSTALS-Kyber) in 2024, but we’re still learning about its real-world security properties. Running both classical and post-quantum key exchanges provides defense in depth.
The sequential design—classical exchange first, then ML-KEM encrypted by the classical session—also reveals careful security thinking. Even if an implementation flaw exposed the ML-KEM exchange, the classical encryption provides a safety net. This kind of belt-and-suspenders approach makes sense when deploying new cryptography at scale.
What’s Still Missing
Cloudflare’s announcement focuses on encryption, not authentication. They’ve solved the harvest-now-decrypt-later problem for IPsec, but not the post-Q-Day active attack scenario. Current IPsec authentication uses RSA or ECDSA signatures that quantum computers will break. We need post-quantum signatures too.
The NIST PQC standards include ML-DSA and SLH-DSA for signatures, and the IETF IPsec working group has drafts for post-quantum authentication in IKEv2. Cloudflare’s release covers key agreement only. Until authentication migrates, a future quantum attacker could still impersonate endpoints and mount man-in-the-middle attacks. It’s half the solution, though arguably the more urgent half given current harvest-now-decrypt-later risks.
The vendor ecosystem remains fragmented. Cloudflare achieved interoperability with Cisco and Fortinet, but what about Juniper, Palo Alto, Check Point, and others? Each vendor that implements their own approach before standards solidify creates another island of incompatibility. The IPsec community needs to converge on draft-ietf-ipsecme-ikev2-mlkem quickly, before we end up with a dozen incompatible “post-quantum” implementations.
The Competitive Landscape
Managed VPN and site-to-site services from other cloud providers will need the same capability.
This creates an interesting dynamic. Enterprises often use multiple cloud providers. If only one offers quantum-resistant site-to-site connections, how do you architect around that? Do you route all inter-cloud traffic through the quantum-ready provider? Accept the risk on some connections? The asymmetry could drive some unexpected network topology decisions.
Traditional network vendors face their own challenges. Cisco and Fortinet moved quickly to support the new standard, but they’ll need to backport support to older equipment that enterprises won’t replace for years. The companies that figure out software updates for existing hardware will win. Those that try to force hardware refresh cycles will lose customers to cloud-native alternatives.
Practical Next Steps
If you’re running Cloudflare IPsec with compatible Cisco or Fortinet equipment, enabling post-quantum encryption should be straightforward. But I’d recommend starting with non-critical connections first. New cryptographic implementations sometimes have bugs or performance impacts. Test thoroughly before protecting production traffic.
For security teams still building their post-quantum roadmaps, this announcement provides a concrete milestone. You can now tell executives: “Major providers are shipping quantum-resistant infrastructure today. Our competitors may already be deploying it.” That’s often more compelling than abstract discussions about quantum computing timelines.
The most important takeaway? Post-quantum cryptography has moved from research projects and browser experiments into production infrastructure. The migration is happening now, whether your organization is ready or not. Cloudflare’s 2029 target looks increasingly achievable, and they’re not waiting for others to move first.
The IPsec announcement might seem like a narrow technical development. But it signals something larger: the infrastructure foundations of the internet are beginning their quantum transition. The question isn’t whether your organization will migrate to post-quantum cryptography. It’s whether you’ll lead, follow, or scramble to catch up.
