<p>Post-quantum VPN migration is not a single task. Enterprise VPN infrastructure spans three distinct protocol families, each with a different standardisation path, different integration mechanism for ML-KEM, and different maturity level in enterprise vendor implementations. The comparison below is for network security architects who already know migration is coming and want an honest picture of where the protocol ecosystem stands, which vendor versions actually support what, and how to structure an evaluation before the next infrastructure refresh cycle.</p>

<h2>How VPN protocols handle key exchange and where PQC fits</h2>

<p>Enterprise VPN deployments fall into three protocol categories with separate PQC migration paths. The differences are not cosmetic.</p>

<p>IPsec/IKEv2 is the dominant protocol for site-to-site and gateway VPNs. Key exchange uses the IKEv2 protocol with Diffie-Hellman groups specified in the IKE SA negotiation. PQC integration adds ML-KEM as a new DH transform type. The IETF IPSECME working group document draft-ietf-ipsecme-ikev2-ml-kem had reached RFC Editor stage as of knowledge cutoff August 2025. [ASSUMED: verify the current RFC number if published before relying on the draft identifier in procurement specifications.] IETF RFC 9242 (2022) addresses the intermediate exchange mechanism required to handle the larger message sizes that ML-KEM introduces in IKEv2. Hybrid mode, combining a classical DH group with ML-KEM, is supported in the IETF specification and is the recommended transition approach.</p>

<p>OpenVPN uses TLS 1.3 for control channel key exchange. PQC integration follows directly from TLS 1.3 post-quantum extensions, using hybrid key exchange constructions. OpenVPN 2.6 and later supports external key exchange plugins that can incorporate ML-KEM via the Open Quantum Safe liboqs-based oqs-provider for OpenSSL 3.x. This is not a standalone TLS plugin; it operates as an OpenSSL provider, meaning OpenVPN loads oqs-provider through its standard OpenSSL 3.x provider mechanism. In this configuration, OpenVPN uses X25519 with ML-KEM-768, matching RFC 9496 X-Wing or equivalent IETF hybrid constructions. This integration path is not a production-supported configuration from the OpenVPN project itself; it is a research and early-adoption path requiring the operator to build and maintain the oqs-provider integration. [ASSUMED: verify current OpenVPN documentation and oqs-provider compatibility matrix for the specific OpenVPN and OpenSSL 3.x version in your environment before any deployment decision.]</p>

<p>WireGuard operates differently from both. Its cryptographic design is static and hardcoded: Curve25519 for key exchange, ChaCha20-Poly1305 for symmetric encryption, BLAKE2s for hashing. The design explicitly excludes algorithm negotiation to eliminate downgrade attacks. That is a security property of WireGuard. It is also why PQC integration requires a protocol extension rather than a configuration parameter change. The Rosenpass project (Schmidt et al., 2023, IEEE S&amp;P) addresses this: Rosenpass runs a separate PQC key exchange alongside WireGuard, mixing the output into WireGuard's session key to produce a hybrid construction. The Rosenpass specification is published and formally verified. Enterprise management tooling for Rosenpass is not yet at the maturity level of the IPsec ecosystem.</p>

<p>The TLS 1.3 foundations that underpin both OpenVPN and web-based VPN gateways are covered in <a href="/insights/post-quantum-tls-what-changes-stays-same/">Post-Quantum TLS: What Changes and What Stays the Same</a>.</p>

<h2>Enterprise vendor comparison: Cisco, Palo Alto, Fortinet</h2>

<p>The status below reflects public vendor announcements and early release note disclosures as of knowledge cutoff August 2025. VPN product software changes frequently. Before any deployment decision, verify against the current release notes for the specific software version and hardware platform in your environment. Vendor announcements and production feature availability are not the same thing.</p>

