Skip to content

CLOUDFLARE 2026-04-30 Tier 1

Read original ↗

Cloudflare — Post-quantum encryption for Cloudflare IPsec is generally available

Summary

Cloudflare announces general availability of post-quantum encryption for Cloudflare IPsec, implementing the IETF draft draft-ietf-ipsecme-ikev2-mlkem which specifies hybrid ML-KEM (NIST FIPS 203) for the IPsec / IKEv2 key-exchange handshake. The post frames the rollout as a four-years-late counterpart to TLS — TLS adopted hybrid ML-KEM in 2022 because the TLS community converged early on a single interoperable standard; the IPsec community did not, and the delay is explicitly attributed to QKD distraction + ciphersuite bloat arising from the looser RFC 9370 (2023) which opened the door to PQ key-exchange in IPsec but did not specify which ciphersuites to use. Interoperability tests with Cisco 8000 Series Secure Routers (26.1.1+) and Fortinet FortiOS (7.6.6+) as branch connectors are confirmed; Palo Alto Networks' RFC 9370-based implementation does not yet interoperate because it shipped before the draft was available. The post closes by naming the remaining work — post-quantum authentication for IPsec is still unspecified in IETF drafts, and the industry must not let QKD distract focus again as the 2029 full-PQ target approaches.

Key takeaways

  • Hybrid ML-KEM is the IPsec post-quantum encryption standard. draft-ietf-ipsecme-ikev2-mlkem runs a classical Diffie-Hellman exchange first, uses its derived key to encrypt a second exchange running ML-KEM, and mixes both outputs into the session keys that secure the IPsec data plane via Encapsulating Security Payload (ESP). (Source: sources/2026-04-30-cloudflare-post-quantum-encryption-for-cloudflare-ipsec-is-ga) This is the canonical hybrid KEM construction applied to IPsec: the composite is at least as strong as the stronger of the two KEMs; compromising both requires breaking both.

  • Motivating threat is HNDL.

    "Cloudflare IPsec now uses post-quantum encryption with hybrid ML-KEM (FIPS 203) to stop harvest-now-decrypt-later attacks. These are attacks where an adversary harvests data today and then decrypts later, after Q-Day, when there are powerful quantum computers that can break the classical public key cryptography used across the Internet."

  • Interoperability is the load-bearing win. Closed beta tested against a reference implementation (strongswan); GA confirms interop with Cisco 8000 Series Secure Routers 26.1.1+ and Fortinet FortiOS 7.6.6+ as branch connectors. Customers can establish PQ-protected tunnels to Cloudflare's global network using hardware they already have.

  • Why IPsec took four years longer than TLS. TLS turned on hybrid PQ key agreement in 2022; IPsec's full specification only landed in late 2025. Two named causes: (a) QKD distraction — the IPsec community's continued interest in Quantum Key Distribution (codified in RFC 8784 from 2020) consumed standards-community focus; Cloudflare argues QKD "will not operate at Internet scale" because it requires specialized hardware + dedicated physical links + does not provide authentication, and the NSA / BSI / NCSC have all warned against solely relying on it. (b) Ciphersuite bloat from RFC 9370 — published in 2023, RFC 9370 allowed up to seven key exchanges to be run in parallel with classical Diffie-Hellman but did not specify which ciphersuites should be used; vendors shipped early implementations under RFC 9370 defining their own non-NIST-standardised ciphersuites.

    "This is exactly the kind of 'ciphersuite bloat' NIST SP 800 52r2 warned against. And the risks to interoperability have played out in practice: Cloudflare IPsec does not yet interoperate with Palo Alto Networks' RFC 9370–based implementation, because it was launched before draft-ietf-ipsecme-ikev2-mlkem was available."

  • ML-KEM is implementable on standard processors. Unlike QKD,

    "ML-KEM is intentionally designed to be implemented in software across standard processors to provide post-quantum encryption of network traffic. It does not require special hardware or a dedicated physical link between sender and receiver." This is the load-bearing property making Internet-scale interoperability possible in the first place.

  • Cloudflare IPsec is a Cloudflare One / Magic WAN primitive. The post positions Cloudflare IPsec as a WAN Network-as-a-Service that replaces legacy network architectures by connecting data centers, branch offices, and cloud VPCs to Cloudflare's global IP Anycast network via encrypted IPsec tunnels — supporting site-to-site WAN + outbound Internet + connectivity to the Cloudflare One SASE platform.

  • Post-quantum authentication for IPsec is the remaining gap.

    "While draft-ietf-ipsecme-ikev2-mlkem supports post-quantum encryption, we still need IPsec standards for post-quantum authentication, so that we can stop attacks by quantum adversaries on live systems after Q-Day. Given the shortened timeline for full post-quantum readiness, we hope the IPsec community will continue to focus on interoperable PQC implementations, rather than diverting focus to niche use cases with QKD." Parallels the TLS → authentication pivot canonicalised in concepts/post-quantum-authentication and Cloudflare's 2026-04-07 PQ roadmap.

  • Default-on, no additional cost. The post explicitly ties the rollout to Cloudflare's strategic posture:

    "At Cloudflare, we're helping make a secure and post-quantum Internet accessible to everyone, without specialized hardware and at no extra cost to our customers." Third canonical instance of the default-on security upgrade at no additional cost pattern, after 2014 Universal SSL and 2022 TLS PQ-for-all.

  • Two-thirds of human-generated TLS traffic to Cloudflare is already PQ-encrypted (radar.cloudflare.com/post-quantum). IPsec's GA closes a site-to-site gap that TLS has been ahead on for four years.

  • TLS-first-PQC-rollout as an industry blueprint. The post articulates an implicit meta-pattern: when a crypto-protocol community converges early on a single hybrid construction (TLS 2019-2022), rollout is fast and the installed base benefits. When it doesn't converge (IPsec 2020-2025), deployment lags by years and customer-side interop regressions appear. Canonical rollout shape: TLS-first PQC rollout as blueprint.

