up:: In the Protocols MOC

Virtual Private Network (VPN)

A virtual private network (VPN) is an encrypted tunnel that carries traffic securely across an untrusted network, so two endpoints can communicate as if they shared a private link even though their packets cross the public internet. A VPN is a category rather than a single algorithm, and its security comes from an underlying protocol doing the cryptography: usually IPsec (via IKEv2), a TLS-based design like OpenVPN or an SSL-VPN, or WireGuard. The quantum problem with a VPN is narrow and specific. The bulk encryption of the traffic is durable, but the tunnel’s key exchange rests on classical Diffie-Hellman math that a large quantum computer can solve, so recorded tunnel traffic is exposed to decryption later. The fix keeps the VPN and swaps that key-exchange step for a quantum-safe one.

The short version:

• A VPN is a category realized by an underlying protocol. Its cryptography, and therefore its quantum exposure, lives in IPsec (IKEv2), a TLS-based design (TLS under OpenVPN or an SSL-VPN), or WireGuard.
• The tunnel’s key exchange (classical Diffie-Hellman, ECDH, or Curve25519) is the urgent piece. It’s the harvest-now-decrypt-later exposure, because a recorded tunnel can be decrypted once a quantum computer arrives.
• Peer authentication (RSA or ECDSA signatures, or static keys) is the slower track. Forging it needs a quantum computer live during the handshake, which makes it a Non-HNDL problem, so it buys more time.
• Bulk traffic encryption (AES-256 or ChaCha20-Poly1305) survives the transition and stays in place with a large key.
• The path to quantum-safe is hybrid key exchange, and much of it arrives through vendor firmware, so gear hard-wired to one key-exchange method (WireGuard’s fixed cipher set is the extreme case) may need replacement rather than a config change.

Picture sending mail through the public postal system inside a tamper-proof, opaque, locked strongbox that only the sender and the recipient can open. Anyone can watch a box travel, and nobody can read what’s inside or even tell for certain who’s talking. The quantum risk sits in how the two sides first agreed on the key to that box, a coded exchange they carried out over an open postcard that anyone could copy. Copy the postcards today, store them, and years from now a fast enough codebreaker reconstructs the key and opens every box you saved. The box and the lock are fine. You upgrade the postcard conversation that sets the key.

What is a VPN?

A VPN is an encrypted tunnel that lets endpoints exchange traffic privately and with integrity across infrastructure they don’t trust, so a remote worker or a branch office reaches a protected network as though directly attached to it. Because a VPN wraps traffic below or around the application, one tunnel protects every protocol riding through it at once, which is why VPNs underpin remote access, site-to-site connectivity, datacenter interconnects, and partner links.

VPNs come in two deployment shapes:

1. Remote-access VPN connects a single user’s device to a corporate network, the model behind most work-from-anywhere access.
2. Site-to-site VPN connects two gateways so entire networks join across the public internet, the model behind branch connectivity and datacenter interconnects.

A VPN is a service category, and the cryptography that makes it private belongs to the protocol underneath. That’s the first thing to get straight, because “is my VPN quantum-safe?” has no single answer until you name which protocol and which mechanisms a given tunnel actually runs.

Where does the cryptography in a VPN live?

The cryptography lives in the underlying VPN protocol, and three families cover nearly every deployment. Each one does the same three cryptographic jobs, and each faces the quantum threat the same way, differing only in wire details and how much room it leaves to change algorithms.

VPN family	Underlying protocol	Key exchange	Peer authentication	Bulk encryption	Post-quantum path
IPsec VPN	IKEv2	DH / ECDH	RSA / ECDSA signatures or PSK	AES-256 in ESP	RFC 9370 hybrid, add ML-KEM
TLS-based VPN (OpenVPN, SSL-VPN)	TLS 1.3	ECDHE	RSA / ECDSA certificate signatures	AES-GCM / ChaCha20-Poly1305	hybrid TLS group
WireGuard	Noise (Noise_IKpsk2)	Curve25519 ECDH	static Curve25519 keys	ChaCha20-Poly1305	out-of-band PQ pre-shared key, or a new protocol version

