Split tunneling quantum safe VPN: is it safe for OT?

Split tunneling in a quantum-safe VPN is a client setting that sends only traffic for selected networks, such as OT subnets, through the post-quantum encrypted tunnel. Everything else on the laptop goes straight out over the local internet connection. That traffic is protected only by whatever encryption each application uses on its own, and sometimes it has none.

For an organization that runs substations, water treatment, pipelines or production lines, the setting decides which data from an engineer’s laptop leaves outside the tunnel. That includes name lookups, vendor portals and new subnets that nobody added to the include list. This article covers what bypasses the tunnel, which of it can be stored for later decryption, and how to check on Windows and macOS that OT-bound traffic really goes through the tunnel.

Is split tunneling a security risk for remote access to OT networks?

Yes. On a device that can reach OT, split tunneling is a real risk: the laptop connects to the control network and to an untrusted network at the same time, and the organization loses sight of part of its traffic. The risk is larger for OT than for office IT because one engineering laptop can change setpoints, push PLC logic or open a historian.

NIST described the trade-off years ago in its telework guidance. Split tunneling improves efficiency, but it stops the organization from examining much of the teleworker’s traffic and from protecting its confidentiality and integrity. A device with two active interfaces can also end up bridging a trusted network and an untrusted one. For VPN users on higher-risk networks such as public Wi-Fi hotspots, NIST SP 800-46 Rev. 2 advises organizations to “consider disabling split tunneling capabilities so that attackers cannot eavesdrop on any of the teleworkers’ network communications.”

In OT terms, a remote access path counts as access via an untrusted network. IEC 62443-3-3 SR 1.13 deals with exactly that. NIST’s manufacturing profile maps SR 1.13 to monitoring remote access and using cryptographic mechanisms where needed. A split-tunnel laptop works against both of those goals, because some of its sessions never pass a point the asset owner controls. CISA’s Cross-Sector Cybersecurity Performance Goals 2.0 also tell OT operators to use encryption for external connections wherever latency does not affect operations.

What traffic goes outside the VPN tunnel when split tunneling is turned on?

Anything whose destination is not in the client’s tunnel routes goes out through the physical interface. In practice that covers more than web browsing. Your include list (or exclude list) and the operating system’s resolver and IPv6 behaviour decide where each packet goes.

Even a correct full tunnel does not cover everything. SP 800-46 points out that a tunnel protects only the path between the client device and the VPN gateway. It gives no protection between the gateway and internal resources. Segmentation behind the gateway still has to be handled separately.

Can DNS queries and other bypassed traffic from remote Windows or macOS users be harvested for later decryption?

Yes, and it happens in two ways. Plaintext traffic such as classic DNS can be read straight away. Traffic protected with classical key exchange can be recorded now and decrypted once a cryptographically relevant quantum computer exists.

The first case needs no quantum computer at all. A query for a historian hostname sent over UDP port 53 on hotel Wi-Fi can be read by anyone on that path. The second case is the “harvest now, decrypt later” threat. NIST IR 8547 describes it as adversaries collecting encrypted data now with the goal of decrypting it once quantum technology matures. NIST stresses that the symmetric session keys come from the key establishment step. That is why recorded classical TLS or encrypted DNS sessions are exposed even when the bulk cipher itself is strong. CISA, NSA and NIST warned in a joint factsheet that “cyber threat actors could be targeting data today that would still require protection in the future.”

How urgent this is depends on how long the data stays sensitive. Expert estimates of the timeline:

• Expert survey: a majority of 37 leading experts put the chance of a cryptographically relevant quantum computer at 5% or lower within 10 years, but at 50% or more within 15 years (Mosca and Piani, 2023, summarised by the OECD in 2024).
• Statistical forecast: less than a 5% chance that RSA-2048 is broken before 2039 (Sevilla and Riedel, 2020, summarised by the OECD in 2024).

Asset inventories, network layouts and safety system details often stay sensitive for as long as the plant runs, which can be decades. Even at the more optimistic end of the forecasts, traffic recorded today about those assets can still matter when decryption becomes possible.

Windows and macOS specifics

