Is IPsec quantum-safe? A quantum-safe VPN with ML-KEM and IKEv2, explained

An IPsec VPN does two separate jobs.

1. It agrees a key. IKEv2 runs a Diffie-Hellman or elliptic-curve Diffie-Hellman exchange so both ends get the same secret. The peers prove who they are with certificates or pre-shared keys.
2. It encrypts the data. ESP then encrypts each packet with a symmetric cipher such as AES-GCM.

A large quantum computer running Shor's algorithm could break RSA, Diffie-Hellman and elliptic-curve cryptography. That puts step 1 at risk. Symmetric ciphers are in a much better position. The US NSA's CNSA 2.0 suite keeps AES-256 for encryption and adds ML-KEM-1024 for key establishment.

So "is IPsec quantum-safe?" is really a question about the handshake. If an attacker can recover the key exchange, AES-256 does not help, because they can derive the session keys.

No one needs a quantum computer today to attack today's traffic. An adversary can record encrypted IPsec sessions now and store them. When a cryptographically relevant quantum computer exists, they break the recorded key exchange and read the data.

That is harvest now, decrypt later. The question for you is not "when will quantum computers arrive?" It is "how long must this traffic stay secret?" Branch-to-DC traffic in a bank carries account data, credentials and transaction records. ATM tunnels carry payment data. Government WANs carry records with long classification periods. If that data must stay confidential for ten years, the tunnels need post-quantum key exchange now.

Timelines are firming up. NIST's draft transition report, NIST IR 8547 (initial public draft, November 2024), proposes deprecating quantum-vulnerable algorithms such as RSA and ECDH at the 112-bit security level after 2030, and disallowing them entirely after 2035. In India, DST's May 2026 roadmap sets milestones for critical information infrastructure from 31 December 2027. We cover the Indian dates in post-quantum cryptography in India: DST roadmap milestones.

The IETF did not replace IKEv2. It extended it in three steps.

Step 1: carry bigger keys (RFC 9242). ML-KEM keys are far larger than elliptic-curve keys. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1,184 bytes and its ciphertext is 1,088 bytes. IKEv2 cannot fragment its first message, IKE_SA_INIT, so large keys there risk IP fragmentation and dropped packets. RFC 9242 adds an IKE_INTERMEDIATE exchange between IKE_SA_INIT and IKE_AUTH, where IKE fragmentation works.

Step 2: allow more than one key exchange (RFC 9370). RFC 9370 lets peers negotiate up to seven additional key exchanges on top of the first one. They run in IKE_INTERMEDIATE messages when the tunnel is built, and in a new IKE_FOLLOWUP_KE exchange when it is re-keyed. Every shared secret feeds the final keys.

Step 3: define ML-KEM as a key exchange method (the ML-KEM draft). draft-ietf-ipsecme-ikev2-mlkem defines ML-KEM-512, ML-KEM-768 and ML-KEM-1024 for IKEv2. It allows ML-KEM on its own or as an additional key exchange alongside a traditional one. As of 30 September 2026, version 09 (5 July 2026) has passed IESG review and is in the RFC Editor queue. It is not yet a published RFC.

Production IPsec implementations with RFC 9370 and ML-KEM support have been available since late 2024, so this is no longer a research topic.

A hybrid tunnel runs a classical exchange (such as ECDH) and an ML-KEM exchange in the same handshake, then combines both secrets. An attacker must break both to read the traffic.

Hybrid is the sensible default for now. ML-KEM is new. Classical ECDH is well studied. Hybrid keeps today's protection in place while adding quantum resistance. In IKEv2 the usual pattern is a classical exchange in IKE_SA_INIT, then ML-KEM in an IKE_INTERMEDIATE exchange.

IKEv1 has no IKE_INTERMEDIATE exchange and no way to negotiate additional key exchanges. RFC 9395 moved IKEv1 to Historic in April 2023 and notes that no new algorithms have been accepted for it in over a decade. If any of your tunnels still use IKEv1, often to old third-party gateways, list them now. They must move to IKEv2 before they can become post-quantum.

Key exchange protects against harvest-now, decrypt-later. Authentication protects against impersonation, which only becomes possible once a quantum computer exists. That makes it less urgent, but certificate lifetimes and device lifetimes are long, so plan it now. ML-DSA (FIPS 204) is the main post-quantum signature. The IETF draft for post-quantum signatures in IKEv2 is also in the RFC Editor queue.

As described on our post-quantum cryptography page:

• Key exchange: every IKEv2 tunnel uses hybrid classical + ML-KEM key exchange (FIPS 203). This covers SD-WAN, Instaroute routers, SSE and management-plane tunnels. Tunnels re-key with the same hybrid method.
• Authentication: ML-DSA (FIPS 204) certificates, issued through the Nexapp PKI, for IKEv2 and TLS peer authentication.
• Firmware and configuration: NexappOS firmware and configuration are signed with a post-quantum signature.
• TLS: X25519MLKEM768 in TLS 1.3 on consoles, APIs and SSE inspection.
• Visibility: the controller shows which tunnels use post-quantum protection, and a cryptographic bill of materials (CBOM) lists every algorithm in use.
• Crypto-agility: algorithms can be switched by policy as standards change.
• Status: generally available, with post-quantum mode on by default.

The same protection runs from an entry-level 4G router at an ATM to the data centre hub. NGFW VPN tunnels use it too.

ML-KEM adds bytes to the handshake, not to each packet. The extra kilobytes travel when a tunnel comes up or re-keys. After that, ESP encrypts data with the same symmetric cipher as before, so throughput on the data path is not affected by the key exchange choice. On lossy 4G links, fragmentation support in IKE_INTERMEDIATE is what keeps the larger handshake reliable.