<table>
  <thead>
    <tr>
      <th>Vendor</th>
      <th>Protocol</th>
      <th>PQC feature</th>
      <th>Software version</th>
      <th>Hybrid mode</th>
      <th>FIPS 140-3 PQC status</th>
      <th>Notes</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Cisco</td>
      <td>IPsec/IKEv2</td>
      <td>ML-KEM-768 and ML-KEM-1024 as IKEv2 key exchange methods</td>
      <td>IOS XE 17.13 (2024) [ASSUMED: verify exact version and platform support in current release notes]</td>
      <td>Supported (classical DH Group 19/20 + ML-KEM)</td>
      <td>Pending [ASSUMED: verify CMVP status]</td>
      <td>Verify feature flag availability per ASA/FTD platform; not all platforms run the same feature set simultaneously</td>
    </tr>
    <tr>
      <td>Palo Alto</td>
      <td>IPsec/IKEv2</td>
      <td>Hybrid post-quantum IKEv2 including GlobalProtect VPN</td>
      <td>PAN-OS 11.x [ASSUMED: verify specific version in current release notes]</td>
      <td>Supported</td>
      <td>Pending [ASSUMED: verify CMVP status]</td>
      <td>Confirm whether GlobalProtect (client VPN) and site-to-site are both supported in the same version</td>
    </tr>
    <tr>
      <td>Fortinet</td>
      <td>IPsec/IKEv2</td>
      <td>ML-KEM as IKEv2 phase 1 key exchange in FortiGate site-to-site</td>
      <td>FortiOS 7.6+ [ASSUMED: verify in current FortiOS release notes]</td>
      <td>Supported</td>
      <td>Pending [ASSUMED: verify CMVP status]</td>
      <td>Feature availability varies across FortiGate hardware models; check platform compatibility matrix</td>
    </tr>
  </tbody>
</table>

<p>The caveat in the Notes column for every vendor is operational, not cautionary boilerplate. Enterprise deployments routinely run software one to three major releases behind current. A network architect assessing PQC readiness across their VPN estate must check the deployed software version, not the vendor's most recent announcement. A vendor may have shipped ML-KEM support in its latest release while the deployed estate is two versions earlier with no PQC capability at all.</p>

<p>For the broader picture of post-quantum tunnel provider status, see <a href="/quantum-news/post-quantum-vpns-ml-kem-tunnel-providers/">Post-Quantum VPNs: ML-KEM Deployment Status Across Tunnel Providers</a>.</p>

<h2>Consumer and cloud VPN provider status: what enterprise architects can learn</h2>

<p>Enterprise architects should not deploy consumer VPN products in enterprise environments. This section is about what consumer VPN deployment experience tells us about protocol feasibility.</p>

