The question comes up every time quantum computing makes the news: does my VPN still protect me? For WireGuard the honest answer requires separating what the protocol does today from what a standards body has published, because they are not the same thing.
The part that is genuinely vulnerable
WireGuard's handshake is built on Curve25519. Elliptic-curve key exchange is exactly the family of cryptography a large quantum computer would break, which is why the question is being asked at all.
This is not a flaw in WireGuard. It is the state of nearly all deployed key exchange, and it is why NIST ran a multi-year process to standardise replacements.
What NIST actually standardised
On 13 August 2024, NIST published FIPS 203, which specifies a key-encapsulation mechanism called ML-KEM.
A KEM does one specific job: it lets two parties establish a shared secret key over a public channel, which can then be used for ordinary symmetric encryption and authentication. Its security rests on the Module Learning with Errors problem and, in the standard's careful phrasing, it is believed to be secure, even against adversaries who possess a quantum computer.
The standard defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security strength and decreasing performance. Note the phrasing throughout: believed to be secure. That is how cryptographers write, and it is worth reading literally rather than as marketing hedging.
What WireGuard offers instead
WireGuard does not implement ML-KEM. What its protocol page describes is an optional pre-shared key, to be used if an additional layer of symmetric-key crypto is required (for, say, post-quantum resistance).
Three details matter here.
It is mixed in, not substituted. The pre-shared key is combined with the public key cryptography during key derivation. An attacker therefore needs both to break Curve25519 and to hold the shared secret. The elliptic curve is not removed, it is backed up.
It is off by default. When pre-shared key mode is not in use, the value is treated as an all-zero string of 32 bytes. Nothing happens unless you configure it.
The documentation itself hedges. The phrase is for, say, post-quantum resistance. That "say" is doing real work: the page offers the use case as an example rather than a guarantee, and states no formal security claim about quantum adversaries. A protocol that wanted to advertise post-quantum safety would not phrase it that way.
The distinction that decides everything
Both approaches end with a shared secret, but they solve opposite halves of the problem.
ML-KEM establishes a secret between parties who have never met, over a channel anyone can watch. That is the hard problem, and it is what a quantum computer threatens.
WireGuard's pre-shared key assumes the secret already exists. You have to get 32 bytes to both peers by some other route, safely, and keep it safe afterwards.
So the pre-shared key is a real mitigation, and it is not the same thing as post-quantum key establishment. If you can distribute secrets out of band, it works. If you cannot, it does not help, and no amount of enabling it changes that.
What to actually do
Enable it if you control both ends. Site-to-site tunnels, your own servers, a handful of devices you administer: the key distribution problem is small and the mitigation is real. It addresses the harvest-now-decrypt-later concern, where traffic captured today is stored until a quantum computer exists.
Weigh the operational cost honestly. Every peer pair needs its own key, distributed safely, rotated, and protected. A leaked pre-shared key is worse than none, because it removes the layer you thought you had while you keep believing it is there.
Do not expect your commercial VPN to offer it. The pre-shared key model fits infrastructure you own, not a provider serving thousands of clients. If a provider claims post-quantum protection, the useful question is which mechanism, and whether it is ML-KEM or something they named themselves.
The honest summary
WireGuard is not post-quantum secure by default, and its handshake rests on Curve25519, which quantum computing threatens directly.
Its answer is an optional pre-shared key, mixed into the existing cryptography, off unless configured, and described by its own documentation with a deliberate say rather than a promise. NIST's ML-KEM, standardised in FIPS 203 on 13 August 2024 with three parameter sets, solves the harder problem of establishing a secret in the first place.
Use the pre-shared key where you can distribute keys safely. Do not mistake it for the standard, and be sceptical of anyone who blurs the two.
The ML-KEM description, the FIPS 203 publication date of 13 August 2024, the three parameter sets, the Module Learning with Errors basis and the phrase about being believed secure against adversaries who possess a quantum computer are taken from NIST's published page for FIPS 203. The optional pre-shared key, its stated purpose, its mixing into the public key cryptography and the all-zero 32-byte default are taken from the WireGuard protocol documentation. Both were checked at the time of writing. Commercial links carry the rel="sponsored nofollow" attribute; an affiliate commission may apply at no extra cost to you.
Secure your connection with NordVPN
Threat Protection blocks trackers & malware · kill switch · 30-day money-back
