Post-Quantum VPNs Explained: What ML-KEM Does Inside a VPN Tunnel and Which Providers Have Shipped It

The threat to VPN security from quantum computing is not that a quantum computer decrypts your traffic today. It is that someone is collecting it now. An adversary with access to network infrastructure can capture encrypted VPN sessions and store them. When a cryptographically relevant quantum computer (CRQC) becomes available, those sessions become readable. For traffic carrying information with a sensitivity window longer than the CRQC arrival timeline, the exposure window is already open.

This article works through how a VPN tunnel uses public-key cryptography, which layer is actually vulnerable, what hybrid post-quantum key exchange does to address it, and which providers have shipped production implementations. The Cloudflare measurement data on real-world performance overhead follows — the "post-quantum VPNs are slow" claim deserves a precise answer, not a vague one.

How a VPN Handshake Establishes a Shared Key

A VPN connection begins with a handshake. The client and server need to establish a shared symmetric key for encrypting tunnel traffic — without transmitting that key across the network. In TLS 1.3, this uses an ephemeral Diffie-Hellman key exchange, typically X25519 (Curve25519). In WireGuard, it uses the Noise_IK protocol framework with Curve25519 for key agreement. In both cases, the asymmetric operation occurs once per session. Everything after that — the bulk data transfer — uses a symmetric cipher, most commonly AES-256-GCM or ChaCha20-Poly1305.

The quantum vulnerability is in the handshake, not the bulk encryption. AES-256-GCM is not broken by a CRQC in the same way. Grover's algorithm provides a quadratic speedup against symmetric ciphers, effectively halving the security level; AES-256 provides roughly 128-bit security against a quantum adversary, which NIST and NSA assess as sufficient for the foreseeable future (NIST IR 8547 Initial Public Draft, 2024; NSA CNSA 2.0, September 2022). The session key establishment — the handshake — is the target.

Curve25519 is an elliptic-curve algorithm. Its security rests on the discrete logarithm problem over that curve. Shor's algorithm, published in 1994, solves the elliptic-curve discrete logarithm in polynomial time on a quantum computer. A CRQC running Shor's algorithm against a recorded WireGuard or TLS handshake can recover the session key from the public key material exchanged during the handshake. The recorded session is then fully readable (Shor, P.W., SIAM Journal on Computing, 1997).

That is the harvest-now-decrypt-later (HNDL) threat applied to VPNs. The Mosca inequality provides a framework for assessing whether this is relevant to your traffic: if the time your data must remain confidential plus the time to complete your PQC migration exceeds the time until a CRQC exists, you have an exposure problem now (Mosca and Piani, "2023 Quantum Threat Timeline Report," Global Risk Institute, January 2024). For corporate VPN traffic carrying long-lived sensitive data — negotiated contracts, client records, classified communications — that calculation is worth doing explicitly, not estimated.

Assess your organisation's HNDL exposure with the Quantum Threat Exposure Assessment at QSECDEF, which scores your quantum cryptographic exposure including your Mosca parameters.

What Hybrid Key Exchange Does

A hybrid key exchange runs a classical and a post-quantum key agreement algorithm in the same handshake. The session key is derived from both outputs, typically by concatenating the two shared secrets and hashing the result. The security consequence is that an attacker must break both algorithms simultaneously to recover the session key. The classical component (X25519) protects against current adversaries. The post-quantum component (ML-KEM) protects against future CRQCs. If a flaw is later discovered in ML-KEM, the classical algorithm provides a backstop. This is the construction specified in IETF draft-ietf-tls-hybrid-design, the active Internet-Draft governing hybrid key exchange in TLS 1.3.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as FIPS 203 by NIST in August 2024, is the post-quantum algorithm used in these hybrid deployments. It is based on the hardness of the Module Learning With Errors problem. In a key encapsulation, the client generates a keypair; the server encapsulates a shared secret under the client's public key and sends the ciphertext back; the client decapsulates to recover the shared secret. Neither party transmits the secret itself. The mechanism differs structurally from Diffie-Hellman, but produces the same outcome: a shared symmetric key established without it appearing on the wire.

FIPS 203 defines three parameter sets. ML-KEM-512 provides NIST Security Level 1 (AES-128 equivalent); ML-KEM-768 provides Security Level 3 (AES-192 equivalent); ML-KEM-1024 provides Security Level 5 (AES-256 equivalent). For VPN applications, ML-KEM-768 is the dominant industry choice. The IETF hybrid specification names X25519MLKEM768 as the primary hybrid named group (IETF draft-ietf-tls-ecdhe-mlkem-04).

Key sizes grow with post-quantum algorithms. An X25519 public key is 32 bytes. An ML-KEM-768 public key is 1,184 bytes; its ciphertext is 1,088 bytes. The hybrid handshake sends approximately 2.3 kilobytes more data than a classical-only handshake. Cloudflare reported a 4% increase in TLS handshake completion time in Chrome, based on measurements from their production deployment after deploying hybrid post-quantum key exchange across their network ("State of the post-quantum Internet in 2025," Cloudflare, October 2025). Tunnel throughput after the handshake is unaffected — the symmetric cipher is unchanged. The overhead is real, narrow, and confined to the handshake phase.

Which Providers Have Shipped It

