How does quantum safe SCADA encryption protect OT links?

Quantum safe SCADA encryption means protecting supervisory control and data acquisition traffic between sites, control centres, cloud environments and remote users with cryptography built to withstand both today’s attacks and a future quantum computer. It usually does this by combining a classical key exchange with a post-quantum algorithm such as ML-KEM, standardised in FIPS 203.

For operators of critical infrastructure, the problem isn’t abstract. Field networks built today will still carry control traffic well after quantum-vulnerable public-key algorithms are due to be phased out. Many of those networks also cross public internet links, cellular networks or shared carrier infrastructure. This article covers why OT traffic is exposed, how long that exposure lasts, and how to protect SCADA and PLC communication without rebuilding the plant.

Why is OT traffic a target for harvest now decrypt later?

OT traffic is a target because it can be recorded today and decrypted later, and much of what it reveals about a plant stays valid for as long as the plant runs. That is why protection matters now: traffic that is encrypted quantum-safe from today stays confidential for as long as it matters.

In a joint factsheet written especially for critical infrastructure, CISA, NSA and NIST warned that “cyber threat actors could be targeting data today that would still require protection in the future.” NIST IR 8547 makes the same link. It frames its transition timeline partly as a way to reduce the risk of harvest now, decrypt later attacks on network communications.

Not all OT traffic is equally sensitive. An analysis of quantum-ready WAN design points out that routine operational data that quickly loses its value carries a lower harvest-now risk. A tank level from 2026 is of little use in 2036. The real concern is the structural information that travels alongside the process values, which stays useful for years:

• IP addressing, tag names and register maps that describe how the process is built
• Engineering sessions that carry PLC project files, logic and firmware
• Credentials and configuration pushed from engineering workstations to remote sites
• Historian exports that show operating limits, setpoints and alarm thresholds

That same WAN analysis also notes that forward secrecy doesn’t help here. It protects a session if a long-term private key leaks, but it doesn’t protect an elliptic-curve Diffie-Hellman exchange from an adversary who can later solve the underlying mathematical problem. So traffic protected only by classical key exchange stays exposed, even when it’s encrypted.

Estimates of when such an adversary could exist vary, but they have been moving closer:

• 34% by 2034: in the Global Risk Institute’s 2024 survey of 47 quantum computing experts, the estimated probability of a cryptographically relevant quantum computer by 2034 was 34%, double the 17% estimate from the 2022 assessment (Global Risk Institute, 2024, as reported in arXiv 2603.06969).

How long does OT equipment stay in service?

OT equipment typically stays in service for decades, far longer than IT hardware. That means a network architecture chosen now will still carry SCADA traffic well past the 2030s.

CISA’s guidance for integrators and engineering firms warns that security weaknesses introduced during procurement, design and deployment are likely to last for the whole decades-long lifecycle of an OT system. The joint NSA and CISA advisory AA22-265A states that “Traditional ICS assets are difficult to secure due to their design for maximum availability and safety,” and adds that they often run decades-old systems without recent security updates.

Put that lifecycle next to the federal cryptography timeline:

What are the risks of unencrypted links to remote sites?

Unencrypted links to remote sites expose control traffic to eavesdropping, spoofing and tampering in transit, because many industrial protocols were never designed with security in mind. Links with only classical encryption add a second, slower-moving risk: traffic recorded today could be decrypted in the future.

CISA notes that many OT owners and operators still rely on insecure legacy industrial protocols that lack basic authentication and integrity checks. It warns that this lets threat actors impersonate a device or change a message on its way to an OT device. Academic surveys reach the same conclusion. Modbus has no encryption, integrity checks or authentication, and DNP3 in its original form implements neither encryption nor authentication.

The exposure depends on the kind of link:

Remote access raises the stakes further. AA22-265A lists external connections and remote access among the factors that widen the attack surface of OT and ICS environments.

Can legacy PLCs be protected without replacing them?

Yes, as far as their traffic in transit is concerned. An encryption gateway at each end of the link can protect everything the PLC sends and receives across the WAN, with no changes to the PLC itself. The gateway doesn’t make the controller any more secure, so local controls are still needed.

This “bump in the wire” approach fits OT for practical reasons. Legacy controllers often can’t run modern cryptography, vendors may not support firmware changes, and replacing a PLC means process downtime and requalification. The CISA-led asset inventory guidance advises operators to weigh the cost of downtime or degraded service against the cost of replacing vulnerable legacy systems or deploying compensating controls. A network-layer gateway is one such compensating control.

In IEC 62443 terms, the encrypted path between two gateways works as a protected conduit between zones. The zone model still matters: behind each gateway, traffic is cleartext again, so segmentation, access control and monitoring within the zone remain necessary.

Quantum Network’s QPN is one example of this design. A hardware or software gateway sits at each end of a connection and encrypts at Layer 3, so everything above Layer 3 is carried encrypted. No software is installed on the equipment behind it. It works alongside existing firewalls and routers and is integrated by adding or adapting a few routes. Like any gateway of this type, it protects data in transit, not the devices behind it. It doesn’t replace a central firewall and isn’t a defence against denial of service.

How to secure SCADA communication over public networks?

Secure SCADA over public networks by encrypting each conduit end to end with a hybrid classical and post-quantum key agreement that fails closed. Then design firewall placement, latency, remote access and algorithm updates around how the plant actually operates.

Map conduits by how long their data must stay secret

Start with the asset inventory and list every path that leaves a zone: control centre to outstations, engineering access, vendor support, historian exports. Put the paths that carry engineering sessions, configuration and bulk process history first, because that data stays useful to an adversary the longest.

Use hybrid key agreement

Combine a classical exchange and ML-KEM into a single session key. The combined key stays secure as long as either part holds, which protects against a future quantum attack on the classical part and against an unexpected weakness in the newer post-quantum algorithm. NIST’s project page says organisations should begin applying the post-quantum standards now.

Decide where inspection happens

If a firewall has to keep inspecting OT protocols on a path, encryption has to terminate before the traffic reaches it, so the gateway goes in front of the firewall. Where inspection isn’t needed, the gateway can sit behind it. Make this decision for each conduit instead of forcing one layout across the whole network.

Require fail-closed behaviour and unattended recovery

A tunnel that quietly falls back to cleartext during an outage defeats the purpose. Require designs that never send unencrypted traffic and that reconnect automatically after a line failure, since most remote sites have no one on site to restart anything. Also plan how the local process keeps running while the link is down.

Test timing against the process

Measure the added latency and throughput on a real link against your tightest polling cycle or interlock before a full rollout. Long-distance and cellular links deserve extra attention.

Cover cloud and remote users, not just sites

Hybrid-encrypted paths are also needed for cloud historians and for remote engineers. The same QPN design offers edge-to-cloud deployment with a virtual gateway in the organisation’s own data centre or cloud, and remote-access clients for Windows and macOS that need no incoming firewall ports. Whatever the implementation, avoid opening inbound ports into OT zones.

Plan for crypto agility

Post-quantum standardisation is still under way, and NIST is developing further standards as backups. Choose equipment whose algorithms can be changed without new hardware. Agree on how updates will reach air-gapped or isolated networks, and treat maintenance subscriptions as part of your cryptographic lifecycle, not as optional extras.

CISA Acting Director Madhu Gottumukkala has described the underlying challenge plainly: “Adopting secure communications in OT environments is a long-term effort with complexities, costs and risks.” Encrypting the links between sites, cloud and remote users with hybrid post-quantum cryptography is one part of that effort that doesn’t require replacing field equipment, and it reduces the amount of traffic recorded today that could be decrypted later.