Can an always-on VPN post-quantum device tunnel work?

An always-on VPN post-quantum device tunnel is a machine-authenticated tunnel that comes up before anyone signs in. Its session keys come from a hybrid exchange that combines classical (EC)DH with ML-KEM. Because of that, traffic recorded today, including pre-logon domain traffic, can’t be decrypted later by an attacker with a quantum computer.

For organisations that run OT and critical infrastructure, the device tunnel is often the most sensitive remote connection they have. It carries the engineering laptop’s domain authentication, policy refresh and certificate renewal, and it does this on hotel, home and mobile networks. NIST’s remote access guidance tells organisations to assume that the networks between the telework client device and the organization cannot be trusted. That premise applies even more strongly when the adversary can store traffic for a decade.

Can an always-on VPN device tunnel use hybrid ML-KEM before the user logs in?

Yes, but only if the client stack that brings up the pre-logon tunnel and the gateway both support a hybrid key exchange. The protocol standards allow it. Whether it works in practice depends on whether the OS-native or installed client actually implements it.

What the standards allow

Device tunnels are usually built on IKEv2, defined in RFC 7296. RFC 9370 extends IKEv2 to allow multiple key exchanges to take place while computing a shared secret during Security Association setup, typically one classical (EC)DH and the other a post-quantum algorithm. ML-KEM, specified in FIPS 203, fills the post-quantum slot. FIPS 203 specifies three parameter sets which, in order of increasing security strength and decreasing performance, are ML-KEM-512, ML-KEM-768 and ML-KEM-1024. The point of the hybrid design is that the exchange remains secure as long as at least one of the component algorithms is unbroken.

Nothing in this design needs a logged-in user. The additional key exchanges happen between the machine and the gateway during IKE SA setup, so a tunnel authenticated with a machine certificate can negotiate them just as a user tunnel would.

Where the built-in clients stand

The constraint sits in the client. On Windows, the native device tunnel uses IKEv2 with machine certificate authentication on domain-joined Enterprise or Education editions. Its configurable key exchange parameters have historically been classical DH and ECP groups. Before you plan around the native client, check the current Windows documentation for an ML-KEM additional key exchange transform. A 2026 protocol survey found that IPsec adoption of PQC remains largely confined to research prototypes and testbeds, with no major commercial VPN product shipping post-quantum IKEv2 by default.

If the native stack can’t negotiate ML-KEM, organisations usually take one of two routes. They either deploy a dedicated client that runs as a system service, or they move the post-quantum protection to the network layer between sites. For remote access, the QPN software client is available for current Windows and macOS, needs no incoming firewall ports, and uses a hybrid key agreement that combines a classical part and ML-KEM into one session key. Whether any client starts before logon is a property of that client’s service design, so test it on a signed-out machine.

The fragmentation constraint

Post-quantum key shares are much larger than elliptic-curve shares. Researchers note that IKEv2 was designed around the assumption of compact key exchange payloads, and its fragmentation mechanisms are less mature than those in TLS 1.3. RFC 9370 handles this by carrying the extra exchanges in IKE_INTERMEDIATE messages, which are encrypted and can therefore be fragmented. Still, test pre-logon connectivity on networks that drop UDP fragments. A device tunnel that fails silently in a hotel leaves the laptop without domain connectivity at the logon screen.

Does a pre-logon machine tunnel protect domain authentication traffic against harvest now, decrypt later?

Only if the tunnel’s key exchange is itself quantum-resistant. A device tunnel keyed with classical (EC)DH alone protects domain traffic today, but a recording of that session could be decrypted once a cryptographically relevant quantum computer exists.

Harvest now, decrypt later targets the key exchange, not the symmetric cipher. If an adversary can recover the IKE shared secret from a recorded handshake, every inner protocol opens up at once. That includes protocols that were never designed to resist offline analysis.

How do you enforce post-quantum key exchange settings on a fleet of Windows and macOS laptops?

Enforce the requirement at the gateway first, then align the client profiles through device management. The gateway is the only place where one policy decision applies to every laptop, whatever its OS version.

Make the gateway the policy point

Under RFC 9370, the initiator proposes additional key exchanges and the responder decides which ones it accepts. If the gateway’s proposal for the device tunnel group lists ML-KEM as a required additional key exchange, without the “NONE” option, no laptop can finish an IKE SA without it. If NONE is included, ML-KEM becomes optional and downgrades succeed silently. Write this choice down per connection profile, because device tunnels and user tunnels usually point at different profiles.