<p>Cloudflare was an early adopter of post-quantum hybrid TLS, deploying a hybrid construction using Kyber768 (the draft algorithm that became ML-KEM) in its 1.1.1.1 DNS service and WARP VPN product in 2023. Following NIST finalisation of FIPS 203, Cloudflare has published intentions to migrate from the Kyber draft construction to ML-KEM-768 per the final standard. [ASSUMED: verify current WARP deployment status against Cloudflare's technical blog.] Cloudflare Research has published performance benchmarks for the hybrid key exchange: approximately 1 KB additional data in the TLS ClientHello, with negligible latency impact on modern server hardware. That figure is the most useful data point from consumer VPN experience for enterprise architects: hybrid ML-KEM-768 TLS is proven at internet scale, and the overhead is not a blocking concern for performance planning.</p>

<p>NordVPN has announced ML-KEM-768 hybrid deployment in its desktop and mobile applications, using a hybrid approach where both the classical IKEv2 and ML-KEM shared secrets are combined in session key material. [ASSUMED: verify current NordVPN implementation details and whether the feature is default or opt-in.] ExpressVPN had referenced post-quantum research in its communications but had not deployed a production ML-KEM implementation as of knowledge cutoff August 2025. [ASSUMED: verify current status.] Treated as a pattern rather than individual data points, the consumer VPN ecosystem shows ML-KEM-768 hybrid deployment at commercial scale is operationally feasible, which supports the case for enterprise IKEv2 hybrid deployment on purpose-built platforms.</p>

<h2>What to evaluate: the six-dimension enterprise VPN assessment</h2>

<p>For enterprise IPsec/IKEv2 site-to-site VPN assessment, the six dimensions that matter are:</p>

<ol>
  <li><strong>Protocol support.</strong> Does the deployed software version support ML-KEM as an IKEv2 transform type? Not the announced version. The version running in production today.</li>
  <li><strong>Hybrid mode.</strong> Is classical DH combined with ML-KEM hybrid mode supported? Which DH groups can be combined with which ML-KEM parameter sets? For CNSA 2.0 environments, the hybrid must use ML-KEM-1024; for commercial use, ML-KEM-768 applies.</li>
  <li><strong>FIPS 140-3 validation.</strong> Is the post-quantum module FIPS 140-3 validated, or is the validation pending? For US government environments, an unvalidated module is not a usable production option regardless of algorithmic correctness.</li>
  <li><strong>Interoperability.</strong> Has the vendor tested interoperability with other vendor implementations against the IETF IPSECME working group test vectors? Multi-vendor VPN estates, which are common in large organisations, need active interoperability testing. Individual vendor claims of compliance with the IETF draft are not equivalent to tested interoperability between two different vendors' implementations.</li>
  <li><strong>Performance at scale.</strong> What is the measured IKE handshake overhead with ML-KEM-768 or ML-KEM-1024 on the specific hardware platform, at the expected number of concurrent tunnels? The Cloudflare performance data on TLS hybrid overhead is a useful reference, but enterprise gateway hardware processing thousands of concurrent IPsec SAs is a different workload profile than TLS at an internet edge.</li>
  <li><strong>Management plane.</strong> Does the VPN management console support configuring PQC algorithm selection per tunnel? An environment where hybrid ML-KEM is enabled globally but cannot be scoped to specific tunnels or peer groups creates operational management complexity during phased rollout.</li>
</ol>

<p>WireGuard with Rosenpass is technically sound but operationally immature for most enterprises. The Rosenpass protocol has been formally verified by Girol et al. (2023) and the tooling is actively maintained. Central key management, monitoring integration, and policy enforcement tooling for Rosenpass is not yet comparable to what the IPsec ecosystem provides. If WireGuard is part of your environment, evaluate Rosenpass in a pilot context before committing to enterprise-wide deployment. The protocol works; the enterprise management layer is the open question.</p>

<h2>A practical starting point: assessing what you currently run</h2>

<p>Before evaluating vendor roadmaps, a network architect needs an accurate picture of their current VPN estate. Three questions produce the information that makes everything else tractable.</p>

<p>First: which VPN software version is actually running in production across each site-to-site tunnel group and each client VPN gateway? Not the version in the procurement contract. The version returned by the management console today. Organisations that have not refreshed VPN firmware in 18 months or more are likely running versions that pre-date any vendor's post-quantum feature releases, regardless of what the vendor's current product sheet shows.</p>

<p>Second: which key exchange algorithm is in use per tunnel? IPsec IKEv2 SA logs record the negotiated DH group. If your estate shows DH Group 2 (modular exponential 1024-bit) or DH Group 14 (2048-bit MODP) in production tunnels, the first migration objective is not PQC but moving to ECDH Group 19 or 20. Deploying ML-KEM hybrid on top of weak classical groups is poor ordering. The classical component should be Group 19 (P-256) or Group 20 (P-384) before adding ML-KEM. Groups 19 and 20 are already mandated under CNSA 1.0 for NSS environments; their absence in commercial VPN estates is common.</p>

<p>Third: is there a multi-vendor boundary in the VPN estate? Site-to-site tunnels between a Cisco endpoint and a Fortinet endpoint require interoperability testing specifically for the PQC key exchange negotiation, not just for the standard IKEv2 base protocol. Identifying multi-vendor boundaries before beginning PQC deployment lets the interoperability testing be planned as a programme task rather than discovered as a production incident.</p>

<p>These three questions can be answered from existing management console data and IKEv2 SA logs without any new tooling. The answers determine whether the PQC migration is a near-term configuration change or a multi-phase firmware and renegotiation programme.</p>

<h2>Deployment timeline: when you must act</h2>

<p>NIST IR 8547 (November 2024) specifies that RSA and ECDH are deprecated for new use from 2030. For VPN infrastructure, that means new VPN deployments from 2030 must use PQC or hybrid PQC key exchange. Existing deployments must complete migration by 2035. Both dates carry weight for network architects planning infrastructure.</p>

<p>The operational implication is straightforward but frequently missed. Most enterprise network infrastructure runs on refresh cycles of three to five years. A network architect planning a VPN infrastructure refresh now who does not specify PQC-capable platforms as a mandatory requirement is locking in quantum-vulnerable infrastructure for another five years, taking the estate to 2031 or later on non-compliant kit. The 2030 new-use deadline will already have passed by the time that refresh cycle ends. The specification conversation is not something to defer to the next procurement cycle. It is a requirement for the current one.</p>

<p>For organisations in scope for CNSA 2.0, the timeline is tighter: the software and network device category begin-transition date was 2025. If your NSS-category VPN infrastructure has not begun transition, the NSA timeline is already behind you.</p>