Post-quantum ZTNA for OT remote access: is it quantum safe?

Post-quantum ZTNA for OT remote access means that every tunnel in a zero trust network access path, from the remote user to the broker and from the broker to the connector beside the OT assets, sets up its session keys with a hybrid key exchange that includes ML-KEM from FIPS 203. Without that, it still relies on classical RSA or elliptic-curve Diffie-Hellman.

Many operators are replacing VPN concentrators with ZTNA to give engineers, integrators and OEM support staff narrower access to plant systems. That is a sound move for access control. Whether those sessions can be recorded today and decrypted later is a separate question, and it depends on cryptography, not on architecture.

Is ZTNA quantum safe or does it still rely on RSA and ECDH?

ZTNA is not quantum safe by default. Most deployments still set up session keys with X25519 or ECDHE and authenticate with RSA or ECDSA certificates, unless the vendor has explicitly enabled a hybrid post-quantum group and both ends negotiate it.

NIST SP 800-207 defines zero trust in terms of policy: who gets access, to which resource, per session. It does not specify algorithms. The CISA Zero Trust Maturity Model v2.0 follows the same SP 800-207 tenet that all communication is secured regardless of network location. Its Networks pillar rates traffic encryption on a maturity scale but does not require post-quantum key exchange. A ZTNA deployment can therefore reach “Optimal” maturity on paper and still run every session over classical ECDH.

Key exchange and authentication are separate problems

It helps to split the tunnel into two cryptographic functions:

• Key establishment (ECDH, X25519, RSA key transport): this is what harvest now, decrypt later targets. Someone who records the handshake today could recover the session keys once a cryptographically relevant quantum computer exists.
• Authentication (RSA or ECDSA certificates, signed tokens): this only matters at the moment the connection is made. NIST IR 8547 states that signatures are not vulnerable to harvest now, decrypt later, though their migration is still urgent because it is slower and involves more parties.

For OT remote access, fix key establishment first: switch to a hybrid of a classical group and ML-KEM. That is what RFC 10024 standardises for TLS 1.3.

Which ZTNA connections need hybrid ML-KEM: client to broker, broker to connector or both?

Both. A ZTNA session is usually two or more separately encrypted legs that meet at the broker, so the traffic is only as protected as its weakest leg.

In a typical cloud-brokered design, the client opens a TLS, DTLS or QUIC session to the broker. The connector inside the plant keeps an outbound tunnel to that same broker. The broker decrypts and re-encrypts traffic between them, or splices the two streams. Each leg has its own handshake and can negotiate a different group.

The broker to connector leg is often overlooked. It is long-lived, it aggregates traffic from every remote user and it ends at the boundary of an OT zone. If vendor documentation only mentions post-quantum support “for clients”, the connector leg probably still uses classical key exchange.

Does replacing a VPN with ZTNA reduce harvest now, decrypt later risk for OT?

Not by itself. ZTNA reduces what one compromised identity can reach. Harvest now, decrypt later only depends on whether recorded handshakes use quantum-vulnerable key exchange, and a classical ZTNA tunnel is as exposed as a classical VPN tunnel.

The CISA maturity model puts bulk-traffic VPN tunnels at the “Traditional” stage of network segmentation. That is about reachability and lateral movement, not cryptographic lifetime. Moving to ZTNA can even add exposure: a cloud broker places an extra internet-facing hop between the plant and the user, and both hops cross networks the operator does not control.

OT data often stays sensitive for a long time. Network diagrams, PLC logic, safety system configurations and maintenance credentials can remain useful for a decade or more, because plant assets are replaced slowly. NIST IR 8547 puts it plainly: “Systems that protect data with long-term confidentiality needs warrant the earliest transitions.”

Timelines that shape procurement decisions

• NIST IR 8547 (final, October 2026): quantum-vulnerable public-key cryptography is deprecated after 2030 and disallowed under NIST standards after 2035.
• Executive Order 14412, as summarised by NIST in October 2026: US federal high-value assets and high-impact systems must migrate key establishment to PQC by 2030 and digital signatures by 2031.
• NIST assessed 82 algorithms from 25 countries before finalising FIPS 203, 204 and 205 in August 2024.

