Quantum-safe RDP remote desktop: how to secure OT access

Quantum-safe RDP remote desktop access means protecting Remote Desktop Protocol sessions so that traffic recorded today cannot be decrypted later by a cryptographically relevant quantum computer (CRQC). In practice there are two ways to do it: negotiate a hybrid post-quantum key exchange inside RDP’s own TLS layer, or carry RDP inside a separate tunnel whose key agreement includes ML-KEM.

In operational technology (OT) and critical infrastructure, RDP is usually how engineers and vendors reach a Windows jump host, and from there reach engineering workstations and HMIs. That makes RDP sessions some of the most sensitive traffic an organization sends over untrusted networks. This article explains where the quantum risk sits, what RDP can and cannot do natively, and how to design the path from a remote laptop to the OT zone.

Is Remote Desktop Protocol traffic vulnerable to harvest now, decrypt later?

Yes. Modern RDP is protected by TLS, and its session keys come from classical key exchange (typically ECDHE). Anyone who records the handshake and the encrypted stream today could recover the content once a CRQC exists.

Harvest now, decrypt later is not a theoretical idea that agencies have only just raised. In 2023, CISA, NSA and NIST jointly warned that threat actors could be targeting data today that would still require protection in the future, using a “harvest now, decrypt later” operation. For OT specifically, CISA notes that attackers could harvest and exfiltrate or intercept encrypted OT traffic and so uncover device credentials or gain insight into OT networks.

What a recorded RDP session actually contains

An RDP stream is not just pixels. It carries keystrokes (including passwords typed into HMI or PLC programming software), clipboard contents, redirected files, and screen images of process graphics, alarm lists and network diagrams. Credentials sent during Network Level Authentication travel inside the same TLS channel. For a utility or manufacturer, the confidentiality lifetime of that information (plant layouts, control logic, account naming schemes) often runs to decades. That is far longer than many expert estimates of when a CRQC could arrive.

Statistic: In a survey of 32 leading science and industry experts in the field, approximately two-thirds estimated a 50% or greater likelihood of the arrival of a cryptographically relevant quantum computer within the next 15 years (OECD, citing Mosca and Piani, 2024).

Can RDP sessions use ML-KEM hybrid key exchange?

In principle yes, because RDP’s enhanced security runs over TLS, and TLS 1.3 can carry hybrid ML-KEM groups. In practice it depends on whether both the client’s and the server’s TLS stacks offer and accept those groups. You have to verify that for each operating system version and RDP client, not assume it.

TLS 1.3, defined in RFC 8446, negotiates key exchange through the supported_groups and key_share extensions. The IETF is standardizing hybrid groups for it: one draft defines three hybrid key agreement mechanisms for TLS 1.3 - X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. The post-quantum half is ML-KEM from FIPS 203.

Statistic: NIST published FIPS 203 on August 13, 2024, and the standard specifies three parameter sets for ML-KEM: ML-KEM-512, ML-KEM-768, and ML-KEM-1024 (NIST CSRC, 2024).

NIST is clear about the algorithm’s standing: “At present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.” The hybrid construction adds a safety margin. As the IETF draft on ML-KEM for TLS puts it, hybrid mechanisms provide security as long as at least one of the component algorithms remains unbroken.

How to check what your RDP sessions negotiate

Capture a connection to the jump host and inspect the TLS ClientHello and ServerHello. If the selected group is plain X25519 or secp256r1, the session is quantum-vulnerable. Also check whether the session falls back to TLS 1.2, which has no standardized hybrid ML-KEM groups. OT estates often contain older Windows Server builds and third-party RDP clients, so expect results to vary across your fleet. That variation is the main practical argument for not relying on RDP’s native TLS alone.

Should RDP to an OT jump host be wrapped in a quantum-safe tunnel?

For access that crosses the internet or any network you do not control, yes. A tunnel with hybrid ML-KEM key agreement protects the RDP stream however the RDP endpoints negotiate TLS, and it also keeps the RDP service off the public internet.

This works at the network layer. A Layer 3 encryption gateway encrypts everything above Layer 3, so RDP, plus any file transfer or licensing traffic on the same path, travels inside the post-quantum protected tunnel. One example is Quantum Network’s QPN. Its gateways combine a classical and an ML-KEM key exchange into one session key, encrypt payloads with ChaCha20-Poly1305, and do not require software on the jump host or the OT systems behind the gateway. That last point matters in OT, where installing agents on certified engineering workstations is often not allowed.

