Post-Quantum VPN Rekey Interval: How Often to Rekey?

A post-quantum VPN rekey interval is how often an encrypted tunnel throws away its session keys and agrees new ones through a key exchange that includes a quantum-resistant algorithm such as ML-KEM. Fresh keys only defend against future quantum decryption if each rekey actually runs that post-quantum exchange. Choosing the interval means weighing how much data each key exposes against handshake cost on the gateway.

For organizations running operational technology (OT) and critical infrastructure, the question matters for two reasons. Tunnels between substations, plants, control rooms and cloud environments often stay up for months. The data they carry, such as process recipes, network topology and engineering credentials, can stay sensitive for years. This article explains how rekeying works in IKEv2 with post-quantum extensions, what it protects against, what it doesn’t, and what it costs.

How do RFC 7296, RFC 9242 and RFC 9370 fit together?

RFC 7296 defines IKEv2 and its rekeying model. RFC 9242 adds the IKE_INTERMEDIATE exchange, and RFC 9370 uses it to run extra key exchanges such as ML-KEM, both at setup and during rekeys.

RFC 9370 says it utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established, and introduces a new IKEv2 exchange, IKE_FOLLOWUP_KE, which is used for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs. The framework has room to spare:

• Statistic: RFC 9370 allows up to 7 layers of additional KEMs alongside the original ECDH (IETF draft-wang-hybrid-kem-ikev2-frodo-01, 2024).

RFC 9370 is a framework, not a specific algorithm profile. The IETF IPSECME working group’s draft on ML-KEM describes how ML-KEM can be used as a quantum-resistant KEM in IKEv2 in an IKE_SA_INIT key exchange, or in one additional IKE_INTERMEDIATE or IKE_FOLLOWUP_KE key exchange. The algorithm itself is defined in NIST FIPS 203, which specifies three parameter sets for ML-KEM: in order of increasing security strength and decreasing performance, ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

How often should a quantum-safe IPsec tunnel rekey?

RFC 7296 leaves SA lifetimes to local policy, so the right interval is a risk decision, not a protocol constant. What matters is that every interval ends with a fresh hybrid key exchange. If a rekey skips the ML-KEM step, the interval adds no quantum resistance.

Think about the interval in two layers:

• IKE SA lifetime: the control channel. With RFC 9370, every IKE SA rekey runs all negotiated key exchanges again, ML-KEM included.
• Child SA lifetime: the keys that encrypt the actual traffic. This is where you choose whether each rekey brings fresh post-quantum key material.

For OT networks, three practical factors should set the numbers:

• Exposure window. Ask how much process or engineering data you would accept losing if one Child SA key leaked through a gateway compromise, a memory disclosure or a future break of one component algorithm. Shorter lifetimes shrink that window.
• Volume, not just time. Busy historian or video links should also rekey on a byte limit. Quiet telemetry links can use time limits alone.
• Link behaviour. Cellular, satellite and radio backhaul with high latency or packet loss need lifetimes long enough that rekeys don’t collide with link flaps. RFC 9370 spends considerable text on situations where, due to packet loss, one of the peers receives a request to rekey an SA that it is already rekeying itself.

Some purpose-built gateways go to the short end of the range. Quantum Network’s Quantum Gateway, for example, uses a hybrid key agreement that combines a classical part and an ML-KEM part into one session key, and renews both handshakes every two minutes. Short intervals like that are workable because, as the next sections show, the post-quantum part of a rekey costs little in compute. The harder limits are message size and how many tunnels a hub has to service.

Does perfect forward secrecy protect against harvest now, decrypt later?

Not if the forward secrecy comes only from classical Diffie-Hellman. An adversary who records traffic today and later has a cryptographically relevant quantum computer can solve each ephemeral elliptic-curve exchange one by one, so classical forward secrecy alone does not help.

Perfect forward secrecy protects against later theft of long-term keys. It guarantees that stealing a gateway’s authentication key does not unlock past sessions. Harvest now, decrypt later is a different threat model: the attacker doesn’t need any stored key, because they attack the recorded key exchange itself. Each classical ephemeral exchange is a separate target, but every one of them is breakable with a quantum computer.

Hybrid forward secrecy closes that gap. When each rekey includes a fresh ML-KEM exchange, the recorded traffic contains a lattice-based ciphertext that is believed to be secure, even against adversaries who possess a quantum computer. The ML-KEM draft for IKEv2 describes the goal as negotiating IKE and Child SA keys which are safe against cryptanalytically-relevant quantum computers and theoretical weaknesses in ML-KEM.

The timeline still matters for planning. Statistic: NIST IR 8547 proposes that quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030 and disallowed after 2035 (NIST, Dustin Moody, 2025). NIST’s guidance is that “organizations should begin migrating their systems to quantum-resistant cryptography.” OT data recorded today is the data most exposed to that window.

Does every IKEv2 child SA rekey need a fresh ML-KEM exchange?

