Post-Quantum VPN Migration: IPsec, TLS VPNs, and Remote Access

Quick answer: Post-quantum VPN migration has two distinct starting points depending on what your appliance supports today. RFC 8784 lets you mix a post-quantum pre-shared key into IKEv2 key derivation without any new key exchange algorithm, a low-effort first step available on many current-generation firewalls already. RFC 9370, building on RFC 9242’s Intermediate Exchange, adds genuine hybrid post-quantum key exchange to IKEv2 itself. TLS-based remote access VPNs inherit the same hybrid key exchange (X25519MLKEM768) already deploying across browsers and CDNs. The real constraint across both paths is firmware: treat your appliance’s specific product version as a hard dependency, and validate interoperability on the exact peer combination you run, not just the vendor’s general roadmap.

VPN migration gets less attention than TLS migration in most PQC planning, which is a mistake given how much long-lived, sensitive traffic runs over IPsec and TLS VPN tunnels. Unlike a web server, a VPN appliance is usually not something you can patch by pushing a new build; it is a hard firmware dependency, often controlled by a vendor release schedule you do not control, sitting on both ends of a tunnel that also has to interoperate. This guide covers the protocols, the appliance readiness question, and a phased rollout approach.

Key Takeaways

• RFC 8784 (post-quantum pre-shared keys) is the lowest-effort first step for IKEv2 VPNs, requiring no new key exchange algorithm, just a pre-shared key mixed into the existing derivation.
• RFC 9370, built on RFC 9242’s Intermediate Exchange, adds genuine hybrid post-quantum key exchange to IKEv2, combining a classical exchange with one or more post-quantum KEMs.
• TLS-based remote access VPNs inherit hybrid key exchange support from the underlying TLS stack, following the same X25519MLKEM768 deployment pattern as browser and CDN traffic.
• Firmware and product version are a hard dependency for VPN appliances, not a configuration toggle; vendor support announcements and actual deployment readiness are two separate questions.
• CISA’s quantum-readiness guidance treats vendor engagement and interoperability validation as core parts of the migration roadmap, not an afterthought.

IPsec Key Exchange: Two Paths, Different Effort

IKEv2 has two distinct standards-track paths to post-quantum resistance, and they are not mutually exclusive.

RFC 8784, post-quantum pre-shared keys, mixes a symmetric pre-shared key, distributed out of band, into the IKEv2 key derivation alongside the existing classical exchange. It requires no new asymmetric algorithm and no significant change to the IKEv2 negotiation itself, which is why it is often the first capability appliances ship and the fastest path to some quantum resistance on infrastructure that already supports it.

RFC 9370, multiple key exchanges in IKEv2, is the more complete answer: it extends the protocol to carry one or more additional key exchanges, typically a post-quantum KEM like ML-KEM, alongside the classical exchange, using a cascaded key derivation approach. Because the original IKE_SA_INIT exchange could not fragment large key material, RFC 9242 first introduced an “Intermediate Exchange” specifically so RFC 9370 could carry the larger post-quantum key material after the initial handshake, where fragmentation is available. This is the path that produces a genuine hybrid key exchange, not just an additional pre-shared secret.

TLS VPNs: Inheriting the Same Hybrid Key Exchange

TLS-based remote access VPNs sit on the same TLS 1.3 stack as any other TLS-terminating service, which means they inherit hybrid post-quantum key exchange the same way a web server does: through the underlying TLS library’s support for the X25519MLKEM768 group, covered in depth in our X25519MLKEM768 deployment guide. The negotiation mechanics, compatibility risks, and testing approach in that guide apply directly to a TLS VPN gateway, with one addition: VPN client software, not just browsers, needs to support the hybrid group, and client update cycles for VPN software are often slower than browser auto-update cycles.

Appliance Readiness: Vendor Support Is Not Deployment Readiness

A vendor announcing post-quantum support in a roadmap or press release is not the same as that support being available, tested, and stable on the specific product version running in your environment. Treat firmware and product version as a hard, explicit dependency in your migration plan: identify the exact minimum version that supports the key exchange method you intend to use, confirm it against your currently deployed version, and budget the upgrade cycle as part of the migration timeline rather than assuming it happens automatically.

Interoperability validation matters as much as version support. Post-quantum IKEv2 support from two different vendors, or even two different product lines from the same vendor, is not guaranteed to negotiate cleanly with each other on day one. Validate the exact peer combination you actually run, client to concentrator, site to site, rather than assuming general standards compliance guarantees interoperability.

Client Compatibility