Architectural mechanism

The hybrid ML-KEM IKEv2 handshake

IKEv2 initiator                            IKEv2 responder
─────────────────────────────────────────────────────────
(1) Classical DH exchange  ←─────────────→  Classical DH exchange
                                            ├─ derive key K_cl
(2) Encrypt second exchange with K_cl
    ML-KEM exchange        ←─────────────→  ML-KEM exchange
                                            ├─ derive key K_pq
(3) Both sides mix:
    session_keys = KDF(K_cl || K_pq || handshake_transcript)
(4) IPsec data plane uses session_keys
    via Encapsulating Security Payload (ESP)

The hybrid is one-directional-compromise-resistant: an adversary must break both the classical DH (requires CRQC for ECDLP) and the ML-KEM lattice-based construction. Neither half alone suffices.

Why draft-ietf-ipsecme-ikev2-mlkem fills RFC 9370's gap

RFC 9370 is the generic mechanism allowing up to seven key exchanges in parallel with classical DH in IPsec. draft-ietf-ipsecme- ikev2-mlkem is the concrete ciphersuite specification inside that mechanism — naming ML-KEM specifically as the parallel KEM and pinning its parameters. The former without the latter is what created the ciphersuite-bloat interoperability regression.

This is the standards- convergence-over-vendor-extension lesson at protocol level: extension points without named defaults fragment the installed base.

Systems extracted

Concepts extracted

Patterns extracted

Operational numbers

  • Two-thirds (>66 %) of human-generated TLS traffic to Cloudflare is already PQ-encrypted (via hybrid ML-KEM in TLS 1.3).
  • Four years: gap between TLS hybrid ML-KEM landing (2022) and IPsec hybrid ML-KEM full specification landing (late 2025).
  • Seven: maximum number of key exchanges RFC 9370 allows in parallel with classical Diffie-Hellman.
  • 2029: Cloudflare's target date for full post-quantum security across the product suite.

Caveats

  • No performance numbers disclosed. The post does not quote per-tunnel handshake latency, CPU overhead, or aggregate IPsec throughput impact from the PQ upgrade. TLS hybrid ML-KEM adds ~1 kB to the ClientHello and modest CPU; IPsec impact at the branch-connector altitude (with smaller MTU and more MTU-sensitive path characteristics) is unquantified here.
  • No customer migration numbers. Unlike the TLS rollout (>65 % of human traffic quantified via Cloudflare Radar), the IPsec PQ uptake rate is not disclosed — not surprising for a GA-day post.
  • Palo Alto Networks interop is the canonical non-interop case but Cloudflare frames this gently: "we hope to add Palo Alto Networks to the list of interoperable post-quantum branch connectors as the industry continues to consolidate around draft-ietf-ipsecme-ikev2-mlkem." No concrete timeline; PANW ciphersuite choices not named.
  • Post-quantum authentication explicitly deferred. IPsec standards for PQ signatures / PQ cert-based IKE auth are not yet drafted at the IETF; Cloudflare's IPsec PQ story is KEM-side only.
  • No discussion of FIPS-compliance implications for regulated customers. ML-KEM is FIPS 203 approved; classical DH groups in IKEv2 are FIPS-approved; the hybrid's FIPS status for government customers isn't discussed explicitly.
  • No discussion of per-tunnel key-rotation cadence or interaction with IKEv2 rekey events (CHILD_SA rekeys, IKE_SA rekeys).
  • Tier-1 launch-voice content. The post is 60 % architectural (handshake + RFC 9370 / draft-ietf-ipsecme-ikev2-mlkem contrast
  • QKD rejection rationale + interoperability story), ~25 % standards-community editorial (on why the community should not divert focus to QKD again), ~15 % product announcement (customer advocacy + branch-connector list). Architecture density is well above the Tier-1 include threshold.

Source

Last updated · 433 distilled / 1,256 read