The invariant across all three families is the split you already see in TLS and IPsec:

1. Key exchange agrees on the secret keys that encrypt the tunnel. Classical key exchange is broken by Shor’s algorithm, and it’s the piece an adversary can record today and decrypt later.
2. Authentication proves each endpoint’s identity with a signature or a static key. Those are also breakable by Shor’s algorithm, and a forgery only helps an attacker in real time, so there’s nothing to record.
3. Bulk encryption protects the actual traffic with a symmetric cipher. Grover’s algorithm only weakens it, and a 256-bit key answers that, so this channel is a strengthen-in-place item.

Source: J. A. Donenfeld, “WireGuard: Next Generation Kernel Network Tunnel,” and the protocol primitives (Curve25519, ChaCha20-Poly1305, BLAKE2s, no cipher agility), wireguard.com.

Source: OpenVPN, “OpenVPN Cryptographic Layer” (the TLS control channel negotiates key material for the data channel), openvpn.net.

Which parts of a VPN are quantum-vulnerable?

Two of the three cryptographic roles in a VPN are quantum-vulnerable, and they run on different clocks. This is the distinction that decides what moves first.

The tunnel’s key exchange is the urgent piece. Whether it’s finite-field Diffie-Hellman in an IPsec tunnel, ECDHE in a TLS-based VPN, or Curve25519 in WireGuard, the key exchange produces the shared secret that seeds every tunnel key. All of them rest on the discrete-logarithm problem, which Shor’s algorithm solves on a large enough quantum computer. The reason this is time-critical is timing itself. An adversary can record a tunnel’s encrypted traffic and its key-exchange messages today, store them, and derive the shared secret years later once a capable quantum computer exists. That’s harvest-now-decrypt-later, and it makes any VPN traffic that must stay confidential for a long time exposed right now, well before the quantum computer boots.

Peer authentication is the slower track. VPN endpoints prove identity with signatures (RSA or ECDSA) or with static public keys, and those are also breakable by Shor’s algorithm. Forging one, though, requires a quantum computer live at the moment the tunnel is set up, because identity only matters during the handshake. There’s nothing to harvest and no deferred payoff, which makes this a Non-HNDL trust problem rather than a confidentiality one. It still has to be fixed, on a longer runway.

Bulk traffic encryption survives. The AES-256 or ChaCha20-Poly1305 encryption of the traffic isn’t broken by Shor’s algorithm. Its only quantum concern is Grover’s algorithm, which shaves the effective margin of a brute-force search and is answered by using a large key, so the data channel is a strengthen-in-place item rather than a replacement.

Cryptographic role	Where it runs	The algorithm today	Quantum threat	Exposure class	Urgency
Key exchange	Tunnel setup handshake	DH / ECDH / Curve25519	Broken by Shor’s	HNDL, harvestable today	Highest, migrate first
Peer authentication	Handshake identity step	RSA / ECDSA signatures or static keys	Broken by Shor’s	Non-HNDL, needs a live CRQC	Slower track
Bulk encryption	The data channel	AES-256 / ChaCha20-Poly1305	Weakened by Grover’s	Retain and strengthen	Keep the cipher, large key

The upshot is that a VPN’s most important post-quantum business risk is deferred confidentiality loss from quantum-vulnerable key exchange, and it’s a quantum-vulnerable surface hiding in infrastructure many teams rarely audit at the cryptographic level.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org.

How does a VPN go post-quantum?

A VPN goes quantum-safe by upgrading the key exchange first and the authentication later, and the exact mechanism depends on the family underneath. All three routes share one idea: hybrid key exchange, running a classical and a post-quantum key agreement together so the tunnel stays secure as long as either half holds.

IPsec VPNs migrate through RFC 9370. Standard IKEv2 negotiates exactly one Diffie-Hellman group. RFC 9370, published May 2023 as a Proposed Standard, extends IKEv2 so a Security Association can perform several key exchanges and mix all of their results into one shared secret, with seven additional slots (ADDKE1 through ADDKE7) on top of the original.