The consumer VPN market moved faster than enterprise network infrastructure vendors. The following providers have production deployments confirmed as of May 2026.

NordVPN. NordVPN deploys ML-KEM via a pre-shared key (PSK) exchange layered on top of an existing WireGuard session. A standard WireGuard handshake completes first; within that session, an ML-KEM key exchange produces a PSK that is injected into the WireGuard session, upgrading it to quantum-resistant. Keys rotate every 90 seconds. Linux rollout was September 2024; all platforms (Windows, macOS, iOS, Android) followed in 2025. Available on the NordLynx protocol only; not available with dedicated IPs, obfuscated servers, or Meshnet. Nord Security confirmed the ML-KEM implementation meets NIST compliance requirements but does not publish the specific parameter set in its public documentation.

ExpressVPN. ExpressVPN upgraded its proprietary Lightway protocol to ML-KEM at NIST Security Level 5 — ML-KEM-1024, the highest security parameter set. The implementation uses WolfSSL's production library; ExpressVPN migrated from the Open Quantum Safe library to WolfSSL for production-grade reliability. Deployed by default across all platforms in January 2025. No user toggle required — it is on.

Mullvad. Mullvad uses a hybrid combining Classic McEliece and ML-KEM to derive a WireGuard PSK, following the same architectural pattern as NordVPN but with a different algorithm pairing. Classic McEliece is a code-based key encapsulation mechanism that has withstood nearly 50 years of cryptanalysis (since 1978); pairing it with ML-KEM means both lattice-based and code-based assumptions must be broken simultaneously. Quantum-resistant tunnels became the default on desktop from January 2025. The open-source wgephemeralpeer tool is published for vanilla WireGuard integrations. Rosenpass, the formally verified post-quantum WireGuard companion protocol, uses the same Classic McEliece and ML-KEM pairing with a purpose-designed key exchange separate from the standard WireGuard handshake.

Cloudflare WARP. Cloudflare WARP — both the 1.1.1.1 consumer client and the Cloudflare One enterprise agent — deploys X25519MLKEM768 by default. As of late October 2025, over 50% of all human-generated connections to Cloudflare were using the hybrid post-quantum key agreement, making this the largest publicly measured production deployment of PQC in TLS (Cloudflare, "State of the post-quantum Internet in 2025," October 2025). That scale deployment has validated the 4% handshake overhead figure under real-world load conditions.

Three Claims Worth Being Sceptical Of

"Post-quantum VPNs are slower." Partially true and overstated. The handshake carries roughly 2.3kB of additional data, and Cloudflare reported a 4% increase in handshake completion time, based on measurements from their production deployment. Tunnel throughput after the handshake is unaffected — the symmetric cipher is unchanged. The overhead is real; it is confined to a one-time cost per session; and at 4%, it is not operationally significant for most enterprise deployments. The claim generalises from a measurable but narrow effect.

"My corporate VPN is already post-quantum safe." Almost certainly false unless your vendor has explicitly announced a production PQC rollout and your deployment is running the PQ-enabled protocol variant. The commercial consumer providers listed above moved faster than enterprise network infrastructure vendors. Most enterprise IPsec/IKEv2 deployments, OpenVPN installations, and legacy SSL-VPN products have not shipped ML-KEM support. If your enterprise VPN vendor has not published a PQC deployment announcement, assume the implementation is classical.

"WireGuard is quantum-safe." False. WireGuard's Noise_IKpsk2 handshake uses Curve25519 for key agreement. Curve25519 is an elliptic-curve algorithm, quantum-vulnerable under Shor's algorithm on a CRQC. WireGuard does not ship post-quantum key exchange. PQ protection in WireGuard-based VPNs — NordLynx, Mullvad, Cloudflare WARP — is delivered via a layered PSK injection mechanism: an ML-KEM exchange running over a WireGuard session to produce a PSK injected into the handshake. The base WireGuard protocol is unchanged and remains classically implemented.

The Authentication Gap

ML-KEM is a key encapsulation mechanism. It solves key agreement. It does not authenticate the parties to a VPN connection — confirming that you are connecting to the correct server, not a man-in-the-middle. VPN authentication depends on separate mechanisms: certificate chains, pre-shared secrets, or digital signatures using RSA or ECDSA. Post-quantum signatures — ML-DSA per NIST FIPS 204, SLH-DSA per NIST FIPS 205 — are a distinct migration problem from key exchange.

None of the major consumer VPN providers reviewed have published confirmation that their server authentication certificates have been migrated to ML-DSA or SLH-DSA as of May 2026. A VPN deployment running ML-KEM for key exchange while authenticating via ECDSA certificates is partially post-quantum protected, not fully. The key exchange is resistant to HNDL. The authentication layer remains classically vulnerable.

If you are evaluating a vendor's PQC claims, six questions separate a genuine implementation from marketing language: Which algorithm handles key agreement, and which FIPS 203 parameter set? Is the PQ mechanism in the tunnel handshake directly, or in a separate PSK layer? Has the implementation been independently audited? Is source code or technical documentation for the PQ mechanism published? Have server authentication certificates been migrated to a post-quantum signature scheme? Is PQ enabled by default, or does it require a user toggle?

The authentication certificate question is where most enterprise procurement processes currently end the conversation too early.