Vendor compatibility
WireGuard post-quantum VPN support
The WireGuard protocol and its in-kernel and userspace implementations, used for site-to-site and infrastructure tunnels.
Last reviewed
1 compatibility record
Direct answer
The WireGuard protocol specifies Curve25519 for its Noise_IK handshake and defines no post-quantum key establishment of its own. It does support an optional pre-shared symmetric key mixed into the handshake, which the protocol documentation presents as the mechanism for adding post-quantum resistance. That optional key must be distributed and rotated out of band, which is an operational commitment rather than a configuration flag.
Practical status
What this means in a real estate
WireGuard's cryptographic agility is deliberately close to zero: the protocol names its primitives rather than negotiating them, which is why it is simple and fast, and also why there is no proposal to migrate. The available lever is the optional pre-shared key. In an enterprise estate the question is therefore not whether the software supports a new key exchange, but whether the organisation can operate symmetric key distribution and rotation at the scale of its WireGuard peer set.
What to establish about key exchange
The protocol's handshake uses Curve25519 ECDH. Post-quantum resistance is obtained by enabling the optional pre-shared key, which is mixed into the handshake alongside the public key cryptography. This is a symmetric mechanism and its security depends entirely on how the key is generated, distributed and rotated.
Why authentication is a separate question
WireGuard authenticates peers by static public key. Enabling the optional pre-shared key adds a shared symmetric secret to the handshake but does not introduce post-quantum peer authentication, and the static public key model remains as it was.
Products and versions
Compatibility records
Each record is scoped to a product and a version range. Key establishment and authentication are stated separately, because they migrate on different timelines through different mechanisms.
| Product | Key establishment |
|---|---|
| WireGuard protocol (in-kernel and userspace implementations) | Post-quantum key establishment: Unsupported |
WireGuard protocol (in-kernel and userspace implementations)
All implementations of the current protocolThe protocol specifies Curve25519 for its Noise_IK handshake and defines no post-quantum key exchange. The protocol documentation states that where an additional layer of symmetric-key cryptography is required, for example for post-quantum resistance, WireGuard supports an optional pre-shared key mixed into the public key cryptography. That optional key is the only in-protocol lever available.
Migration implication: For WireGuard the migration decision is organisational rather than technical: either commit to operating symmetric key distribution and rotation across the peer set, or move the connections that need negotiated post-quantum key establishment to IKEv2.
Caveats
- The protocol does not negotiate primitives, so there is no gradual in-tunnel migration path
- The security benefit depends entirely on how the symmetric key is managed
- A pre-shared key stored beside the configuration it protects adds little
Last reviewed · medium confidence · 2 sources
Prerequisites
Establish these before assessing migratability.
- An inventory of every WireGuard peer relationship in the estate
- A decision on how pre-shared keys will be generated, stored and distributed
- A rotation policy and an owner for it
- Confirmation that all implementations in use support the pre-shared key option
Peer compatibility
A tunnel is governed by the weaker of its two peers.
- The pre-shared key must be configured identically on both peers or the handshake fails
- Every peer relationship needs its own key if compromise is to be contained
- Mixed implementations must all support the option before it is enabled
Operational limitations
Constraints that shape the plan rather than block it.
- No in-protocol negotiation means no gradual migration path within a single tunnel
- Symmetric key distribution and rotation is an ongoing operational burden
- A pre-shared key stored alongside the configuration it protects provides little benefit
Migration paths
The routes available when the current state is not the target.
- Enable the optional pre-shared key with a managed distribution and rotation process
- Replace WireGuard with an IKEv2 implementation where negotiated post-quantum key establishment is required
- Layer WireGuard inside an IPsec tunnel that provides the required key establishment
- Defer and track, with the symmetric key management dependency recorded explicitly
Verification requirements
What must be evidenced before a change is recorded as complete.
- Confirm that the pre-shared key is configured on both peers and that handshakes complete
- Confirm key provenance and rotation records, since the mechanism's value rests on them
- Re-verify after any peer reconfiguration
Sources
- 1. WireGuard Protocol & Cryptography(opens in a new tab)
WireGuard · verified by PQVPN
Individual compatibility records carry their own sources, listed against each record in the compatibility matrix.
Need this mapped to your actual WireGuard estate?
A readiness assessment establishes the exact release, licence and peer position for every gateway you run — and tells you which tunnels can move first.