A deployment negotiates the classical (EC)DH group first and adds an ML-KEM exchange in one of those slots, and the final key depends on both. Because ML-KEM values are far larger than a classical elliptic-curve value, RFC 9242’s IKE_INTERMEDIATE exchange (May 2022, Proposed Standard) carries them during setup, and the ML-KEM binding for IKEv2, draft-ietf-ipsecme-ikev2-mlkem, reached the RFC Editor queue in 2026. This is the same route covered in depth for IPsec.

TLS-based VPNs inherit the TLS path. OpenVPN and SSL-VPNs run their key exchange inside TLS, so they go quantum-safe when the underlying TLS negotiates a hybrid group, X25519MLKEM768, which pairs classical X25519 with ML-KEM-768. In practice that arrives with the VPN’s TLS library, so a TLS-based VPN linked against a post-quantum-capable build reaches hybrid key exchange the same way any TLS server does, through TLS 1.3 Hybrid Key Exchange.

WireGuard is the hard case, because it has no crypto-agility. WireGuard fixes its entire cipher set at Curve25519, ChaCha20-Poly1305, and BLAKE2s, with a hardcoded handshake construction and no versioning of algorithms, a deliberate design that trades flexibility for auditability. So there’s no hybrid group to switch on, and two routes exist instead:

1. Inject a post-quantum pre-shared key out of band. This is what Rosenpass does, running Classic McEliece and Kyber as a companion handshake that feeds WireGuard’s optional pre-shared-key slot a quantum-resistant value while WireGuard keeps handling the classical layer.
2. Move to a native post-quantum WireGuard, which requires a new protocol version rather than a configuration change.

This makes WireGuard the clearest illustration of cryptography bound into a fixed design.

An interim move for IPsec before native ML-KEM ships. RFC 8784 (June 2020, Proposed Standard) mixes a post-quantum pre-shared key into IKEv2’s key derivation, adding quantum-resistant entropy to every session without waiting for a standardized post-quantum key exchange. It’s a bridge for high-value tunnels whose gateways can’t yet negotiate ML-KEM.

Authentication migrates later. The peer-authentication signatures transition toward NIST’s standardized schemes, ML-DSA as the general-purpose choice and SLH-DSA where a conservative hash-based signature is preferred. This is harder to roll out because it touches the certificate and identity ecosystem behind the endpoints, so it moves on a longer timeline, and composite certificates let peers present both a classical and a post-quantum signature during the overlap.

ML-KEM parameter set	Public key size	Ciphertext size	Typical fit
ML-KEM-512	800 bytes	768 bytes	Constrained or latency-sensitive links
ML-KEM-768	1,184 bytes	1,088 bytes	General-purpose default
ML-KEM-1024	1,568 bytes	1,568 bytes	Highest assurance, CNSA 2.0 level for national-security systems

Sources: CJ. Tjhai, M. Tomlinson, G. Bartlett, S. Fluhrer, D. Van Geest, O. Garcia-Morchon, V. Smyslov, “Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9370, May 2023, datatracker.ietf.org.

Source: V. Smyslov, “Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2),” RFC 9242, May 2022, datatracker.ietf.org.

Source: S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov, “Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-quantum Security,” RFC 8784, June 2020, datatracker.ietf.org.

Source: NIST, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” FIPS 203, August 2024, csrc.nist.gov.

Source: Rosenpass, “Post-quantum security for WireGuard” (a companion handshake using Classic McEliece and Kyber that supplies WireGuard a post-quantum pre-shared key), rosenpass.eu.

What does migrating a VPN actually look like?

Migrating a VPN is a rollout tracked tunnel by tunnel, governed by one rule: a tunnel is only as quantum-safe as the weaker of its two endpoints. Both ends have to support the same post-quantum key exchange for a session to negotiate it, and because VPN termination is concentrated in appliances and managed services, the migration is really about getting new cryptography supported across a population of gateways that someone other than the data owner often controls.

The reality has a few defining features:

1. The weakest-endpoint rule. If one endpoint offers ML-KEM and the peer doesn’t, the negotiation falls back to a classical group and the HNDL exposure stays open for that tunnel. Coverage across both ends closes it, so a partner tunnel or a legacy branch gateway that hasn’t moved reopens the door for everything behind it.
2. Firmware sets the pace. VPNs terminate on concentrators, firewalls, SD-WAN and SASE appliances, and cloud networking gateways, and support for hybrid key exchange arrives when the vendor ships firmware that implements it. These are vendor surfaces, and appliance refresh cycles are measured in years.
3. Fixed cryptography forces replacement. A gateway with crypto-agility can negotiate a new key-exchange group and retire an old one in place. Gear hard-wired to one method, an appliance with baked-in crypto or a WireGuard deployment with its fixed cipher set, has to be replaced or re-architected before it can move at all, because a config change can’t reach its cryptography.
4. Both sides of a site-to-site tunnel move together. A tunnel between two organizations or two internal sites is a coordinated change on both ends, which turns a technical upgrade into a scheduling-and-contracts problem across owners.
5. Visibility is harder than it looks. The presence of a VPN says nothing about which key-exchange group or authentication method a given tunnel actually negotiated. Seeing the true cryptographic posture takes configuration-level and negotiated-parameter inspection, which is the evidence a CBOM is built to capture.

What are the interop and deployment traps?

The traps cluster around the size of post-quantum key material and the age of the gear in the path. Three come up repeatedly:

1. Oversized handshakes. An ML-KEM public key or ciphertext runs from roughly 800 bytes to over 1,500 bytes, where a classical elliptic-curve value is tens of bytes. In IPsec that’s why RFC 9242’s IKE_INTERMEDIATE exchange exists, and in a TLS-based VPN it’s the oversized ClientHello. A deployment that carries the larger values without that plumbing runs straight into fragmentation, dropped packets, and stalled tunnels.
2. Silent fallback and middleboxes. Fallback to a classical algorithm is designed to be seamless, so a tunnel that quietly dropped to classical key exchange looks identical to a protected one, which makes confirming the negotiated group a distinct step from enabling it. Firewalls, NAT devices, and older concentrators written before large handshakes were common can also mishandle the bigger messages, so rollouts have to test the whole path end to end.
3. Constrained links raise a parameter-versus-latency tension. On satellite and other bandwidth- or latency-constrained links, the extra round trip and larger payloads become a real cost, and MTU limits can cap the achievable parameter size. Research on quantum-safe IKEv2 for satellite links shows latency-optimal configurations gravitating to ML-KEM-512 or ML-KEM-768 to stay MTU-safe, which collides with the CNSA 2.0 direction toward ML-KEM-1024 for national-security systems.

How urgent is a VPN migration?

VPN key exchange is one of the more time-sensitive items in the transition, and Mosca’s theorem is the clean way to see it. Mosca frames the decision as three numbers: X, how long the tunnel-protected data must stay confidential; Y, how long the migration takes; and Z, how long until a capable quantum computer exists. When X plus Y is greater than Z, the data is already exposed.

VPNs often carry long-lived, high-value infrastructure traffic, datacenter interconnects, partner data exchange, and administrative channels, and the migration Y is long because it depends on vendor firmware and cross-organization coordination. For anything that must stay secret for a decade, the harvestable window is open now, which is why VPN key exchange belongs in the early phase of a transition rather than a later cleanup. The authentication side is genuinely less urgent, because it’s a live-trust problem with nothing to harvest, so the honest prioritization is key exchange first and signatures on a longer runway.

Common misconceptions

