Post-quantum VPN encryption targets one specific component of a VPN session: the key exchange that establishes your session keys. The cipher that encrypts your traffic does not need replacing. What changes is the mathematical problem an adversary would need to solve to recover those keys, and that change is already deployed in several production VPN implementations today.
TL;DR
Two components protect every VPN connection. The cipher (AES-256-GCM or ChaCha20-Poly1305) encrypts your traffic through the tunnel. Post-quantum encryption addresses a different component entirely: the key exchange that establishes the session. The cipher is not the concern. The key exchange is.
A quantum computer running Shor’s algorithm could reconstruct the shared secret from the public key values exchanged during a VPN handshake, making every session key derived from that exchange recoverable. This threat is already operational in the form of harvest now, decrypt later: adversaries are recording encrypted traffic today, passively and without trace, planning to decrypt it once sufficient quantum hardware exists.
Post-quantum protection adds a second key exchange layer using ML-KEM (FIPS 203, published 13 August 2024), the key encapsulation mechanism standardised by NIST after an eight-year global competition. The hybrid construction requires that both the classical and post-quantum layers be broken simultaneously for a session to be compromised. In WireGuard-based deployments, this is delivered through the protocol’s built-in pre-shared key slot without modifying the handshake.
Mullvad has made post-quantum protection the default on desktop since January 2025, with mobile following later that year. NordVPN offers it as an opt-in toggle. ExpressVPN ships it as the default on its Lightway protocol and as an opt-in option on WireGuard. ProtonVPN has not yet deployed it. For most users, everyday browsing and general ISP privacy do not produce data whose confidentiality needs to span a decade. For journalists, lawyers, researchers, and people under sustained surveillance, enabling post-quantum key exchange now closes the harvest window on future sessions.
What post-quantum VPN encryption is (and what it isn’t)
Post-quantum encryption adds a second lock to the specific moment in a VPN connection where your device and the server agree on a shared secret key. What changes is the mathematical problem an adversary would need to solve to recover that key, and a sufficiently powerful quantum computer could eventually solve the version of that problem in use today.
When a VPN app displays “AES-256-GCM” or “ChaCha20-Poly1305” in its settings, those names describe the cipher that encrypts your traffic through the tunnel. Post-quantum encryption addresses a different component: the negotiation that happens before any cipher work begins, where your device and the VPN server agree on the keys the cipher will use. Quantum computing threatens one of these components specifically and has no meaningful impact on the other.
Post-quantum VPN encryption is a modification to how the session key is established. It adds a second, quantum-resistant key encapsulation step alongside the classical one. It does not change the data cipher and does not alter the VPN protocol underneath.
Readers who want the full explanation of what AES-256-GCM and ChaCha20-Poly1305 actually do, including why the GCM suffix matters and how AEAD authentication works in a single cryptographic pass, should read VPN Encryption Explained first.
The threat: what a quantum computer could actually break
Shor’s algorithm shatters the key exchange
Every VPN handshake (the initial exchange of cryptographic keys that establishes a session) relies on a mathematical trapdoor. Two parties each generate a key pair for the session: a private key, kept secret, and a corresponding public key, transmitted openly. Each combines its own private key with the other party’s public key through an operation that is computationally easy in one direction (private key plus public key yields shared secret) and computationally infeasible to reverse with a classical computer (two public keys alone cannot yield the shared secret). On the elliptic-curve variant used by WireGuard (a VPN protocol, using Curve25519) and by modern IKEv2 (another VPN protocol widely used in enterprise and mobile networks, typically using NIST P-256 or P-384), this security rests on the elliptic curve discrete logarithm problem (ECDLP): given a point on the curve and the result of multiplying it by a secret integer, recovering that integer is not feasible classically.
Shor’s algorithm, presented by Peter Shor at the 1994 Symposium on Foundations of Computer Science, solves both integer factorisation and the discrete logarithm problem, including the elliptic-curve variant. On a quantum computer of sufficient scale, Shor’s algorithm solves the ECDLP in polynomial time. Given the ephemeral public key values transmitted during a VPN handshake, a quantum computer can recover the corresponding ephemeral private keys, reconstruct the shared secret, and derive the session keys from it. The key exchange, as currently deployed, provides no meaningful resistance to a capable quantum adversary.
Quantum computers capable of running Shor’s algorithm against 256-bit elliptic curve keys do not exist today. Estimates from credible sources for cryptographically relevant machines range from roughly five to fifteen years.
Grover’s algorithm merely weakens the cipher
Quantum computers affect symmetric ciphers through a fundamentally different and far weaker mechanism. Grover’s algorithm provides a quadratic speedup for brute-force key search: where a classical computer requires 2256 operations to exhaustively search AES-256’s key space, a quantum computer using Grover’s requires approximately 2128. This reduces AES-256’s effective post-quantum security to approximately 128 bits, a weakening rather than a break. A 128-bit post-quantum security margin is considered comfortably adequate by current cryptographic consensus, and NIST’s security level equivalences for ML-KEM are calibrated against this Grover-adjusted AES baseline. The ciphers your VPN uses do not need replacing.
Harvest now, decrypt later: why the threat is active today
The harvest now, decrypt later (HNDL) strategy removes the need for a quantum computer to exist today. An adversary with access to network infrastructure intercepts and stores encrypted VPN traffic now. The encryption holds against every classical attack available. When a quantum computer capable of running Shor’s against the recorded key exchanges becomes available, those stored sessions become readable retroactively. The attacker’s investment is front-loaded: capture and storage are technically accessible to nation-state actors now. Decryption is deferred to when the hardware catches up.
The collection phase leaves no trace. When an adversary intercepts and records a VPN handshake transcript, there is no alert, no anomaly, and no indication anything unusual has occurred. From the user’s perspective, the VPN connected normally, traffic flowed normally, and the session ended normally. The harvest is passive. The exposure materialises years later, on hardware that does not yet exist, when the stored transcript is used to reconstruct the session keys.
State-level adversaries have several documented mechanisms for capturing encrypted internet traffic at scale. Undersea cable landing stations and internet exchange points are the most established: the GCHQ (UK signals intelligence agency) TEMPORA programme, disclosed through documents published in 2013, buffers communications extracted from transatlantic fibre-optic cables at UK landing stations, explicitly designed to store traffic for later processing and search. The buffer-and-search architecture is directly relevant to HNDL as an operational model. BGP hijacking provides an additional mechanism: by deliberately rerouting internet traffic through adversarially controlled network infrastructure, an attacker can copy whatever encrypted traffic traverses the hijacked route before forwarding it to its intended destination with minimal delay. The research group Renesys documented BGP-based man-in-the-middle interception in 2013; academic analysis by Demchak and Shavitt documented long-lived BGP route manipulation attributed to a state-owned telecommunications carrier, with traffic redirected and returned. VPN sessions travel on the same internet infrastructure as all other traffic and are captured equally under these mechanisms.
The threshold question for any piece of data is not whether a quantum computer exists today but whether the information will still be sensitive when one does. A VPN session protecting ordinary evening browsing is unlikely to be worth storing for a decade. A session carrying a journalist’s communication with a confidential source, a lawyer’s privileged case material, an unreleased clinical trial dataset, or diplomatic correspondence may need to remain confidential well beyond current quantum timeline estimates. For data with that kind of sensitivity window, the exposure is already present.
Government agencies that have to plan around this threat treat HNDL as an active operational strategy rather than a theoretical scenario. The NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), published September 2022, names network traffic as especially vulnerable to HNDL collection and requires US national-security networking equipment, including VPNs, to achieve exclusive use of post-quantum algorithms by 2030, with overall NSS quantum resistance targeted by 2035. In February 2026, Google’s Kent Walker (President of Global Affairs) and Hartmut Neven (Founder and Lead, Google Quantum AI) published a call to action stating that adversaries are actively harvesting encrypted data for future quantum decryption and that a cryptographically relevant quantum computer is no longer perpetually a decade away. Google has been deploying ML-KEM key exchange across its services, with Chrome’s implementation live since 2024 and full migration targeted for 2026.
The same harvest logic applies across all protocols that rely on classical public-key cryptography: TLS connections, encrypted messaging, and any session whose key exchange was conducted over Diffie-Hellman or ECDH faces the same retroactive exposure. VPN key exchange has been one of the first deployment areas for post-quantum protection because network traffic in transit is among the most exposed HNDL surfaces and the implementation paths (the WireGuard PSK slot, RFC 8784 for IKEv2) are well-defined and deployable without altering the underlying protocols.
Why your key exchange is the vulnerable component
The WireGuard handshake illustrates the exposure most clearly. Your device generates an ephemeral key pair for the session: a private key known only to your device, and an ephemeral public key transmitted to the server in the first handshake message. The server generates its own ephemeral key pair and returns its public key in the second message. Each side performs the ECDH operation, combining its own ephemeral private key with the other party’s public key, and arrives at the same shared secret through the mathematical properties of Curve25519. HKDF, keyed with BLAKE2s, derives directional session keys from that shared secret. Those session keys are what ChaCha20-Poly1305 uses to encrypt your traffic. After the handshake, both devices discard their ephemeral private keys: they are no longer needed, and this discarding is what produces perfect forward secrecy against classical adversaries.
During this handshake, an adversary monitoring the network records two values: your device’s ephemeral public key and the server’s ephemeral public key. Both travel in the clear. They are public keys, designed to be shared. The recorded values are useless to a classical attacker: the ECDLP makes reversing the key exchange computationally infeasible with current hardware.
Shor’s algorithm breaks the ECDLP. Given an elliptic curve public key, a quantum computer of sufficient scale recovers the corresponding private key directly from the recorded public value, in polynomial time. A quantum adversary with the stored handshake transcript reconstructs your device’s ephemeral private key and the server’s ephemeral private key, performs the ECDH computation, arrives at the shared secret, runs it through HKDF, and derives the session keys. Every packet encrypted under those keys becomes decryptable.
The fact that both parties discarded their ephemeral private keys after the handshake is irrelevant to this attack. The quantum adversary is not obtaining private keys from the devices. The adversary is reconstructing them from the public keys in the recorded transcript. Ephemerality protects against a classical adversary who later compromises a device or a server’s long-term key. It has no bearing on an adversary who breaks the mathematical relationship between public and private key from the recorded public material alone.
This vulnerability is not specific to WireGuard. Any VPN protocol using elliptic-curve or classical Diffie-Hellman key exchange, including IKEv2 and OpenVPN (an open-source VPN protocol), carries the same exposure.
Perfect forward secrecy and the post-quantum interaction
Perfect forward secrecy protects against a classical adversary who later obtains a server’s long-term key: session keys came from ephemeral material that both parties have already discarded, so past sessions cannot be decrypted. Shor’s algorithm bypasses this entirely. It reconstructs ephemeral private keys directly from the ephemeral public values in the recorded handshake transcript — without needing anything either party currently holds. Ephemerality is irrelevant when the public key alone is sufficient to recover the private key.
PFS and post-quantum PSK protection address different attack classes and are complementary, not substitutes. See Perfect Forward Secrecy in VPNs for the full mechanics, including how the two protections interact across WireGuard, OpenVPN, and IKEv2.
The NIST post-quantum standards
In December 2016, NIST issued a call for post-quantum cryptographic algorithm proposals, launching a global eight-year evaluation. The goal was to identify algorithms that could replace RSA, elliptic-curve key exchange, and digital signatures against a capable quantum computer, based on mathematical problems that neither classical nor quantum computers are known to solve efficiently. Over multiple evaluation rounds involving cryptographers across dozens of countries, with public submissions and open cryptanalytic scrutiny at each stage, NIST narrowed the field and selected four algorithms for standardisation.
On 13 August 2024, NIST published three finalised standards simultaneously. FIPS 203 (Federal Information Processing Standard 203) standardised ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), the post-quantum algorithm for establishing shared secrets. FIPS 204 standardised ML-DSA (Module-Lattice-Based Digital Signature Algorithm), for digital signatures. FIPS 205 standardised SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), a hash-based signature alternative. ML-DSA and SLH-DSA are signature algorithms: they authenticate identity and sign messages. They are not the relevant category for VPN session key establishment, where the problem is agreeing on a shared secret rather than verifying a message. FIPS 203 (ML-KEM) is what all current commercial VPN post-quantum deployments use.
The authentication side of the transition is progressing more slowly than key exchange, and the reason is practical. Post-quantum signature algorithms produce substantially larger outputs than their classical counterparts. ML-DSA signatures range from approximately 2,420 bytes (ML-DSA-44, Level 1) to 4,627 bytes (ML-DSA-87, Level 5), compared to 64 bytes raw for an ECDSA P-256 signature. Large post-quantum handshake objects, including both key shares and signature chains, can exceed UDP MTU limits, cause fragmentation across multiple packets, and be dropped by middleboxes that cannot handle fragmented records. For IKEv2 specifically, the size of post-quantum key material prompted the IETF to introduce the IKE_INTERMEDIATE exchange (RFC 9242) to split large post-quantum objects across smaller messages without breaking the handshake. On the certificate infrastructure side, no publicly-trusted certificate authority currently issues certificates signed with ML-DSA or SLH-DSA. Let’s Encrypt, which accounts for a large share of public TLS certificates, targets late 2026 for a staging environment and 2027 for production post-quantum certificate issuance. VPN providers have therefore focused first on post-quantum key exchange, where the HNDL threat is most immediate and the implementation path is well-defined, while post-quantum certificate authentication follows as the broader infrastructure matures.
A key encapsulation mechanism establishes a shared secret between two parties. One party uses the other’s public key to encapsulate a randomly generated secret, producing a ciphertext that only the holder of the corresponding private key can decapsulate. Both parties arrive at the same shared secret, which becomes session key material. This serves the same purpose as Diffie-Hellman key exchange but works differently at the mathematical level. ML-KEM’s security rests on the hardness of problems in module lattices, a class of mathematical structures for which no efficient quantum algorithm is known.
ML-KEM defines three security levels. ML-KEM-512 targets NIST Security Level 1, with post-quantum security equivalent to approximately AES-128. ML-KEM-768 targets Level 3, equivalent to approximately AES-192. ML-KEM-1024 targets Level 5, the highest defined, equivalent to approximately AES-256 post-quantum security, and the level NIST’s CNSA 2.0 specifies for ML-KEM in national-security deployments. ExpressVPN has publicly disclosed that its Lightway protocol uses ML-KEM-1024 (Level 5). NordVPN and Mullvad have not disclosed which level their implementations use.
ML-KEM is the standardised form of the algorithm that competed in the NIST process as CRYSTALS-Kyber, selected for standardisation in July 2022 and renamed during the process. Where older provider documentation or secondary sources refer to “Kyber” or “CRYSTALS-Kyber,” they are describing what is now ML-KEM under FIPS 203. Some implementations, including Rosenpass, use the pre-standardisation Kyber rather than the finalised ML-KEM; these are not equivalent designations.
In March 2025, NIST additionally selected HQC (Hamming Quasi-Cyclic) as a backup KEM for standardisation, based on different mathematical hardness assumptions from lattice problems. This provides diversity in case lattice-based problems are someday weakened. HQC has not yet appeared in commercial VPN provider deployments.
The hybrid model: why classical and post-quantum run together
ML-KEM was standardised in August 2024. Classical ECDH key exchange has accumulated decades of public cryptanalytic scrutiny, planetary-scale deployment, and formal security proofs in well-established mathematical frameworks. ML-KEM has been rigorously analysed through NIST’s eight-year process, which is the best available evidence of its security, but it is orders of magnitude less battle-tested than ECDH in real-world production. The cryptographic community’s response to this asymmetry is the hybrid model: run both key exchanges simultaneously and combine their outputs so that neither layer can be weakened by the other. If either has an undiscovered flaw, the session remains protected by the remaining layer.
In a hybrid post-quantum key exchange, both an ECDH operation (classically X25519 over Curve25519) and an ML-KEM encapsulation run during session establishment. The ECDH produces a shared secret in the classical way. ML-KEM produces an encapsulated secret that only the server can decapsulate. Both outputs are combined, typically by feeding them together into the key derivation function, to produce the final session key material. An adversary must defeat both components simultaneously to recover the session keys. A future quantum computer runs Shor’s against the X25519 component and succeeds; the ML-KEM layer still holds. A hypothetical flaw in ML-KEM breaks the ML-KEM component; X25519 holds under all current classical attacks.
The hybrid approach is the cryptographic community’s broadly adopted response during the transition period, reflected in IETF specifications and in every major VPN provider implementation. NIST permits hybrid key establishment and considers it acceptable alongside pure ML-KEM. NSA’s CNSA 2.0 acknowledges hybrid as acceptable during the transition but sets exclusive ML-KEM-1024 as its ultimate endpoint for national-security systems. The hybrid approach will remain appropriate until ML-KEM has accumulated the deployment history and post-standardisation cryptanalytic scrutiny that makes pure post-quantum implementations the clear choice.
How VPN protocols deliver post-quantum protection
WireGuard: the pre-shared key slot
The Noise_IKpsk2 construction at the core of WireGuard includes a built-in optional pre-shared key slot. The “psk2” suffix in the full protocol identifier (Noise_IKpsk2_25519_ChaChaPoly_BLAKE2s) indicates that the pre-shared key is mixed into the key derivation function after the second handshake message. WireGuard’s own protocol specification documents this slot as a mechanism for adding symmetric protection on top of the existing asymmetric exchange, with post-quantum resistance named as an example use. When a provider implements post-quantum WireGuard, a separate ML-KEM key encapsulation step, run outside the WireGuard handshake, derives a 32-byte symmetric secret and injects it into this slot for the session. The final session keys are derived from both the classical X25519 output and the ML-KEM-derived PSK combined, requiring both to be broken simultaneously. The WireGuard protocol itself is unmodified. For the mechanics of the PSK slot within the Noise_IKpsk2 handshake, see WireGuard Explained. For NordVPN’s specific implementation, including the 90-second key rotation and the features that conflict with post-quantum encryption, see NordLynx Explained.
For self-hosted WireGuard deployments, the open-source Rosenpass project provides post-quantum key exchange in a symmetric peer-to-peer model. Rosenpass runs as a separate background process alongside WireGuard and performs its own authenticated key exchange using a hybrid of two KEMs: Classic McEliece (specifically mceliece460896) as the static key encapsulation mechanism and Kyber-512 as the ephemeral one. Classic McEliece is a code-based algorithm that remains under NIST’s ongoing evaluation and has not been published as a finalised NIST standard; Kyber-512 is the pre-standardisation round-3 version of the algorithm that became ML-KEM under FIPS 203. The resulting shared secret is refreshed approximately every two minutes and injected into WireGuard’s pre-shared key slot; WireGuard’s own handshake is unmodified. Rosenpass is pre-1.0 software (v0.2.2 as of July 2026), has undergone one published independent penetration test by Radically Open Security (2023, report published January 2024), and is distributed as a Linux tool. Both peers must run the Rosenpass daemon, making it suited to server-to-server and technically capable self-hoster deployments rather than consumer client-server VPN use.
IKEv2: RFC 8784
IKEv2 post-quantum protection has a published IETF (Internet Engineering Task Force) standard: RFC 8784, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” published June 2020. The mechanism is a Post-quantum Pre-Shared Key (PPK): a symmetric secret established out-of-band (through a channel separate from the VPN connection itself) before the IKE exchange, and then mixed into IKEv2’s key derivation function alongside the classical DH output.
During the IKE handshake, both parties perform a classical DH exchange in the standard way. RFC 8784 adds the PPK as an additional input to the key derivation step: the final session key material is derived from both the DH shared secret and the PPK combined. If a future quantum adversary uses Shor’s algorithm to recover the DH shared secret from the recorded handshake, the session keys remain inaccessible without also knowing the PPK. The PPK was never transmitted over the connection. It exists only in the configuration of the two endpoints.
The IKEv2 PPK under RFC 8784 is a static, pre-distributed secret, provisioned ahead of time between the two endpoints and rotated through out-of-band channels on a schedule. This differs from most WireGuard post-quantum deployments, where the post-quantum PSK is derived freshly per session from a live ML-KEM encapsulation exchange, changing with every connection. Both approaches provide the same hybrid guarantee: breaking both the classical DH and the symmetric post-quantum component is required to compromise the session keys. The WireGuard approach additionally provides forward secrecy for the post-quantum component, because the per-session ML-KEM key material is discarded when the session ends; the RFC 8784 PPK persists until manually rotated. For the base IKEv2 protocol, including the two-phase handshake and Security Association architecture, see IKEv2/IPsec Explained.
OpenVPN: partial mitigation and the OpenSSL 3.5 path
OpenVPN’s tls-crypt-v2 provides a partial post-quantum mitigation by wrapping the full TLS control-channel handshake, including the classical DH key exchange, inside a symmetric AES-256-CTR plus HMAC-SHA-256 envelope. A future quantum adversary who recorded the traffic cannot recover the handshake to derive the data-channel keys without knowing the pre-shared tls-crypt key, which was never transmitted. Full hybrid key exchange becomes available when OpenVPN 2.7 is built against OpenSSL 3.5 or later: OpenSSL 3.5 includes the X25519MLKEM768 hybrid group in its default TLS 1.3 group list, so when an OpenVPN 2.7 build links against OpenSSL 3.5 or later and both peers support it, the hybrid group negotiates automatically. Availability is gated by the OpenSSL version the build links against rather than a separate configuration option. The underlying IETF specification for X25519MLKEM768, draft-ietf-tls-ecdhe-mlkem, remains a Standards Track Internet-Draft as of mid-2026 and has not yet been published as an RFC. For the full treatment of tls-crypt-v2’s mechanism and the OpenSSL build requirements, see OpenVPN Explained.
Where providers stand in 2026
Commercial VPN post-quantum deployment in mid-2026 falls into three states: production-deployed and on by default, production-deployed and available as an opt-in, and groundwork underway with no live feature yet.
| Provider | Protocol | PQ mechanism | Default or opt-in | ML-KEM level disclosed | Status |
|---|---|---|---|---|---|
| NordVPN | WireGuard (NordLynx) | ML-KEM via PSK slot, hybrid with X25519 | Opt-in toggle | Not disclosed | Deployed, all platforms |
| Mullvad | WireGuard | Classic McEliece + ML-KEM, ephemeral-peer exchange into PSK slot | Default, all platforms | Not stated | Deployed |
| ExpressVPN (Lightway) | (D)TLS 1.3 | ML-KEM-1024 via TLS 1.3 native hybrid key exchange | Default, all platforms | Level 5 (ML-KEM-1024) | Deployed |
| ExpressVPN (WireGuard) | WireGuard | ML-KEM via PSK slot, hybrid with X25519 | Opt-in | Not disclosed separately | Deployed August 2025 |
| ProtonVPN | — | New WireGuard codebase (groundwork) | N/A | N/A | Not yet deployed |
NordVPN’s post-quantum encryption is available on all platforms via a manual toggle and is incompatible with several features when active.
Mullvad’s post-quantum implementation has two features that distinguish it from most provider deployments: it is the default rather than an opt-in option, and it uses two KEMs rather than one. The combination is Classic McEliece, a code-based algorithm with long-established security foundations and a different mathematical hardness basis from lattice problems, alongside ML-KEM, the NIST-standardised lattice-based KEM. The dual-algorithm design provides resilience against any undiscovered weakness in either individual algorithm: a future flaw in ML-KEM leaves Classic McEliece standing.
Mullvad’s delivery mechanism uses an ephemeral-peer model: a short-lived WireGuard tunnel is established specifically to exchange the post-quantum key material via ML-KEM encapsulation; the resulting shared secret is then injected into WireGuard’s pre-shared key slot for the actual VPN session. The per-session derivation from a live ML-KEM operation provides forward secrecy for the post-quantum component: the key material is discarded after each session ends. The ML-KEM security level is not stated in Mullvad’s published documentation, although the implementation is fully open source. Post-quantum protection became the default on Mullvad desktop apps on 9 January 2025.
ExpressVPN has two distinct post-quantum deployments. Its default protocol, Lightway, a (D)TLS 1.3 protocol using DTLS 1.3 for UDP and TLS 1.3 for TCP, carries ML-KEM-1024 through TLS 1.3’s native hybrid key exchange, making post-quantum protection the default for all Lightway connections across all platforms. ExpressVPN has publicly disclosed the security level as ML-KEM-1024 (NIST Level 5, the highest defined by the standard), making it the only major provider to have stated its ML-KEM parameter set at this level of specificity.
In August 2025, ExpressVPN launched a separate post-quantum WireGuard implementation alongside a publicly released technical whitepaper. The WireGuard implementation uses hybrid ML-KEM delivered through WireGuard’s PSK slot, derived fresh per session via an ML-KEM hybrid TLS 1.3 channel, without modifying the WireGuard protocol. Unlike Lightway, this implementation is opt-in; Lightway remains the default protocol. Platform availability at launch covered iOS, Android, and Windows; macOS, Linux, and Apple TV have since been added. Marketing language around the launch described not relying on “pre-shared keys,” which referred to static, manually configured pre-shared keys rather than to the WireGuard PSK slot mechanism.
ProtonVPN has not deployed post-quantum encryption as of mid-2026. The company’s Spring/Summer 2026 roadmap, published April 2026, describes a new client-side WireGuard codebase currently in beta on Android and Windows, with macOS, iOS, iPadOS, and Linux to follow, as the groundwork for post-quantum encryption as a future deliverable from that codebase. ProtonVPN has stated that its aim is consistent deployment across its full product ecosystem rather than a per-platform feature.
Windscribe uses the WireGuard PSK slot populated via X25519MLKEM768 hybrid key exchange over TLS 1.3, with the key rotated at each login, and is live across desktop, Android, and iOS. Surfshark shipped WireGuard post-quantum protection in January 2026 and followed with a proprietary protocol called Dausos in April 2026, using hybrid ML-KEM plus X25519 for key exchange alongside an ML-DSA certificate system; an MTU compatibility issue affecting residential PPPoE connections was fixed in version 4.27.1. NymVPN’s default Fast Mode protocol, AmneziaWG, incorporates post-quantum protection via the Lewes Protocol key exchange, which became the default on all Fast Mode connections in June 2026.
Does post-quantum encryption slow down your VPN?
Post-quantum protection changes only the key exchange, not the cipher that encrypts your traffic, so its performance cost is confined to session setup rather than to the speed of the tunnel itself. Once the handshake completes and session keys are derived, your traffic flows through exactly the same ChaCha20-Poly1305 or AES-256-GCM cipher it always did.
The cost that does exist is at connection establishment. Post-quantum key exchange involves one additional cryptographic step: the ML-KEM encapsulation and decapsulation. ML-KEM is computationally efficient by design, and on modern hardware the added computation is not perceptible. The more practical consideration is packet size: hybrid key exchanges produce larger initial handshake messages than classical-only exchanges. This can create fragmentation considerations on some network paths, and for IKEv2 it is precisely why RFC 9242’s IKE_INTERMEDIATE exchange was introduced. In WireGuard deployments, the ML-KEM key material is exchanged outside the WireGuard handshake through a separate channel, so WireGuard’s own packet structure is not affected.
Mullvad’s ephemeral-peer approach derives the post-quantum PSK once, at connection setup: the app briefly establishes a WireGuard tunnel to a short-lived peer, negotiates the quantum-safe shared secret inside that auxiliary tunnel, then reconnects using the derived PSK for the actual VPN session. This is a one-time cost paid at connect time, not an ongoing interval overhead. Once connected, WireGuard’s normal rekeying continues on its standard schedule, mixing the established PSK into each rekey rather than re-running the full KEM exchange. NordVPN’s 90-second key rotation (when post-quantum encryption is enabled) refreshes session keys more frequently than WireGuard’s standard 120-second rekey interval, which is by design: more frequent rotation limits the volume of traffic exposed if a session key were ever recovered. Neither model produces perceptible latency or throughput effects during normal use.
For the vast majority of users, post-quantum encryption has no measurable impact on VPN speed.
How to enable post-quantum encryption
Post-quantum encryption is WireGuard-only on most providers and off by default on every provider except Mullvad. The general steps are: confirm the active protocol is WireGuard (or, on ExpressVPN, confirm Lightway if that is the implementation you want); locate the post-quantum toggle in settings if one exists; and after enabling it, verify the toggle remains active after switching between features, since on some providers it can be disabled silently when incompatible options are activated.
By provider
Mullvad: Post-quantum encryption is the default on all platforms and requires no action to enable. To confirm it is active while connected, look for the “Quantum resistance” indicator on the main connection view, below the server name. The configured preference can be checked separately at Settings → VPN settings → WireGuard settings → Quantum-resistant tunnel on desktop; on mobile the path omits the WireGuard settings sub-level: Settings → VPN settings → Quantum-resistant tunnel.
NordVPN: Opt-in, available when NordLynx (WireGuard) is the active protocol. The post-quantum toggle is in the Connection and security section of Settings.
ExpressVPN (Lightway): Post-quantum protection via ML-KEM-1024 is the default when Lightway is active, which it is by default on all platforms. No separate toggle is needed. Verify the active protocol in the ExpressVPN protocol settings.
ExpressVPN (WireGuard): Select WireGuard in the protocol settings; the app enables post-quantum key exchange automatically when WireGuard is the active protocol. Available on iOS, Android, Windows, macOS, Linux, and Apple TV.
ProtonVPN: Post-quantum encryption is not available as of mid-2026. Check ProtonVPN’s official release notes for current status, as the new WireGuard codebase that will carry it is in active development.
Should you enable post-quantum encryption now?
The relevant question is not which provider has the most technically complete post-quantum deployment but whether the data your VPN sessions carry has a confidentiality shelf-life that extends into the quantum era. If data your VPN protects today would cause harm if disclosed in five, ten, or fifteen years, the HNDL exposure applies to those sessions now. If not, the risk calculus does not meaningfully change today.
For most VPN users, the data’s shelf-life does not span that window. Everyday browsing, streaming, and public Wi-Fi protection do not produce data whose sensitivity extends a decade into the future. Standard VPN encryption, through a verified no-log provider on a modern protocol, remains adequate for this use case. Enabling post-quantum protection where it requires switching protocols or forgoing incompatible features imposes real friction for no meaningful benefit in this scenario.
For a narrower group, the shelf-life threshold is crossed. Journalists whose source relationships need to remain confidential across years. Lawyers handling long-term sensitive case material. Researchers working with commercially or politically sensitive unpublished data. People under documented sustained state-level surveillance. For these users, enabling post-quantum protection on future sessions closes the HNDL window for traffic recorded from that point forward. It cannot protect sessions already recorded under classical key exchange only. Those sessions are permanently exposed to a future quantum adversary who stored them.
Inventory the types of communication your VPN protects and identify which carry a long sensitivity shelf-life.
Where post-quantum encryption is available and relevant to your situation: confirm which protocol is active, since PQE is WireGuard-only on most providers; enable the toggle if one exists; and verify it has not been disabled by switching to an incompatible feature.
Switching providers solely to gain post-quantum protection is justified only if your traffic already crosses the confidentiality shelf-life threshold. For users in that category, the practical distinction is between providers where post-quantum protection is on by default (Mullvad) and those where it requires a manual toggle. Traffic captured under classical key exchange before you make any change remains permanently exposed to a future quantum adversary who stored it.
Frequently asked questions
Is my VPN already quantum-safe?
Probably not, unless you use Mullvad (which enables post-quantum protection by default) or have deliberately enabled a post-quantum toggle on a provider that offers one. Most VPN connections, even through providers that have deployed post-quantum encryption, use classical key exchange by default. Check your protocol settings and whether a post-quantum option exists and is active.
What is Q-Day?
Q-Day (also called Y2Q) is the point at which a quantum computer of sufficient scale can break RSA and elliptic-curve cryptography. Timeline estimates from credible sources range from roughly five to fifteen years. Its relevance before it arrives is the harvest now, decrypt later strategy: traffic recorded today under classical key exchange is retroactively vulnerable when Q-Day arrives, even though it is secure against every attack that currently exists. The only protection against HNDL is deploying quantum-resistant key exchange before traffic is captured, because sessions already recorded cannot be retroactively protected.
What is ML-KEM?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, FIPS 203, published 13 August 2024) is the key encapsulation mechanism standardised by NIST after an eight-year global competition. It establishes a shared secret using public-key cryptography based on module lattice problems, for which no efficient quantum algorithm is known. It is the algorithm used in all current major commercial VPN post-quantum deployments and comes in three security levels (ML-KEM-512, ML-KEM-768, and ML-KEM-1024), with ML-KEM-1024 being the highest. ML-KEM is the standardised form of the algorithm that competed in the NIST process as CRYSTALS-Kyber.
What is harvest now, decrypt later?
The strategy of recording encrypted network traffic today and storing it for decryption once a capable quantum computer is available. The collection is passive: there is no indication when traffic is captured. The adversary stores the handshake transcript alongside the encrypted session data. When quantum hardware arrives, Shor’s algorithm reconstructs the session keys from the recorded public values and the stored traffic is decrypted. Sessions already recorded under classical key exchange only cannot be retroactively protected. Deploying post-quantum key exchange before traffic is captured is the only effective mitigation.
Does perfect forward secrecy protect me from quantum computers?
No. PFS protects against classical retrospective compromise of long-term key material — session keys came from ephemeral material that no longer exists. Shor’s algorithm bypasses this: it reconstructs ephemeral private keys directly from the ephemeral public values in the recorded transcript, without needing anything either party currently holds. PFS and post-quantum PSK protection address different attacks; both are worth having.
Why doesn’t WireGuard need to be modified to add post-quantum protection?
Because WireGuard’s Noise_IKpsk2 construction includes a built-in optional pre-shared key slot, documented as usable for adding symmetric protection on top of the existing asymmetric exchange, with post-quantum resistance named as an example use. An ML-KEM key encapsulation step derives a 32-byte symmetric secret outside the WireGuard handshake and injects it into that slot. The WireGuard handshake itself is unmodified. The result is hybrid protection: both X25519 and the ML-KEM-derived PSK must be broken simultaneously. No protocol fork or custom implementation is required.
What is the difference between how WireGuard and IKEv2 handle post-quantum key exchange?
The hybrid guarantee is the same for both: both classical and post-quantum components must fail simultaneously. The difference is in how the post-quantum material is sourced. WireGuard post-quantum deployments derive the PSK freshly per session from a live ML-KEM encapsulation exchange, providing forward secrecy for the post-quantum component because the per-session key material is discarded after use. IKEv2’s RFC 8784 mechanism uses a static PPK provisioned out-of-band and rotated on a schedule, which provides the quantum resistance but not the per-session freshness.
How do the ML-KEM security levels compare?
ML-KEM defines three levels. ML-KEM-512 provides approximately AES-128 equivalent post-quantum security (NIST Level 1). ML-KEM-768 provides approximately AES-192 equivalent security (Level 3). ML-KEM-1024 provides approximately AES-256 equivalent security (Level 5) and is the level CNSA 2.0 specifies for national-security deployments. ExpressVPN has publicly confirmed using ML-KEM-1024 for its Lightway protocol. NordVPN and Mullvad have not stated their implementation levels publicly.
Do I need post-quantum encryption for everyday VPN use?
For most everyday use, including ISP privacy, public Wi-Fi protection, streaming, and general browsing, no. These sessions do not produce data whose sensitivity extends a decade into the future, so the harvest now, decrypt later exposure is not meaningfully relevant. Standard VPN encryption remains adequate. Post-quantum key exchange matters when data needs to remain confidential for years.
Is AES-256 encryption quantum-safe?
Yes, with one qualification. Grover’s algorithm provides a quadratic speedup for brute-force key search against symmetric ciphers, reducing AES-256 to approximately 128-bit effective post-quantum security. This is a weakening rather than a break, and a 128-bit post-quantum security margin is considered comfortably adequate by current cryptographic consensus. AES-256 is not the component that post-quantum VPN encryption is designed to address.
Does post-quantum encryption slow down my VPN?
Not during normal use. The performance cost is confined to connection setup: the ML-KEM encapsulation step adds a small computation at key establishment, and larger hybrid handshake objects can create MTU considerations on some network paths. Steady-state throughput, download speed, and streaming performance are unaffected because the data cipher is unchanged. NordVPN rotates session keys every 90 seconds in the background when post-quantum encryption is enabled; Mullvad derives its post-quantum key once at connection setup, not on a repeating interval, so there is no periodic post-quantum overhead during an active Mullvad session.
How do I turn on post-quantum encryption?
The steps depend on the provider. On Mullvad, it is on by default and requires no action. On NordVPN, confirm NordLynx is the active protocol, then enable the post-quantum toggle in Settings under Connection and security. On ExpressVPN, post-quantum protection is already active by default when Lightway is the protocol; for the WireGuard implementation, select WireGuard in the protocol settings. After enabling any toggle, verify it has not been silently disabled by subsequently switching to an incompatible feature.
Should I switch VPN providers to get post-quantum encryption?
Only if your data carries a confidentiality shelf-life that reaches into the quantum era. For everyday privacy use, your current provider is adequate without post-quantum protection. If your work involves multi-year source relationships, ongoing sensitive legal matters, or data whose exposure would be harmful years from now, and your current provider does not offer post-quantum encryption, switching to one that does is a reasonable step. Switching cannot protect sessions already recorded under classical key exchange: those remain permanently exposed to a future quantum adversary regardless of which provider you use from today forward.