Post-Quantum Cryptography and Your VPN: Is Data at Risk?

Post-quantum cryptography (PQC) is a new generation of encryption designed to survive attacks from quantum computers. For a business VPN, it matters because a future quantum computer could break the math that protects encrypted tunnels today. The risk to VPN traffic is real but manageable, and the migration path to a quantum-safe VPN is already taking shape. This guide covers what post-quantum cryptography is, why it matters for VPN key exchange, and exactly what a post-quantum VPN migration involves — including the specific algorithms (ML-KEM, ML-DSA, SLH-DSA) and the rollout steps admins need to plan for.

New to the quantum threat in general? Our companion piece, Cybersecurity in the Quantum Age, covers why quantum computing matters for cybersecurity broadly and how OpenVPN's existing protections (TLS Crypt, Perfect Forward Secrecy) already reduce exposure. This guide picks up from there with the technical migration details.

What is post-quantum cryptography?

Post-quantum cryptography is a set of encryption algorithms built to resist attacks from both classical and quantum computers.

Most encryption in use today — the kind that secures web traffic, VPNs, and stored data — relies on math problems that ordinary computers can't solve quickly, such as factoring very large numbers (RSA) or solving discrete logarithms (elliptic-curve cryptography, or ECC). A sufficiently powerful quantum computer running Shor's algorithm could solve those problems fast, breaking RSA and ECC in a way that isn't possible today.

To get ahead of that, the U.S. National Institute of Standards and Technology (NIST) ran a multi-year competition and, in 2024, published the first finalized PQC standards. The three most relevant ones are ML-KEM (key exchange), ML-DSA (digital signatures), and SLH-DSA (hash-based signatures). These are the post-quantum encryption algorithms vendors are now building into their products.

Why should you care? The "harvest now, decrypt later" threat

The most important thing to understand about the quantum threat is that you don't have to wait for quantum computers to exist to be affected by them.

The strategy security researchers worry about is called harvest now, decrypt later (HNDL). An adversary captures encrypted data today — quietly, without breaking anything — and simply stores it. Years from now, when quantum computers are capable enough, they go back and decrypt the archive. There's no alarm, no ransom note, and no sign of a breach at the time of capture. The data just sits in someone else's storage, waiting.

That changes the timeline. If information you send today still needs to be secret in five, ten, or twenty years, then today's encryption already has to be strong enough to survive tomorrow's computers.

Does the quantum threat actually apply to VPN traffic?

This is where nuance matters. VPN traffic is data in transit, and most of it is a medium-risk target for HNDL — not the highest priority, but not zero either.

Here's why the risk is moderate rather than severe. A well-configured VPN uses forward secrecy: every session negotiates a fresh, temporary key, so no single long-term key unlocks past sessions. A lot of tunneled traffic is also short-lived and low-value — routine web browsing, brief app sessions, transient system chatter — where the payload has little worth by the time a quantum computer could crack it.

But "medium" is not "none," for two reasons:

The key exchange itself is harvestable. An attacker who records a tunnel's handshake and ciphertext can, with a future quantum computer, break that specific session's key agreement and decrypt that session's payload. Forward secrecy limits the blast radius; it does not make a captured session immune to being cracked later.

Some tunnels carry long-lived, sensitive data. VPNs don't just carry web browsing. They carry file transfers, database replication, backups, admin credentials, health and financial records, and intellectual property — exactly the kind of long-shelf-life data that HNDL targets.

So the practical takeaway is: don't panic, but don't ignore it. The parts of your VPN worth prioritizing are the tunnels that carry data which must stay confidential for years.

What does this mean for your business VPN?

Three practical implications follow from all of this.

First, the key exchange is the piece to upgrade first. Quantum computers threaten how the two ends of a tunnel agree on a shared secret. Protecting that agreement with a quantum-safe algorithm is the single most valuable change you can make.

Second, both ends have to support it. A quantum-safe handshake requires PQC-capable software on the server and the client. Upgrading one side alone doesn't produce a quantum-safe tunnel.

Third — and this is the part teams most often overlook — going post-quantum is not a switch you flip. Existing connection profiles and configurations were generated before PQC existed. They will keep negotiating the old, classical ciphers until they're replaced. Turning on PQC on your servers does not retroactively upgrade the profiles already deployed to your users.

How VPNs go post-quantum: hybrid key exchange

The industry isn't ripping out classical cryptography and dropping in PQC overnight. The standard transition approach is hybrid key exchange.

A hybrid handshake runs a classical algorithm (such as X25519) and a post-quantum one (such as ML-KEM) together, combining both into the session key. The connection stays secure as long as either algorithm holds up.

Why bother with both? Because the PQC algorithms are new. They were only standardized in 2024 and haven't yet faced the decades of public analysis that RSA and ECC have. Hybrid mode is an insurance policy: you get quantum resistance now, but if a weakness is ever found in the new algorithm, the proven classical layer still protects you. This is why OpenSSL 3.5 — a foundational cryptographic library that many VPNs, web servers, and applications depend on — ships hybrid PQC key exchange (the group X25519MLKEM768) as its default.

What migrating to a quantum-safe VPN involves

At a high level, moving a business VPN to post-quantum protection looks like this:

