Browser remote access to OT HMI: is post-quantum TLS enough?

Browser remote access to an OT HMI is only protected against quantum attacks when every encrypted leg between the operator’s browser and the HMI uses a hybrid post-quantum key exchange, such as X25519MLKEM768 in TLS 1.3 (RFC 8446). A current browser can secure the first leg. The portal’s onward connection to the OT web server often still uses classical cryptography, and that is where the protection usually breaks.

This article goes through each leg of a clientless HMI session: what protects it today, how to verify that protection, and where a browser portal stops being the right tool.

Do Windows and macOS web browsers already use hybrid ML-KEM for HTTPS connections?

Yes. Current mainstream browsers on Windows and macOS offer X25519MLKEM768 by default in TLS 1.3. Whether a session actually uses it depends on whether the server you connect to supports it as well.

The group is now specified in an RFC. RFC 10024 defines three hybrid key agreement mechanisms for TLS 1.3, X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, that combine the post-quantum ML-KEM with an ECDHE exchange. The ML-KEM part comes from FIPS 203. X25519MLKEM768 uses code point 0x11EC, and by late 2024 IETF working group material already reported it in use by the major browsers.

The “hybrid” design matters for OT risk owners. According to the IETF, hybrid key establishment provides compositional security: the exchange remains secure as long as at least one of the component algorithms is unbroken. So you give up no classical security by enabling it.

National guidance points the same way. NCSC-NL’s TLS guidelines rate X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024 as Good, and they recommend “configuring X25519MLKEM768 now in order to be resilient against the threat of a CRQC” (NCSC-NL, TLS Security Guidelines 2025-05).

The browser is rarely the weak point. The limiting factor is the TLS stack on the portal side, plus any load balancer or reverse proxy in front of it.

Is a clientless web portal to an OT HMI protected against harvest now, decrypt later?

Only partly. A portal that negotiates X25519MLKEM768 protects the browser-to-portal leg. The HMI session as a whole is only as strong as the weakest leg that crosses an untrusted network.

A clientless portal works as a termination point. NIST SP 800-46 Rev. 2 (Telework and Remote Access Security) treats portals as a distinct remote access architecture next to tunnels and remote desktop. In a portal, the remote user’s TLS session ends at the portal, and the portal then opens its own connection to the internal application. For an OT HMI, that internal application is typically one of two things: an HTML5 rendering of a remote desktop session, or a reverse-proxied embedded web server on the HMI or controller.

Harvest now, decrypt later is about recorded traffic. An adversary who captures encrypted HMI sessions today (setpoints, alarm lists, process layouts, credentials typed into the HMI) could decrypt them later if the key exchange was classical. Researchers studying this risk put it plainly: “PQC migration arrests future accumulation but cannot rewrite the past.”

There is also a quiet fallback. Under TLS 1.3, client and server pick a group they both support. If the portal’s TLS library does not offer the hybrid group, the session falls back to classical X25519 without any error. The IETF notes that upgrading a library may not be sufficient, as it is not known whether PQC groups are enabled by default across different implementations.

What happens to quantum safety when the portal re-encrypts traffic to the OT web server with classical TLS?

The post-quantum protection ends at the portal. From the portal to the HMI, the traffic is only as strong as the classical TLS (or plain HTTP) on that leg. Whether that matters depends on where the leg runs.

Embedded web servers on HMIs, PLCs and gateways often run TLS stacks that are years old. Some only support TLS 1.2 with classical ECDHE or RSA key exchange, and many cannot be updated without firmware changes. The same research warns that protocols that hard-code algorithms or require firmware updates (e.g., IoT, SCADA) cannot pivot within relevant timescales.

The practical answer is not to wait for every HMI vendor to ship a post-quantum TLS stack. Make sure the back-end leg never crosses an untrusted network in classical form. You can do that by placing the portal next to the HMI, or by carrying the back-end leg inside a quantum-safe tunnel between the hosting location and the site. In practice, a network-layer gateway at each end can do this without touching the HMI. Quantum Network’s QPN, for example, encrypts at Layer 3 with a hybrid classical and ML-KEM key agreement, so the portal’s classical TLS to the HMI travels inside that protected path. No software is installed on the equipment behind the gateway.

How can I check that a browser session to a remote access portal negotiated X25519MLKEM768?

Check from both ends: look at the negotiated key exchange group in the browser’s connection details, and confirm it in the portal’s TLS logs or a packet capture. Do not rely on configuration files alone.

From the browser

Many browsers show a security or connection panel in their developer tools. Open the portal page, find the connection details for the main document, and read the key exchange field. It should say X25519MLKEM768. If it shows X25519 or P-256, the session was classical. Run the check from the actual operator workstations, because managed Windows and macOS builds can lag behind or carry policies that change the TLS defaults.

On the wire

In a packet capture of the handshake, look at the ServerHello key_share extension. The selected group should be 0x11EC. The ClientHello will also look larger than usual, because the size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519). That extra size occasionally trips up older middleboxes, and it is worth testing through every firewall and proxy in the path.

On the portal

Configure the TLS terminator to log the negotiated group for each session, and review the share of classical sessions regularly. A command-line TLS client that lets you restrict the offered groups to the hybrid group only is a quick way to confirm that the server accepts it. Also run that test against the back-end HMI address, so you know exactly which leg is classical.

When is a browser-based portal not enough and a full quantum-safe tunnel client needed for OT access?

A portal is enough when the work is purely browser-based and every leg that crosses an untrusted network is hybrid. You need a tunnel when traffic leaves the browser, when the back-end leg cannot be protected, or when the data has to stay confidential for many years.

Typical cases where a browser session does not cover the job:

• Engineering work: PLC programming software, firmware uploads and project file transfers run outside the browser and use industrial or vendor-specific protocols.
• Direct protocol access: historians, OPC UA clients or Modbus/TCP diagnostics need IP-level reachability, not a rendered screen.
• Back-end legs you cannot fix: HMIs whose web servers support only classical TLS, reached across a WAN or the internet.
• Long-lived sensitive data: network topology, safety system logic and process recipes that would still be valuable a decade from now.

IEC 62443-3-3 SR 1.13 (Access via untrusted networks) asks asset owners to monitor and control all access to the control system that comes in through untrusted networks. The standard says how access must be governed, but it does not settle which cryptography protects the path. That remains an engineering decision. For remote users, the tunnel alternative to a portal is a client on the laptop itself. The QPN software client, for example, runs on current Windows and macOS and needs no incoming firewall ports, so the user’s whole Layer 3 traffic to the site travels inside the hybrid ML-KEM session, not just the browser tab.

What timelines should OT owners plan the portal migration against?

Planning dates are now firm. NIST has finalised ML-KEM and published a deprecation schedule for classical key exchange. Because HMI and controller lifecycles run long, equipment you buy today will still be in service when those dates arrive.

NIST states that it will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035. Presenting the final report, NIST’s Dustin Moody said: “We lay out how certain encryption algorithms people are using today will get phased out.”

Because TLS 1.3 already dominates, the browser-facing leg of an OT portal is usually the easy part to fix. Plan your effort around the HMI-side legs, the embedded web servers that cannot be upgraded, and the non-browser engineering traffic, since that is where classical key exchange is likely to remain the longest.