PQC StatusOn a VPN, the part exposed to a future quantum attacker is the key exchange, not the bulk encryption. For IPsec there are two published IETF mechanisms you can use today: RFC 9370, which lets IKEv2 negotiate additional key exchanges so a post-quantum KEM (key encapsulation mechanism) runs alongside a classical group, and RFC 8784, which mixes a post-quantum pre-shared key into IKEv2 key derivation. WireGuard has no post-quantum key exchange in the protocol itself, so its optional 32 byte symmetric pre-shared key is the only lever inside the protocol.
Why the key exchange comes first
An IPsec tunnel has two layers. ESP (Encapsulating Security Payload) protects the data with a symmetric algorithm, typically AES-256-GCM. Symmetric algorithms and hashes are not broken by Shor's algorithm, and Grover's algorithm is the reason AES-256 is preferred for long-term protection. The IKE (Internet Key Exchange) layer is different: IKEv2 as published in RFC 7296 derives its keys from a Diffie-Hellman exchange, and elliptic curve Diffie-Hellman and finite-field Diffie-Hellman are broken by Shor's algorithm on a large enough quantum computer, whatever the group size.
That matters now because of harvest now, decrypt later (HNDL): an attacker who records encrypted tunnel traffic today only needs the key exchange to fall later to read it. Site-to-site tunnels carrying data with a long confidentiality lifetime (health records, legal files, industrial designs, payment data) are the clearest case. Authentication is a separate question. IKEv2 peer authentication with RSA or ECDSA certificates only has to resist an attacker present at the time of the handshake, so signatures can migrate after the key exchange, but they do have to migrate.
The three mechanisms available today
| Mechanism | Specification | What it changes | What it requires |
|---|---|---|---|
| IKEv2 additional key exchanges | RFC 9370, using the IKE_INTERMEDIATE exchange of RFC 9242 | A post-quantum KEM is negotiated in band, in addition to the classical group | Both peers support it, a registered key exchange method for the KEM, IKEv2 fragmentation |
| Post-quantum pre-shared key (PPK) mixing | RFC 8784 | A high entropy secret is mixed into IKEv2 key derivation, so a recorded exchange is not enough | Out-of-band distribution, storage and rotation of one PPK per peer pair |
| WireGuard pre-shared key | WireGuard protocol documentation (the PresharedKey option) | A 32 byte symmetric key is mixed into the handshake chaining key | Out-of-band distribution per peer pair, no in-band negotiation |
| ESP payload protection | AES-256-GCM | Nothing: already outside Shor's reach | Prefer AES-256 for long-term protection |
RFC 9370: additional key exchanges in IKEv2
Base IKEv2 negotiates exactly one key exchange method, in the IKE_SA_INIT exchange. RFC 9370 adds up to seven further key exchange transform types (commonly written ADDKE1 to ADDKE7) which are negotiated in the same proposal and then performed in one or more IKE_INTERMEDIATE exchanges, the exchange type defined in RFC 9242. The resulting shared secrets are combined into the IKE SA key material, so keeping a classical group as the first key exchange and adding a KEM as ADDKE1 gives a hybrid: an attacker has to break both. Hybrid is what ANSSI and BSI recommend, and it is the conservative choice while post-quantum implementations are young.
The KEM to ask for is ML-KEM, standardized by NIST in FIPS 203 on 2024-08-13. ML-KEM-768 is the common middle parameter set; CNSA 2.0 requires ML-KEM-1024. The authoritative list of IKEv2 key exchange method identifiers is the IANA IKEv2 parameters registry, and the work to specify ML-KEM for IKEv2 is in the IETF IPSECME working group, so read the registry and your implementation's documentation rather than trusting a transform number quoted in an article.
Two operational consequences. First, ML-KEM public keys and ciphertexts are far larger than an elliptic curve point, so IKEv2 message fragmentation (RFC 7383) should be enabled. One reason RFC 9370 uses IKE_INTERMEDIATE is that those exchanges can be fragmented, unlike IKE_SA_INIT. Second, proposal syntax differs between implementations and versions, and the keyword spelling for a post-quantum additional key exchange is not portable. Verify it in the documentation for your exact version:
# Illustrative shape only, not a portable configuration line.
# Order: encryption - integrity/PRF - classical group - additional key exchange 1
# aes256gcm16 - prfsha384 - <classical group> - <ML-KEM as ADDKE1>
# The keyword for the additional key exchange depends on the implementation
# and its version. Take it from that version's documentation.Read-only checks on a Linux gateway, before and after a change, show what the kernel actually installed:
# List the IPsec security associations and the ESP algorithms in use
ip -s xfrm state
# Show the installed IPsec policies
ip xfrm policyTest in staging first, with the peers you really use, and keep a classical-only proposal as a documented fallback until every peer is migrated.
RFC 8784: mixing a post-quantum pre-shared key
RFC 8784 takes a different route. The initiator signals support with a USE_PPK notification, and a post-quantum pre-shared key, identified by a PPK_ID, is mixed into the IKE SA key derivation. An attacker who records the exchange and later breaks the Diffie-Hellman part still cannot derive the session keys without the PPK. It is useful precisely because it needs no new asymmetric algorithm: many deployed IKEv2 stacks can do it.
The limits are operational rather than cryptographic. The PPK must have real entropy and must be generated by a proper random source, not typed by a human. It has to be distributed, stored and rotated out of band, per peer pair, which is the hard part at scale. It does not make peer authentication post-quantum. And RFC 8784 allows the PPK to be mandatory or optional: if it is optional, a peer that does not send USE_PPK simply gets a classical SA. Where both ends support it, configure it as mandatory, and log which peers negotiated a PPK so you can prove coverage rather than assume it.
WireGuard today
WireGuard's handshake is built on Curve25519, so the key exchange is quantum-vulnerable in the same way IKEv2 with a classical group is. The protocol has no negotiation layer and no algorithm agility by design, so there is no post-quantum key exchange to turn on. What exists is the optional symmetric pre-shared key, mixed into the handshake, which the WireGuard protocol documentation presents as mitigation against an attacker who records traffic now and attacks the public keys later.
# Generate one 32 byte pre-shared key per peer pair
wg genpsk
# In a wg-quick configuration file, add it to the peer section
# [Peer]
# PublicKey = <peer public key>
# PresharedKey = <output of wg genpsk>
# AllowedIPs = 10.0.0.2/32Treat the result as a secret with a lifecycle: unique per pair, delivered over a channel you trust, rotated, and recorded in your key inventory. Some projects run an external daemon that performs a post-quantum key exchange separately and periodically refreshes the PresharedKey value (Rosenpass is one open source example of that pattern). That leaves WireGuard itself untouched, at the cost of one more component to deploy, monitor and audit. If you need in-band negotiation of a standardized KEM, IPsec with RFC 9370 is the path that exists today.
What to ask VPN suppliers
| Question | Why it matters |
|---|---|
| Which post-quantum key exchange methods does the IKE implementation support, in which firmware version, and under which IANA key exchange method identifiers? | Turns a marketing claim into something you can test and record |
| Do you implement RFC 9370 with RFC 9242, RFC 8784, or both? | In-band hybrid KEM and manual PPK mixing solve the problem differently |
| Is the key exchange hybrid, and which ML-KEM parameter set? | Hybrid is the recommended posture; CNSA 2.0 requires ML-KEM-1024 |
| Is the implementation validated against FIPS 203, or does it use a validated module? | Required by some procurement and audit regimes |
| Is IKEv2 fragmentation enabled, and what is the measured effect on rekey rate, CPU and tunnel setup time? | Larger KEM payloads change IKE packet sizes and gateway load |
| What happens when a peer does not support the post-quantum exchange, and can that be logged or alerted on? | You need visibility on silent fallback to a classical-only SA |
| Which interoperability tests have been run against the specific peers we use (cloud gateways, partner devices, remote access clients)? | Hybrid IKEv2 interoperability is where deployments stall |
| What is the roadmap for post-quantum peer authentication (ML-DSA certificates)? | Key exchange first, signatures next, but both are needed |
| Will current hardware get it, or only the next generation? | Crypto accelerators sized for elliptic curves may not do ML-KEM |
| What written evidence will you provide: release notes, test reports, supported configuration? | This is what goes into your cryptographic inventory |
The dates that apply to network equipment
VPN gateways are called out explicitly in one timeline. NSA CNSA 2.0, which applies to US National Security Systems, sets exclusive use of its algorithm set (ML-KEM-1024 among them) by the end of 2030 for software and firmware signing and for traditional networking equipment, and by the end of 2033 for web browsers and servers, cloud services, operating systems and niche equipment. Networking equipment is in the earlier group.
Elsewhere, BSI TR-02102-1 (version 2026-01, published 2026-01-23) recommends hybrid post-quantum key agreement and considers classical key agreement used alone acceptable only until the end of 2031, or the end of 2030 for very high protection needs; it is a technical guideline, not a regulation. ANSSI makes hybridation mandatory inside its regulated scope (product qualification, Diffusion Restreinte, SAIV and SIIV) and states that its post-quantum recommendations are not yet regulatory obligations elsewhere (ANSSI PQC FAQ). The EU Coordinated Implementation Roadmap v1.1 (2025-06-23) asks for cryptographic inventories and national roadmaps by the end of 2026 and migration of high-risk use cases by the end of 2030; it is coordinated guidance for Member States, not a regulation binding companies. UK NCSC (2025-03-20) expects discovery and an initial plan by 2028, highest-priority migrations by 2031 and completion by 2035. NIST IR 8547 remains an initial public draft: it proposes deprecating 112-bit-security algorithms such as RSA-2048 after 2030 and disallowing all quantum-vulnerable public-key algorithms after 2035.
Our reading, offered as interpretation and not as legal advice: a long-lived site-to-site tunnel carrying regulated data is the kind of high-risk use case these timelines point at first, which puts the VPN estate early in the queue even where the text is a recommendation rather than an obligation.
Next step
Start with inventory, because that is what every one of these texts asks for: list each tunnel, the IKE version, the negotiated key exchange group, the ESP algorithms, the authentication method and the confidentiality lifetime of the data it carries. Then pick one low-risk tunnel between two peers you control and test a hybrid proposal in staging, with a classical fallback left in place.
PQC Status tests TLS, not IKEv2, so it will not tell you what your gateway negotiates on UDP 500 and 4500. It is still the fastest check on everything a VPN estate exposes over HTTPS: appliance web portals, SSL-VPN front ends, management and enrolment interfaces. Run a free scan of those hostnames with PQC Status to see whether they already offer a hybrid ML-KEM key exchange, then send the supplier questions above to the vendor of each gateway.