A remote access platform bought today for an OT site will probably still be running in 2030. Dustin Moody, who leads the NIST post-quantum standardization project, said at the FIPS 203 release: “There is no need to wait for future standards. Go ahead and start using these three.”

Can ZTNA connectors inside an OT network work without cloud telemetry?

Sometimes, but it depends on the architecture. Cloud-brokered ZTNA needs the connector to reach a vendor control plane for policy and session brokering. Self-hosted designs can keep both the control plane and the logs inside the organisation.

For OT, the question is less “is there telemetry” than “what leaves the zone, to whom, and what happens if the link drops”. Ask vendors these four things:

1. Content: Does the connector send asset hostnames, IP ranges, DNS queries, user identities or device posture data to the vendor? Ask for a field-level list.
2. Locality: Can the policy decision point and the broker run in your own data centre or private cloud, so that no third party ends the encrypted legs?
3. Failure mode: If the control plane is unreachable, does the connector fail closed, keep using cached policy, or stop? Fail-closed behaviour is usually right for remote access but must match your operating procedures.
4. Air gap: Can enrolment, certificate renewal and software updates run fully offline for isolated networks?

Placement matters as much as telemetry. IEC 62443-3-3 frames this as zones and conduits, with system requirements such as SR 1.13 (access via untrusted networks), SR 4.1 (information confidentiality) and SR 5.2 (zone boundary protection). Treat a connector as a conduit endpoint, usually in an industrial DMZ rather than inside a control zone. It should only be allowed to start outbound connections to defined brokers.

Some organisations protect the paths between their own sites, and from sites to their own cloud, with a separate Layer 3 encryption layer instead of relying on each application’s tunnel. Quantum Network’s QPN gateway is one example of that design. It uses hybrid key agreement with ML-KEM, sends no telemetry, has no cloud dependency, and supports OT and air-gapped networks.

How do I check whether a ZTNA tunnel negotiates X25519MLKEM768?

Capture the handshake on each leg and read the selected key exchange group. RFC 10024 registers X25519MLKEM768 as TLS supported group 4588 (0x11EC), and that value should appear in the server’s key share.

Step by step for TLS 1.3, DTLS 1.3 and QUIC legs

1. Capture on the right segment. Use a mirrored port or packet capture on the client host for the client to broker leg. Use the industrial DMZ uplink for the broker to connector leg. Do not assume the two legs match.
2. Inspect the ClientHello. In a packet analyzer, open the supported_groups and key_share extensions. A hybrid offer lists group 0x11EC. Its key share is 1216 bytes: 1184 bytes of ML-KEM-768 encapsulation key plus 32 bytes of X25519.
3. Inspect the ServerHello. Only the server’s key_share shows what was actually chosen. If it says x25519 (0x001D) or secp256r1 (0x0017), the session is classical, whatever the client offered.
4. Watch for a HelloRetryRequest. A retry that steers the client to a classical group means the server does not accept the hybrid share.
5. Check for legacy codepoints. Value 25497 (0x6399) is the pre-standard X25519Kyber768Draft00 group. It shows that a pre-standard implementation is in use and the endpoint should be updated.
6. Repeat behind every TLS inspection point. A proxy that terminates and re-originates TLS creates a new handshake that may be classical.

RFC 10024 defines the resulting shared secret as the ML-KEM secret concatenated with the X25519 secret, 64 bytes in total. An attacker would therefore have to break both components.

When the tunnel is not TLS

Some ZTNA connectors use IPsec or a proprietary protocol for the broker to connector leg. For IKEv2, ask whether ML-KEM is negotiated as an additional key exchange under RFC 9370. Then confirm it in the IKE_SA_INIT and IKE_INTERMEDIATE exchanges. For proprietary protocols, ask the vendor for written documentation of the key exchange, the FIPS 203 parameter set and how algorithms can be updated, and test it in a lab.

The CISA, NSA and NIST quantum-readiness factsheet asks critical infrastructure operators to start with a cryptographic inventory. For remote access, that inventory should record the negotiated group for each leg, the expected lifetime of the platform and the confidentiality lifetime of the OT data it carries.