How to migrate IPsec VPN to post-quantum without downtime

Migrating an IPsec VPN to post-quantum without downtime means adding an ML-KEM key exchange to existing IKEv2 tunnels as an extra, negotiated step. Upgraded peers derive hybrid keys, while peers that have not been upgraded yet keep working on classical Diffie-Hellman. Once every site has switched, the classical-only fallback is removed.

For OT and critical infrastructure operators this approach matters because a substation, pumping station or production line cannot accept an unplanned outage just because a cryptographic change went wrong. This article walks through the protocol mechanics, the upgrade order, rollback and verification, based on the relevant IETF and NIST documents.

Why do IPsec tunnels in OT networks need post-quantum key exchange now?

Classical IKEv2 key exchange (finite-field or elliptic-curve Diffie-Hellman) is quantum-vulnerable, and published timelines for retiring it are already in place. For OT data with long confidentiality lifetimes, such as process recipes, grid topology and safety system configurations, recorded traffic remains exposed until the key exchange itself changes.

The standards baseline is settled enough to act on. FIPS 203, published August 13, 2024, specifies a key-encapsulation mechanism called ML-KEM. In its own words, NIST says: “Organizations should begin applying these standards now to migrate their systems to quantum-resistant cryptography.”

Can post-quantum and classical IKEv2 peers coexist during migration?

Yes. RFC 9370 was designed so that a hybrid-capable peer can offer post-quantum key exchange and still fall back cleanly to classical-only proposals when the other side does not support it. Coexistence comes from standard IKEv2 proposal negotiation, not from any special compatibility mode.

How the negotiation works

RFC 9370, published in May 2023 as a Standards Track document, updates RFC 7296, the base IKEv2 specification. Multiple key exchanges are negotiated using the standard IKEv2 mechanism via the SA payload, and seven new transform types are defined, starting with Additional Key Exchange 1 (ADDKE1) with IANA-assigned value 6. The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange.

In practice, the classical ECDH group stays in the familiar Key Exchange Method transform in IKE_SA_INIT, and ML-KEM goes into ADDKE1. The result is a hybrid: both shared secrets feed into the IKE and Child SA keys. draft-ietf-ipsecme-ikev2-mlkem defines the concrete ML-KEM usage. Its author, Panos Kampanakis, summarises the scope: “This draft specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange.”

Making coexistence explicit in policy

A peer that does not support RFC 9370 will consider a proposal with an unknown transform type unacceptable, as RFC 7296 requires. That is why a migrating initiator should send two proposals: a hybrid one first (ECDH plus ADDKE1 = ML-KEM), and a classical one second. Upgraded responders select the first proposal, and legacy responders select the second. RFC 9370 also allows NONE as a value in an ADDKE transform, which marks the additional exchange as optional within a single proposal. Separate proposals are easier to read in logs, though.

How do I migrate an existing IPsec site-to-site VPN to hybrid ML-KEM step by step?

Inventory first. Then enable hybrid key exchange alongside the existing classical proposals, prove it on a pilot link, roll it out per peer, and only remove the classical fallback once verification passes. Each step should be reversible on its own.

Step 1: Inventory peers and capabilities

For every tunnel, list the IKE version, current DH group, authentication method, and whether the firmware supports RFC 9242 (IKE_INTERMEDIATE), RFC 9370 and ML-KEM per draft-ietf-ipsecme-ikev2-mlkem. Note which draft revision each vendor implements: the document is still evolving, and the transform IDs must match on both ends. IKEv1 tunnels have to move to IKEv2 first, because hybrid key exchange is only defined for IKEv2.

Step 2: Check the transport path for larger messages

ML-KEM values are much larger than ECDH values. ML-KEM-768 requires 1,184 bytes for the public key and 1,088 bytes for the ciphertext. Over cellular backhaul, satellite links or industrial firewalls that drop IP fragments, this is the most common cause of failed migrations. Enable IKEv2 message fragmentation (RFC 7383) on both peers and test the actual path MTU before the change window.

Step 3: Choose one parameter set

FIPS 203 specifies three parameter sets; in order of increasing security strength and decreasing performance, these are ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Standardise on one of them across the estate (ML-KEM-768 is the usual hybrid choice), so you do not have to troubleshoot proposal mismatches site by site.

Step 4: Add the hybrid proposal without removing the classical one

