Quantum safe remote access: how do you set it up?

Quantum safe remote access is a remote connection, from a laptop to a site, data centre or cloud environment, whose key exchange resists attacks by future quantum computers. It usually combines a classical key exchange with a post-quantum algorithm such as ML-KEM, so that traffic recorded today cannot be decrypted later.

For organisations running operational technology (OT) and critical infrastructure, remote access is the connection that is hardest to control. Field technicians connect from substations, pumping stations and customer sites. Engineers and operators work from home. Vendors need occasional access to specific controllers. This article explains what changes when remote access has to be quantum safe, and how to design it without weakening the controls you already have.

What is post-quantum remote access?

Post-quantum remote access protects how each remote session agrees on its encryption keys, using algorithms that are designed to withstand both classical and quantum attacks. Everything else about remote access stays the same: who gets access, to which systems, and under what conditions.

The key part is the handshake. Today most remote access relies on RSA or elliptic-curve Diffie-Hellman to agree on a session key. Both are vulnerable to a sufficiently large quantum computer. NIST’s replacement for key establishment is ML-KEM, published as FIPS 203. The Secretary of Commerce approved three Federal Information Processing Standards for post-quantum cryptography, FIPS 203, 204 and 205, on August 13, 2024. A key encapsulation mechanism (KEM) is a type of key establishment scheme that can be used to establish a shared secret key between two parties communicating over a public channel.

Statistic: before choosing these standards, NIST went through a lengthy selection process. After assessing 82 algorithms from 25 countries, the top 15 were identified with global cryptographers’ assistance. (NIST, 13 August 2024)

Why hybrid key agreement is the practical default

Most current designs run a classical and a post-quantum key exchange side by side and combine the results into one session key. If the newer algorithm turns out to have a flaw, the classical part still protects the session against today’s attackers, and if a quantum computer arrives, the post-quantum part protects it. National guidance treats hybrid as a transition step: NCSC-UK suggests hybrid schemes for additional security and retro-compatibility during migration, but stresses that hybrid systems should be considered temporary and capable of switching to standalone post-quantum cryptography. That is why crypto agility, meaning the ability to change the algorithm through an update, matters as much as the algorithm itself.

Is remote access traffic vulnerable to quantum computers?

Yes, remote access traffic protected only by classical key exchange can be recorded now and decrypted later once a cryptographically relevant quantum computer exists. The risk sits in the key exchange, not in the bulk encryption.

The distinction matters for planning. According to NIST, NIST-approved symmetric primitives providing at least 128 bits of classical security continue to be approved. The weak link is the public-key step that sets up the symmetric key. If that step can be broken, an adversary who stored the encrypted traffic can recover the key and read the whole session.

This is the “harvest now, decrypt later” scenario. In their joint factsheet, CISA, NSA and NIST warn that “cyber threat actors could be targeting data today that would still require protection in the future”, a risk that applies particularly to data with a long secrecy lifetime.

Remote access sessions into OT carry exactly that kind of data: network diagrams, PLC logic, setpoints, firmware images, credentials for engineering workstations and maintenance logs. Much of it stays relevant for the 15 to 30 year lifetime of an industrial installation. NIST IR 8547 frames the urgency with Mosca’s theorem: if X is the number of years data must be kept secure and Y the time needed to complete the transition, organisations must start before X + Y exceeds the expected time Z for a cryptographically relevant quantum computer to be built.

NIST’s lead on the standards, Dustin Moody, put it directly when the standards were released: “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”

How to secure remote access for field technicians

Give each field technician a post-quantum client on a managed laptop, route it only to the OT segments their job requires, and terminate it at a gateway placed so your existing firewall can still inspect the traffic. The aim is narrow, encrypted, inspectable access, not a general tunnel into the plant.

Field technicians are the hardest group to secure because their network conditions are unpredictable: a mobile hotspot in a substation yard, a guest network at a supplier, a hotel connection during a multi-day outage. Practical design choices follow from that:

• Scope routes per role, not per person. A relay-protection technician needs the protection relays and their engineering workstation, not the whole control network. Define those subnets as the only routes pushed to the client.
• Terminate in front of the firewall where inspection matters. If the OT firewall or intrusion detection has to see what technicians send to controllers, decryption must happen before that point. On paths where inspection is not required, the gateway can sit behind the firewall.
• Plan for unstable links. Technicians lose coverage. A client that retries automatically and never drops to an unencrypted connection prevents workarounds such as a technician plugging in a separate, unprotected modem to “just get it done”.
• Revoke as part of the job workflow. Tie client enrolment and removal to work orders or contractor onboarding, so access ends when the job or the contract does.

Quantum Network’s QPN takes this approach for remote access: its software client runs on current Windows and macOS, uses a hybrid key agreement that combines a classical part with ML-KEM into one session key, renews both handshakes every two minutes, and never falls back to unencrypted traffic after a line failure.

How to give home workers a protected connection to critical systems

Terminate home workers’ connections at a gateway in your own data centre or cloud environment, give them access only to the specific critical applications they use, and keep the central firewall in the path for filtering and inspection. Home workers usually need fewer systems than technicians, but they connect more often and for longer.

A control room engineer working from home might need a historian, a SCADA thin client and a ticketing system. That is a small, stable set of destinations, which makes it easy to keep the routes narrow. A few points matter specifically for critical infrastructure:

• Separate home-worker routes from technician routes. A home worker rarely needs layer-level access to controllers. Keep these groups on different address pools so firewall rules can tell them apart.
• Keep everyday internet traffic off the tunnel when policy allows. Sending only traffic for critical systems through the encrypted path keeps the gateway focused and the logs readable. Whether to do this is a policy decision for your security team.
• Do not ask the encryption layer to do the firewall’s job. Web filtering, email malware scanning and anti-virus belong to other controls. A post-quantum gateway that does not do these things is not a gap, as long as the traffic still passes through tools that do.

For cloud-hosted applications, the same logic applies at the other end. A virtual gateway in your own cloud tenancy or data centre lets remote users and sites reach cloud workloads over the same post-quantum protected path, without routing through a third-party service.

Do remote access clients need incoming firewall ports?

A well-designed remote access client should not need any incoming firewall ports: it starts the connection outbound to the gateway. Open inbound ports on endpoints are a liability, especially on networks you do not control.

This is more than a convenience. Technicians and home workers sit behind home routers, mobile carrier NAT and guest Wi-Fi, where inbound ports cannot be opened and should not be. A client that listens for incoming connections also exposes a service on a laptop that moves between untrusted networks. Outbound-only clients avoid both problems and remove a common source of support calls.

The QPN software client for Windows and macOS needs no incoming firewall ports. On the gateway side, work with your firewall team to decide where the gateway is reachable and which paths the existing firewall continues to inspect. In most environments, integrating a gateway like this comes down to adding or adapting a few routes rather than redesigning the network.

Where should OT and critical infrastructure operators start?

Start by listing every remote access path into OT, ranking them by how long the data they carry stays sensitive, and moving the longest-lived paths to hybrid post-quantum key agreement first. That inventory is also what national guidance asks for.

CISA is taking steps to help critical infrastructure owners and operators facilitate the eventual transition to PQC for operational technology, and CISA, NSA and NIST urge organisations to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, applying risk assessments and analysis, and engaging vendors.

For remote access specifically, a workable sequence looks like this:

1. Map the paths. Technician access, vendor access, home-worker access and site-to-cloud links, including the ones set up “temporarily” during past outages.
2. Classify the data on each path. Engineering files and network designs usually outlive operational telemetry.
3. Decide where inspection must happen. This determines whether each gateway sits in front of or behind the existing firewall.
4. Pilot with one group. A single maintenance team using one site gives you real data on link stability and support needs.
5. Keep update channels in place. Algorithm agility only helps if gateways and clients actually receive updates, so budget for ongoing support rather than a one-off install.

The past cryptographic migrations have taken over a decade, and this more complex migration will likely take at least that long, according to NIST IR 8547. Remote access is one of the few areas where organisations can make meaningful progress quickly, because the number of endpoints is known, the clients run on mainstream operating systems, and the change can sit alongside existing network equipment instead of replacing it.