What changes, and what does not
It helps to be precise about the blast radius, because the change is smaller than most stakeholders assume and its failure modes are stranger than they expect.
Changes:
- The IKEv2 negotiation gains one or more additional key exchanges, carried in the IKE_INTERMEDIATE exchange defined by RFC 9242.
- The IKE SA's derived keys now depend on both the classical and the post-quantum exchange.
- IKE message sizes increase, in some cases substantially.
- SA establishment takes additional round trips.
Does not change:
- Peer authentication. The certificate or preshared key in use before the change is still in use after it.
- The IPsec data-plane ciphers protecting the traffic itself.
- Routing, policy, NAT behaviour or anything above the tunnel.
- Throughput in steady state. The cost is in the handshake, not in the data plane.
That last pairing is the one to communicate upward. The change is confined to how the tunnel agrees its keys. It does not touch what the tunnel carries or how traffic reaches it.
The two mechanisms, and why the choice matters
There are two ways to get post-quantum resistance into IKEv2, and they have very different operational profiles.
RFC 9370 additional key exchanges. A post-quantum key exchange is negotiated in-protocol alongside the classical one. No out-of-band key material. This scales: adding a peer costs nothing beyond the configuration on both ends.
RFC 8784 preshared key mixing. An out-of-band post-quantum preshared key is mixed into the derived keys. The RFC describes itself as an interim measure for exactly this reason: it was published in June 2020, before negotiated post-quantum key exchange was realistic. It works on older platforms.
The scaling difference is the decision driver. RFC 8784 requires a distinct high-entropy key per peer pair, distributed out of band and rotated on a schedule. For an estate with ten tunnels, that is an afternoon of work and a calendar reminder. For an estate with two hundred peer relationships, it is a key management programme with an owner, a rotation process and an audit trail — and if that programme is not funded, the mechanism decays into a set of keys nobody has rotated since installation, which is worse than useless because it is believed to be working.
RFC 8784 also has a stated scope limit: it protects SK_d and keys derived from it, while identities, notifications and vendor IDs exchanged during initial IKE SA setup remain exposed to a future quantum adversary.
Operational costs to plan for
Message size and fragmentation. Post-quantum public keys and ciphertexts are much larger than elliptic curve equivalents. IKE messages grow accordingly. On paths with reduced MTU, or across a device that mishandles IP fragments, the symptom is intermittent tunnel establishment — it works from the lab and fails from one branch site. Confirm IKE fragmentation support on both peers before the wave, and test from the constrained path rather than from the datacentre.
Round trips. The intermediate exchange adds round trips. On a satellite or high-latency path this lengthens establishment noticeably. It matters most during failover, when a slower re-establishment extends the outage.
Rekey behaviour. RFC 9370 defines IKE_FOLLOWUP_KE for rekeying and for creating additional Child SAs. A tunnel can establish perfectly and then fail on its first rekey, hours after the change window closed. Set the rekey interval short on the canary tunnel so this surfaces during the test, not at three in the morning.
Both peers, every time. There is no unilateral change. Every tunnel is a two-party coordination, and the tunnels whose second party is another company are the ones that set the programme timeline. Start those conversations first — see migrating partner-controlled VPN tunnels.
The failure mode that does not alert
This is worth stating on its own, because it is the one that gets missed.
If the configured proposal still contains a classical-only option, and the peer does not offer the post-quantum option, the negotiation succeeds. The tunnel establishes. Traffic flows. Monitoring is green. The migration is recorded as complete, and the tunnel is exactly as vulnerable as it was before.
Nothing in the estate will tell you this happened. The only way to know is to read the negotiated key exchange method from the established security association on both peers. See verifying a post-quantum VPN migration.
Limitations
This guide describes protocol behaviour and its operational consequences. It makes no claim about which products implement either mechanism at which release; that is recorded per product in the compatibility matrix. It assumes IKEv2 throughout — neither mechanism exists for IKEv1.