• “We run a VPN, so we’re covered.” A working VPN tells you a tunnel exists, and it says nothing about which key-exchange group or authentication method it negotiated. A tunnel using classical ECDH is fully functional and fully harvestable at the same time.
• “Quantum computers break the VPN.” The tunnel and its bulk cipher hold. The vulnerable parts are the key exchange and the peer-authentication signatures, and the fix swaps those mechanisms while keeping the VPN and its data channel.
• “Turning on post-quantum key exchange is just a config flag.” For an IPsec or TLS gateway with crypto-agility, enabling a hybrid group is close to a config change. For fixed-firmware appliances and WireGuard’s fixed cipher set, the upgrade needs new firmware, a new protocol version, or replacement.
• “WireGuard is modern, so it’s quantum-safe.” WireGuard’s fixed Curve25519 handshake is exactly the harvestable piece, and its no-agility design means the post-quantum path is an out-of-band pre-shared key (Rosenpass) or a new protocol version rather than a setting.
• “The authentication problem is the one to fix first.” It’s the reverse. Peer-authentication signatures need a quantum computer live during setup, so there’s nothing to harvest. The key exchange is harvestable today, which makes it the piece to migrate first.
• “The bulk cipher needs replacing too.” It needs a large key, not a new algorithm. AES-256 and ChaCha20-Poly1305 keep a comfortable margin against Grover’s algorithm, so the data channel is a strengthen-in-place item.

Questions people ask

What actually changes in a VPN for post-quantum? The tunnel’s key exchange changes first. An IPsec VPN adds an ML-KEM exchange alongside classical (EC)DH under RFC 9370, a TLS-based VPN negotiates a hybrid TLS group like X25519MLKEM768, and WireGuard gains a post-quantum pre-shared key out of band. Peer-authentication signatures change later toward ML-DSA or SLH-DSA, and the bulk traffic encryption stays the same with a large key.

Do I have to replace my VPN? Often not. An IPsec or TLS-based VPN with crypto-agility is modernized in place by upgrading the key-exchange mechanism, mostly through gateway or appliance firmware and library updates. Replacement becomes necessary for gear hard-wired to one method, appliances with baked-in crypto, or a WireGuard deployment whose fixed cipher set can’t negotiate anything new.

Is my VPN’s traffic being harvested right now? Possibly, if it uses classical key exchange and an adversary is recording it. That’s the harvest-now-decrypt-later problem: the traffic is captured today and decrypted once a quantum computer exists, so any VPN data with a long confidentiality lifetime is a present liability even though no quantum computer exists yet.

Which VPN is easiest to make quantum-safe? A TLS-based VPN and an IPsec VPN with crypto-agility are the most straightforward, because they inherit hybrid key exchange from a library or firmware update. WireGuard is the hardest, because its fixed design leaves no algorithm to switch, so its post-quantum route is an external construction or a new protocol version.

Is WireGuard quantum-safe? Not on its own. WireGuard’s Curve25519 handshake is quantum-vulnerable, and the protocol has no cipher agility, so the practical route today is a companion tool such as Rosenpass that supplies WireGuard a post-quantum pre-shared key while WireGuard handles the classical layer.

What can I do before post-quantum firmware ships? For IPsec, RFC 8784 mixes a post-quantum pre-shared key into IKEv2’s key derivation, adding quantum-resistant entropy to every session without a standardized post-quantum key exchange. It’s a bridge for high-value tunnels whose gateways can’t yet negotiate ML-KEM natively.

Which ML-KEM parameter set should a tunnel use? ML-KEM-768 is the sensible general-purpose default. National-security systems under CNSA 2.0 are directed to ML-KEM-1024. Constrained and high-latency links, such as satellite, sometimes settle on ML-KEM-512 or ML-KEM-768 to stay within MTU limits, which trades some parameter strength for link budget.

Is post-quantum VPN deployable today? For key exchange, yes in large part. Hybrid IPsec is standardized in RFC 9370 with vendor firmware catching up, hybrid TLS ships in current TLS libraries so TLS-based VPNs can inherit it, and WireGuard has the Rosenpass route. Post-quantum authentication signatures and FIPS-validated modules trail behind on their own timelines, and availability in practice tracks whether your specific vendor has shipped support.

---

Everything here is the map, given freely. When your team needs its own VPN estate found, its harvestable tunnels prioritized, and a hybrid rollout sequenced across every gateway, appliance, and partner endpoint, defensible to your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.