A tunnel does not replace jump host controls. Keep multi-factor authentication, NLA, session recording and least-privilege accounts on the jump host. The tunnel protects data in transit, not the endpoints themselves.

How do you secure remote desktop access from macOS to Windows jump servers against quantum attacks?

Start the quantum-safe tunnel on the Mac itself, so the RDP client’s own TLS stack no longer decides how well the session is protected. Then harden the Windows jump server so that whatever comes out of the tunnel is tightly limited.

macOS RDP clients use their own TLS implementations, and administrators rarely control which key exchange groups they offer. An operating-system-level client avoids that problem. For example, the QPN software client from Quantum Network is available for current macOS and Windows and needs no incoming firewall ports on the client side. A practical setup has three steps:

• On the Mac: start the tunnel before launching the RDP client, and route only the jump host’s address through it, so the RDP connection cannot quietly go over the open internet.
• On the jump server (Group Policy): set “Require use of specific security layer for remote (RDP) connections” to SSL, enable “Require user authentication for remote connections by using Network Level Authentication”, and enable “Do not allow drive redirection” and “Do not allow Clipboard redirection” so files cannot move between an unmanaged Mac and the OT side.
• On the network: allow RDP to the jump server only from the tunnel’s address range, never from general corporate or VPN pools.

The same pattern works for Windows laptops, which keeps operating procedures the same for staff and contractors whatever platform they use.

Where should the jump host sit relative to the OT firewall and encryption gateway?

Put the jump host in an IT/OT DMZ, between the enterprise firewall and the OT firewall. End the quantum-safe tunnel at the DMZ edge, never inside the control network.

This follows the zone-and-conduit model in IEC 62443-3-3. That standard’s system requirements include network segmentation (SR 5.1), zone boundary protection (SR 5.2) and control of access via untrusted networks (SR 1.13). NIST SP 800-82r3 likewise recommends a DMZ between corporate and OT networks, so that no traffic passes directly from enterprise or external networks into the control system. The remote session goes laptop → tunnel → gateway → firewall → jump host. Only the jump host may then open defined connections through the OT firewall to specific engineering workstations.

Gateway in front of or behind the firewall?

For multi-site operators, the jump host often sits at a central site while the OT assets sit at substations, pumping stations or plants. In that case, protect the site-to-site link between the central DMZ and each remote OT zone with its own gateway pair. RDP from the jump host to a remote engineering workstation then also crosses public or carrier networks inside a post-quantum tunnel.

How should OT operators prioritize the migration?

Start with the RDP paths that cross untrusted networks and carry the longest-lived secrets, and move to hybrid ML-KEM key agreement there first. The regulatory timeline already points the same way.

Statistic: NIST IR 8547 (initial public draft, November 2024) proposes that classical key establishment such as ECDH and RSA at 112-bit strength be deprecated after 2030 and disallowed after 2035. NIST adds that quantum-vulnerable algorithms will be removed from its standards by 2035, with high-risk systems transitioning much earlier.

Dustin Moody of NIST’s Cryptographic Technology Group sums up the logic in his presentation: “MIGRATE TO QUANTUM-SAFE SOLUTIONS BEFORE THE THREAT IS REALIZED”. CISA adds an OT-specific caution, describing post-quantum migration for OT as a significant and enduring challenge for owners and operators of U.S. critical infrastructure. Long asset lifecycles mean many controllers will never support post-quantum cryptography themselves.

A workable order for OT remote access:

1. Inventory every RDP path into or toward OT: vendor access, on-call engineers, inter-site jump chains. Record which ones cross the internet or carrier networks.
2. Capture and classify the handshakes to see which sessions use classical-only TLS groups or TLS 1.2.
3. Move internet-facing paths behind a hybrid ML-KEM tunnel that terminates in the DMZ, and remove any direct RDP exposure.
4. Protect inter-site links that carry jump-host traffic to remote OT zones.
5. Plan for crypto agility, so the post-quantum algorithm can be swapped if cryptanalysis or NIST guidance changes, without redesigning the access architecture.

This sequence follows what CISA, NSA and NIST asked of critical infrastructure in 2023: they urge organizations to review the joint factsheet and to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, applying risk assessments and analysis, and engaging vendors. For RDP into OT, the outcome should be concrete: no remote desktop session crossing an untrusted network depends on classical key exchange alone.