Remote access VPN client software carries its own compatibility question, separate from the gateway or concentrator. A VPN gateway that supports hybrid key exchange does not help if the client application connecting to it, whether a dedicated VPN client or a browser-based TLS VPN portal, does not. Inventory client software versions across your remote workforce with the same rigor as gateway firmware, since a mixed fleet of updated and outdated clients is the realistic starting condition for most enterprise rollouts, not a clean cutover.

A Phased Rollout Approach

1. Baseline and inventory: confirm every VPN gateway, concentrator, and client’s current firmware or software version and its documented post-quantum capability, before changing any configuration.
2. Modernize the classical baseline first: ensure strong classical cryptography and current protocol versions are already in place; post-quantum capability builds on top of a modern baseline, not a legacy one.
3. Start with RFC 8784 where available: post-quantum pre-shared keys offer meaningful protection against harvest-now-decrypt-later with minimal protocol risk, a reasonable first step while broader hybrid key exchange support matures.
4. Pilot RFC 9370 hybrid key exchange on a non-critical tunnel: validate interoperability on the exact peer combination before touching production traffic.
5. Decide explicitly on classical fallback behavior: determine whether a peer that cannot negotiate post-quantum key exchange should be allowed to connect with classical-only cryptography or rejected outright, and document that decision rather than leaving it as an implicit default.
6. Log and monitor negotiated algorithms: track which key exchange method each tunnel actually negotiates in production, so a silent fallback to classical-only shows up as a metric, not a surprise during an audit.

What We’d Actually Recommend

Start with RFC 8784 pre-shared keys on infrastructure that already supports it, since it delivers real protection against harvest-now-decrypt-later with the lowest implementation risk of any current option. Build your firmware and client version inventory before committing to a hybrid key exchange rollout timeline, and treat vendor roadmap announcements as a planning input, not a deployment date. Pilot RFC 9370 hybrid key exchange on a single, non-critical tunnel first, and validate the exact peer combination rather than trusting general standards compliance.

How Encryption Consulting Can Help

The phased rollout above depends entirely on an accurate inventory of VPN gateway firmware, client software versions, and tunnel configurations across your environment, exactly the kind of discovery gap that stalls most migration plans before they start. CBOM Secure builds and maintains that inventory, mapping every VPN endpoint to its current version and post-quantum capability so the migration plan starts from real data.

Where the ML-KEM key operations themselves need to run on FIPS-validated hardware, HSM-as-a-Service supports the RFC 9370 hybrid exchange without a separate hardware procurement cycle per gateway. Our PQC Advisory Services sequence the firmware upgrade cycle, interoperability validation, and phased rollout described above around your specific appliance mix and tunnel topology, so vendor roadmap timing gets translated into an actual, tested migration plan rather than an assumption.

Firmware Is the Real Migration Timeline

Post-quantum VPN migration is less an algorithm question than a firmware and interoperability question. RFC 8784 offers a genuinely low-effort first step, RFC 9370 offers the complete hybrid answer, and TLS VPNs inherit the same protections web traffic already gets. What actually paces the migration is whether your specific appliance version, on both ends of every tunnel, supports and correctly interoperates on the method you choose, which is why the inventory and interoperability validation steps matter more than the protocol selection itself.

Frequently Asked Questions

What is the fastest way to add post-quantum protection to an existing IKEv2 VPN?

RFC 8784, post-quantum pre-shared keys. It requires no new key exchange algorithm, only a pre-shared key mixed into the existing IKEv2 derivation, and is available on many current-generation appliances already.

What is the difference between RFC 8784 and RFC 9370?

RFC 8784 mixes a symmetric pre-shared key into IKEv2’s existing key derivation without a new algorithm. RFC 9370 adds genuine hybrid post-quantum key exchange, combining the classical exchange with one or more post-quantum KEMs like ML-KEM, and requires RFC 9242’s Intermediate Exchange to carry the larger key material.

Do TLS-based remote access VPNs need separate post-quantum work from IPsec VPNs?

They inherit hybrid key exchange from the underlying TLS 1.3 stack, following the same X25519MLKEM768 pattern as any TLS service, but VPN client software specifically needs to support the hybrid group, and client update cycles are often slower than browser update cycles, so this needs its own compatibility check.

Is vendor support for post-quantum VPN features the same as being ready to deploy?

No. A vendor roadmap announcement is a planning input, not a deployment date. Confirm the specific firmware or product version running in your environment actually supports and has been validated for the key exchange method you intend to use before building a rollout timeline around it.

Should classical-only peers be allowed to connect once post-quantum key exchange is deployed?

That should be an explicit, documented decision rather than a default. Determine and document whether a peer that cannot negotiate post-quantum key exchange should still be allowed to connect with classical-only cryptography or should be rejected, and log negotiated algorithms in production so the actual behavior is visible.