Upgrade the server-side crypto stack to a version that supports PQC (in practice, OpenSSL 3.5 or later).

Enable the PQC-capable ciphers so servers offer quantum-safe key exchange.

Update the client software so users' devices can negotiate the new handshake.

Replace the pre-PQC profiles. Regenerate and redistribute connection profiles so users actually connect with the new ciphers instead of the old ones.

Step 4 is the one that takes planning. The technology change is straightforward; the rollout — reissuing profiles across a fleet of users and confirming everyone has migrated — is the real project. If you're running Access Server or CloudConnexa, treat profile reissuance as its own project milestone, not an afterthought to a server upgrade.

Frequently asked questions

What is post-quantum cryptography, in one sentence?

Encryption designed to stay secure even against attackers using quantum computers.

What is "harvest now, decrypt later" (HNDL)?

An attack strategy where an adversary captures encrypted data today and stores it, planning to decrypt it years later once quantum computers are powerful enough. It means data with a long confidentiality shelf life is already at risk, even though quantum computers can't break it yet.

What is ML-KEM (Kyber)?

ML-KEM (formerly called Kyber, standardized as NIST FIPS 203) is the leading post-quantum key exchange algorithm — the mechanism two endpoints use to agree on a shared secret. For VPNs, this is the most important PQC algorithm, because key exchange is the primary quantum target.

What is ML-DSA (Dilithium)?

ML-DSA (formerly Dilithium, NIST FIPS 204) is a post-quantum digital signature algorithm, used to prove authenticity — for example, in certificates that verify a server's identity.

What is SLH-DSA (SPHINCS+)?

SLH-DSA (formerly SPHINCS+, NIST FIPS 205) is a second post-quantum signature algorithm, built on hash functions. It's more conservative and time-tested in design, at the cost of larger signatures.

What is hybrid key exchange (X25519MLKEM768)?

A handshake that combines a classical algorithm (X25519) with a post-quantum one (ML-KEM-768) so the session is protected if either one holds up. X25519MLKEM768 is the specific hybrid group that OpenSSL 3.5 uses by default. Hybrid mode is the recommended transition approach because the newer PQC algorithms haven't yet had decades of scrutiny.

What is forward secrecy, and does it protect me from quantum attacks?

Forward secrecy means each session uses a fresh, temporary key, so compromising one long-term key doesn't expose past sessions. It reduces HNDL risk but doesn't eliminate it: an attacker can still record a session and later use a quantum computer to break that specific session's key exchange. That's why PQC key exchange is still needed on top of forward secrecy.

What's the difference between a "cipher" and a "profile"?

A cipher (or algorithm) is the underlying math that encrypts and negotiates a connection — for example, ML-KEM. A profile is the configuration file a VPN client uses to connect, which specifies, among other things, which ciphers to use. Enabling new ciphers on your servers doesn't change the profiles already in the field.

Why do pre-PQC profiles need to be replaced?

Because a profile generated before PQC support was added will keep requesting the old, classical ciphers. Even after your servers support quantum-safe key exchange, existing users won't benefit until their profiles are regenerated and redistributed. Profile replacement is a required step in any VPN PQC migration, not an optional one.

Is my current VPN traffic at risk today?

Not from decryption today — no quantum computer can currently break your VPN's encryption. The risk is future decryption of traffic captured today (HNDL). The exposure is highest for tunnels carrying data that must remain confidential for many years.

What is OpenVPN's plan for post-quantum cryptography?

OpenVPN is working toward post-quantum support across its product line — Access Server, CloudConnexa, and the OpenVPN Connect app. The overall direction is the same in each case: add access to NIST-standardized PQC ciphers (hybrid key exchange first), publish migration guidance so administrators can move users onto the new ciphers, and progressively make PQC the default for new deployments. The specifics and timing below are directional and subject to change, because availability depends on an underlying dependency (explained in the next question).

Access Server: The plan is to enable a post-quantum handshake via a server configuration directive once the required OpenSSL version is available on the host operating system — that is, on operating systems that ship OpenSSL 3.5 or later.

CloudConnexa: Because CloudConnexa is cloud-delivered, the plan is for multitenant servers to run on an OpenSSL 3.5-capable stack, with PQC options exposed to administrators in the Admin portal.

OpenVPN Connect app: The plan is to add PQC support in a future release, tied to OpenSSL 3.6 support in the client.

These are planned directions rather than committed release dates.

Why does PQC availability depend on OpenSSL and the operating system?

OpenVPN relies on OpenSSL as its underlying cryptographic library, and the NIST post-quantum algorithms first became available in OpenSSL 3.5 (released in 2025, with hybrid PQC key exchange on by default). On Linux, OpenVPN typically uses the OpenSSL version packaged with the operating system, so post-quantum capability generally arrives when your OS ships OpenSSL 3.5 or later. That's why the timeline is best described directionally: it moves in step with OpenSSL and operating-system release cycles.

Get ready for the quantum-safe migration

Whether you run a self-hosted Access Server deployment or a cloud-delivered CloudConnexa network, the earlier you plan for profile reissuance, the smoother your post-quantum migration will be. Get started for free to see how OpenVPN is building toward a quantum-safe default.