The protocol does not require it, but your security policy should. RFC 9370 makes the key exchange optional for Child SA rekeys and mandatory for IKE SA rekeys. Child SA rekeys without one still use keys derived from a quantum-resistant IKE SA, but they lose fresh forward secrecy.

RFC 9370 states that when creating or rekeying Child SAs, the peers may optionally perform a key exchange to add a fresh entropy into the session keys. In the case of an IKE SA rekey, the key exchange is mandatory. The three cases behave differently:

A workable pattern for OT is to require the additional key exchange in Child SA proposals. If that is too expensive on a hub, keep Child SAs without a key exchange but rekey the IKE SA often. Once negotiated, the methods stay fixed: the IETF draft on optimized rekeys says that if multiple key exchange methods are used for an SA, then optimized rekey of this SA MUST use the same key exchange methods.

There is also a start-up subtlety. Under RFC 7296, the first Child SA is created inside IKE_AUTH and gets no key exchange of its own. The ML-KEM draft notes that to ensure data only travels over a quantum-resistant Child SA, peers could enforce a policy which first establishes a Childless IKE SA and creates protected Child SAs afterwards.

How does rekeying frequency affect CPU load on encryption gateways?

For a single tunnel, ML-KEM adds little CPU cost per rekey. The real costs are larger handshake messages, extra round trips and many tunnels rekeying at once on hub gateways.

Panos Kampanakis, author of the IETF ML-KEM draft for IKEv2, writes that the three ML-KEM parameter sets “will not have material performance impact on IKEv2/IPsec tunnels” because those tunnels usually stay up for long periods and carry large amounts of data. Lattice operations are fast. Message size is where the cost shows up:

Statistic: for all three parameter sets, the shared secret key is 32 bytes (IETF draft-sfluhrer-cfrg-ml-kem-security-considerations-04, 2025).

Every hybrid rekey therefore sends a few kilobytes and adds one IKE_FOLLOWUP_KE round trip for each additional method. On a hub that terminates hundreds of OT sites, the load depends on tunnels times rekey rate. Practical controls:

• Add jitter to lifetimes so tunnels brought up together after a maintenance window don’t all rekey in the same second.
• Size for recovery, not steady state. After a WAN outage, every tunnel renegotiates at once. Each rekey is cheap, but a full IKE_SA_INIT plus IKE_INTERMEDIATE plus authentication for every peer at the same moment is not.
• Use IKEv2 fragmentation (RFC 7383) where intermediate exchanges get close to the path MTU, especially on OT links with small MTUs.
• Keep symmetric costs separate. Payload encryption cost depends on throughput, not on the rekey interval.

Why is reusing ML-KEM key shares across sessions not allowed?

Reusing an ML-KEM key pair across exchanges throws away the forward secrecy that the rekey is meant to provide. Anyone who later obtains that one decapsulation key can recover the shared secret of every session that used it.

The reason is about protocol design, not a weakness in ML-KEM itself. ML-KEM is built to stay secure when one key pair receives many ciphertexts, which is why static KEM keys exist in other settings. In an IKEv2 rekey, however, the ML-KEM exchange is meant to be ephemeral. The IETF draft describes the flow as one where the initiator generates an ML-KEM keypair (sk, pk) using KeyGen(), and sends the public key (pk) to the responder for that exchange. On the responder side, FIPS 203 defines encapsulation as a process that accepts the encapsulation key as input, requires private randomness, and produces a shared secret key and an associated ciphertext.

If a gateway caches its ML-KEM key pair to save a key generation, three things go wrong:

• The decapsulation key becomes a long-lived secret sitting in memory, so one memory disclosure exposes every rekey that used it.
• The post-quantum half of the hybrid no longer gives forward secrecy, and the classical half doesn’t give it against a quantum adversary either.
• Rekeying more often stops being useful, because every “fresh” key depends on the same reused secret.

NIST SP 800-227, finalized in September 2025, provides recommendations for implementing and using KEMs in a secure manner, and guidelines for vendors who wish to securely combine keying material produced via approved post-quantum methods with keying material produced via other (potentially quantum-vulnerable) methods. When you evaluate gateways, ask the supplier directly whether ML-KEM key pairs are generated fresh for every exchange, including IKE_FOLLOWUP_KE rekeys.

What should OT teams check before setting their rekey policy?

Check that every rekey path runs a hybrid exchange, that lifetimes match how long your data stays sensitive, and that hub gateways can handle a simultaneous re-establishment after an outage.

• Confirm that Child SA proposals require the additional ML-KEM key exchange, and that the first Child SA doesn’t carry production traffic before a hybrid exchange has run.
• Test rekeys over your worst-case links (cellular, satellite, radio) with realistic packet loss and check for rekey collisions.
• Find out whether your gateways can change algorithms if ML-KEM guidance changes, and how algorithm updates reach air-gapped sites.
• Write down the chosen IKE SA and Child SA lifetimes along with the reason for them, so audits and later changes start from a clear baseline.

Protection against harvest now, decrypt later comes from making sure every rekey uses fresh post-quantum key material. How often you rekey is a separate choice about exposure and cost.