Configure the hybrid proposal with higher priority and keep the existing classical proposal unchanged. Existing SAs are not affected until they rekey, so traffic keeps flowing while the new policy loads.

Step 5: Rekey deliberately and verify

Trigger a rekey of the IKE SA in a maintenance window instead of waiting for the lifetime to expire, then confirm the result (see the verification section below). With make-before-break rekeying, the new SA is established before the old one is deleted, so the rekey itself causes no gap.

Step 6: Tighten to hybrid-only per peer

Once a peer is verified, remove its classical proposal. To ensure that data is encrypted over a quantum-resistant IPsec Child SA, the peers could enforce a policy which first establishes a Childless IKE SA (or a Child SA which does not encrypt any data) with a traditional key exchange and without an IKE_INTERMEDIATE exchange, according to the draft’s security considerations. Strict policies are the simpler option where both ends support hybrid.

In which order should hub and spoke sites be upgraded to quantum-safe IPsec?

Upgrade the hub first, in permissive mode, so it can accept both hybrid and classical proposals. After that, move spokes from least to most operationally critical. Switch the hub to strict mode per peer only after each spoke has been verified.

Upgrading spokes first does not work when the hub is the responder: a hybrid-first spoke would simply fall back to classical, which looks successful but changes nothing. In full-mesh or dual-hub designs, upgrade both hubs before any spoke, otherwise the security level of a failover path will quietly depend on which hub is active.

How do I roll back a post-quantum IPsec change if an OT site loses connectivity?

Plan the rollback before the change: keep an out-of-band management path to the remote device, stage the previous configuration on the device, and use an automatic revert timer. That way a site that becomes unreachable restores itself without anyone having to drive out.

• Out-of-band access. A cellular modem, serial console server or separate management tunnel that does not depend on the IPsec SA being changed.
• Commit-confirm or revert timer. If the change is not confirmed within, say, ten minutes, the device reloads the previous configuration.
• Change one end at a time. Because the hub stays permissive, reverting a spoke to classical-only always produces a working tunnel. Never change the hub and a critical spoke in the same window.
• Know the failure signatures. IKE_SA_INIT succeeds but IKE_INTERMEDIATE times out: suspect fragmentation or MTU. NO_PROPOSAL_CHOSEN: suspect a transform ID mismatch between draft revisions. DPD failures after rekey: suspect a middlebox dropping large UDP 4500 packets.
• Align with operations. Schedule critical OT spokes in planned production stops, and agree in advance with the plant operator on the maximum tolerable outage.

Expect migration to take longer than the technical change itself. The Dutch NCSC warns that “Migration can take a long time even with a single encryption standard.”

How do I verify that a tunnel actually negotiated ML-KEM after migration?

Don’t rely on the configuration; confirm the result through three independent kinds of evidence. The SA state should show an additional key exchange, a capture should show IKE_INTERMEDIATE messages, and the result should hold after the next rekey.

1. SA state on both peers

The IKE SA details should list the classical group and an additional key exchange identified as ML-KEM, with the parameter set. Check both ends: a mismatch in how the two peers report the SA points to a fallback.

2. Packet capture of the IKE exchange

A hybrid setup shows IKE_SA_INIT followed by an encrypted IKE_INTERMEDIATE exchange before IKE_AUTH. The IKE_SA_INIT response must include the INTERMEDIATE_EXCHANGE_SUPPORTED notification. If IKE_SA_INIT goes directly to IKE_AUTH, the tunnel is classical-only, however the configuration reads. Unusually large IKE messages or fragments are another sign that ML-KEM material was exchanged.

3. Behaviour on rekey

RFC 9370 also introduces IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. If Child SAs use PFS, check that rekeys include IKE_FOLLOWUP_KE. Otherwise, the next Child SA keys may depend on classical key exchange only.

What if existing VPN equipment cannot be upgraded to hybrid IKEv2?

Some OT sites run VPN equipment that will never get RFC 9370 support. For those paths, an alternative is a separate quantum-safe encryption layer next to the existing network, rather than replacing the equipment.

One example is Quantum Network’s Quantum Gateway, which goes in at each end of a connection and encrypts at Layer 3. It is integrated by adding or adapting a few routes and coexists with existing firewalls and routers. Its key agreement combines a classical part and ML-KEM (FIPS 203) into one session key, with both handshakes renewed every two minutes. The same migration discipline still applies: pilot first, keep the existing path available as a fallback during cut-over, and verify before you remove it.