On Windows, the Name Resolution Policy Table and the interface metrics decide which resolver answers a query. If the tunnel’s DNS suffixes are incomplete, lookups for OT hostnames go to the local resolver. macOS uses scoped resolvers per domain, and it sends multicast DNS on the local link no matter how the tunnel is set up. On both systems, name resolution can take a different path from the data packets that follow it.

Should remote access to critical infrastructure use full tunnel only?

For any device that can reach OT, full tunnel should be the default, and every exception should be documented, approved and tested. Split tunneling for OT access only makes sense when the laptop cannot reach OT outside the tunnel anyway.

Many operators separate the jobs instead of arguing over one setting. A dedicated engineering laptop runs full tunnel only, and conferencing and general office work happen on a different device. Then the split tunnel question never comes up for the machine that can touch a controller.

The tunnel itself matters as much as the routing. One example of the design: the Quantum Network QPN client for current Windows and macOS encrypts at Layer 3, so everything above that layer travels inside the tunnel. Its key agreement is hybrid, combining a classical part with ML-KEM (FIPS 203) into one session key. The connection never falls back to unencrypted traffic. Clients need no incoming firewall ports. These properties only protect the traffic that the routing actually sends into the tunnel. The split tunnel decision is still yours.

How do you check that all OT-bound traffic from a laptop really goes through a post-quantum tunnel?

Check four things on the device and enforce one on the OT side: the routing decision for each OT destination, DNS resolution, what actually appears on the physical interface, and which algorithm the handshake negotiated. Then make the OT side reject anything that does not come from the tunnel.

1. Check the route for each OT destination

On Windows, run Find-NetRoute -RemoteIPAddress <OT address> in PowerShell for a sample address from every OT range, including IPv6 ranges. The selected interface should be the tunnel adapter. On macOS, route -n get <OT address> shows the interface that will be used, and netstat -rn lists both the IPv4 and IPv6 tables. Script these checks so they run from the same list of OT ranges your asset inventory uses.

2. Check DNS

On Windows, Get-DnsClientNrptPolicy and Resolve-DnsName show which resolver handles internal names. On macOS, scutil --dns lists the scoped resolvers per domain. Every OT domain suffix should resolve through an internal resolver that is reached over the tunnel.

3. Capture on the physical interface

Start a packet capture on the Wi-Fi or Ethernet interface, not on the tunnel adapter, and generate OT traffic: open the historian, ping an RTU, start an engineering session. The only packets you should see toward the OT side are encrypted tunnel packets to the gateway’s address. Any OT address, OT hostname or port 53 query visible in clear text is a leak.

4. Confirm the post-quantum handshake

Routing into a tunnel only helps if the tunnel actually negotiates post-quantum key agreement. Check the gateway or client logs to confirm that the hybrid exchange with ML-KEM was used and that sessions never fell back to classical-only or unencrypted modes.

5. Enforce from the OT side

Configure the OT boundary firewall to accept remote sessions only from the tunnel’s client address pool, coming from the gateway. Then a client misconfiguration fails closed: traffic that leaves outside the tunnel simply gets no answer. This also gives you the single monitoring point that IEC 62443-3-3 SR 1.13 is aimed at.

How do NIST IR 8547 and CISA’s PQC Initiative affect remote OT access planning?

They set the timeline. NIST plans to retire quantum-vulnerable key exchange over roughly the next decade, and CISA supports critical infrastructure operators in that transition. Remote access tunnels are an obvious early candidate, because their traffic crosses networks the operator does not control.

• NIST IR 8547: US federal high value assets and high impact systems must adopt post-quantum cryptography for key establishment by 31 December 2030 and for digital signatures by 31 December 2031.
• NIST IR 8547: NIST will “deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035.”

These deadlines are written for US federal systems, but they show where vendors and standards are heading. The CISA Post-Quantum Cryptography Initiative works with NIST, OMB and other agencies to support critical infrastructure and federal network owners and operators as they move to post-quantum algorithms. That includes keeping a list of product categories that support the standards. For a remote access program, the practical order is: list which OT-related flows leave laptops today, close the split tunnel paths that carry long-lived sensitive data, and move the tunnel itself to hybrid key agreement based on FIPS 203.