Windows

Device tunnel profiles are delivered as ProfileXML through the VPNv2 configuration service provider, or through PowerShell when you’re staging. Keep the cryptographic suite in the profile identical to the gateway proposal. A mismatch shows up as a tunnel that never comes up, not as a clear error. If you use a dedicated post-quantum client, deploy it as a system service with its configuration locked against local administrator changes, and pin the gateway identity in the profile.

macOS

macOS has no domain pre-logon device tunnel equivalent to the Windows one. Apple’s always-on VPN payload targets supervised iPhone and iPad, so macOS fleets usually rely on VPN On Demand rules or a client that runs as a system extension. Push the IKEv2 or client settings in a managed configuration profile and block users from removing it. Then confirm, with a captured handshake, that the negotiated exchange actually includes ML-KEM.

What happens to an always-on tunnel when the client OS does not support ML-KEM?

The outcome depends entirely on the gateway policy. Either the tunnel comes up with classical key exchange only, or it doesn’t come up at all. Neither outcome is visible to the user unless you’ve built reporting for it.

Enforcing ML-KEM is riskier for an always-on tunnel than for an ordinary VPN, because the device tunnel is often the channel that delivers the fix. A laptop that can’t build the tunnel may also be unable to get the client update that would let it connect. The practical sequence is: optional with logging, then mandatory for a pilot group, then mandatory fleet-wide, with an out-of-band recovery path for stragglers.

Don’t confuse “falling back to classical” with “falling back to cleartext.” A well-designed tunnel should never fall back to cleartext. QPN, for example, never falls back to unencrypted traffic and retries automatically after a line failure. Even so, the classical-versus-hybrid question has to be answered separately for every client and policy.

How do you check which remote laptops are still connecting with classical key exchange only?

Read the negotiated transforms from the gateway’s IKE SA records and join them to your device inventory. Laptops whose SAs show no additional ML-KEM key exchange are the ones still exposed.

• Gateway SA logs: For each established IKE SA, record the peer identity (machine certificate subject), the primary key exchange group and any additional key exchange transforms. RFC 9370 defines seven new Transform Types to negotiate additional key exchanges, so the absence of an additional key exchange transform is the classical-only signal.
• Rekey checks: Confirm that the post-quantum exchange is repeated at rekey, not only at initial setup. Under RFC 9370, rekeys with additional exchanges use the IKE_FOLLOWUP_KE exchange.
• Packet-level spot checks: In a capture, a hybrid IKEv2 setup shows IKE_INTERMEDIATE messages after IKE_SA_INIT. In the ML-KEM draft for IKEv2, the IKE header of IKE_INTERMEDIATE messages carrying the ML-KEM key exchange has an Exchange Type of 43.
• TLS-based tunnels: For clients built on RFC 8446 (TLS 1.3), check the negotiated key share group. A hybrid group such as X25519MLKEM768 indicates post-quantum key exchange, and a plain X25519 or P-256 group does not.
• Inventory join: Compare the list of machine identities seen on the gateway with your device management records. A laptop that appears in device management but never connects is a separate finding. It may be failing a mandatory policy.

Which deadlines apply to classical key exchange on remote access tunnels?

NIST has set end dates for quantum-vulnerable key establishment, and US federal policy has moved high-value systems earlier. Many critical infrastructure operators use these dates as planning anchors even when they aren’t bound by them.

According to NIST, Executive Order 14412 requires federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. Because device tunnels carry authentication material, it makes sense to put them early in that queue, ahead of less sensitive user traffic. NIST’s own position on the algorithms is that no further waiting is needed. Dustin Moody, head of NIST’s Post-Quantum Cryptography project, said: “Organizations should continue to migrate their encryption systems to the standards we finalized in 2024.”

NIST SP 800-46 Rev. 2 is still the reference for remote access architecture as a whole. It provides recommendations for creating telework-related policies and for selecting, implementing, and maintaining the necessary security controls for remote access servers and clients. For an always-on fleet, the post-quantum version of that maintenance work comes down to three things. Set a gateway policy that states whether ML-KEM is required. Keep client profiles that match it. Run a recurring report that lists every machine still connecting with classical key exchange.