OT Network Monitoring: Encrypted Traffic Gateway Placement

OT network monitoring with encrypted traffic means keeping passive intrusion detection, protocol analysis and anomaly detection working after you encrypt the links between sites, cloud environments and remote users. Where you place the gateway decides what your sensors see: cleartext industrial protocols on the protected side, or only encrypted tunnel packets on the WAN side.

This has become a practical design question because the move to post-quantum cryptography now has a schedule. Operators of critical infrastructure are adding quantum-safe gateways to links that their OT security teams have watched in cleartext for years. The goal is to protect data in transit without losing the visibility that control-system defence relies on.

Why does post-quantum migration affect OT monitoring design now?

NIST has published firm end dates for quantum-vulnerable key exchange, so organisations are re-engineering inter-site links on a deadline. Each new gateway changes which network segments carry cleartext.

Dustin Moody of NIST summarised the purpose of the final transition report: “We lay out how certain encryption algorithms people are using today will get phased out.” For federal systems, the timeline is even tighter: Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures. CISA, NSA and NIST had already warned in 2023 that “Early planning is necessary as cyber threat actors could be targeting cryptography in its IT and OT systems.”

Will encrypting OT traffic between sites blind my passive OT intrusion detection sensors?

Only sensors on the WAN side of the gateway lose visibility. Traffic inside each site stays cleartext, so sensors on the protected side keep decoding Modbus/TCP, DNP3, IEC 60870-5-104, S7 or EtherNet/IP as they do today.

A Layer 3 encryption gateway works like a tunnel endpoint. Everything above the IP layer, and in tunnel mode the inner IP header too, travels as ciphertext between the two gateways. A sensor that copies packets from the WAN link sees only gateway-to-gateway flows: outer addresses, packet sizes, timing and volume. It cannot see function codes, setpoints or which PLC talked to which historian.

NIST SP 800-94 (Intrusion Detection and Prevention Systems) makes the general point that network-based IDPS cannot analyse the payloads of encrypted traffic. That is why it advises placing sensors where traffic is unencrypted. In OT this matters more than in IT, because most detection logic is payload-based. The detections that map to MITRE ATT&CK for ICS techniques such as Unauthorized Command Message (T0855), Modify Parameter (T0836) and Program Download (T0843) depend on reading the industrial protocol itself. CISA’s monitoring guidance also emphasises technologies with capabilities built specifically for ICS assets that can analyze common ICS network traffic, data, and communications conforming to ICS protocols.

So the real risk is not encryption itself. The risk is a sensor that was installed on an inter-site link before encryption, and nobody moved it.

Should the SPAN port or network tap sit before or after the encryption gateway?

Put the primary tap or SPAN source on the protected side of the gateway, where traffic is still cleartext. A second, optional tap on the WAN side is useful for tunnel-health metadata, but never for protocol analysis.

Some practical details matter here. Use a passive tap rather than SPAN on links that carry control traffic: SPAN sessions can drop mirrored frames under load, and bursts during startups or batch changes are exactly when you want complete capture. Make sure you capture both directions; asymmetric routing after you add gateway routes can leave a sensor seeing only requests and no responses. If the firewall translates addresses (NAT), tap on the side where hosts keep their real OT addresses, or your asset inventory will collapse into a handful of translated IPs.

Where should an encryption gateway go relative to the firewall so that OT anomaly detection still sees cleartext industrial protocols?

When the firewall and its monitoring have to keep inspecting inter-site traffic, place the gateway on the WAN side, in front of the firewall. The firewall and every sensor behind it then receive decrypted traffic.

The typical order at each site becomes: WAN router, encryption gateway, OT perimeter firewall, OT DMZ or core switch, with the tap on the firewall’s inside interface or the core. The gateway only sees and protects the path between sites, while policy enforcement and inspection stay where they were. Quantum Network’s QPN gateway follows this model: it goes in front of the existing firewall when that firewall has to keep inspecting the traffic, and it can sit behind the firewall when inspection is not needed on that path. It is integrated by adding or adapting a few routes rather than by replacing network equipment.

The behind-the-firewall option is legitimate, but it shifts responsibility. The firewall can only allow or block the tunnel as a whole, so any per-protocol rules and all payload-based detection for that path must happen inside the gateway. Document this in the conduit drawing so that a later firewall audit does not assume coverage that no longer exists.

For edge-to-cloud links the same logic applies in reverse. The virtual gateway in your own data centre or cloud environment is the decryption point. Cloud-side monitoring therefore belongs on the subnet behind that virtual gateway, not on the public interface.

How can I monitor post-quantum tunnel health and handshake failures without decrypting traffic?

Monitor the tunnel through its metadata: handshake and rekey cadence, reachability between gateways, latency, loss and packet-size patterns on the WAN side. None of this requires keys.

Signals worth alerting on

• Missing rekeys. Hybrid key agreement produces small, recognisable handshake exchanges at a fixed interval. If those exchanges stop while data keeps flowing, or repeat without data resuming, treat it as a handshake failure.
• MTU and fragmentation. Post-quantum key shares such as ML-KEM (FIPS 203) are much larger than classical elliptic-curve shares. On links with a reduced MTU (cellular backhaul, nested tunnels, satellite), watch for fragmentation or ICMP “fragmentation needed” messages around handshake times.
• Latency against polling budgets. SCADA polling and protocol timeouts have fixed budgets. Trend round-trip time between gateways next to the master station’s timeout counters, so you can tell link problems apart from field-device faults.
• Cleartext where none should exist. A WAN-side sensor that suddenly decodes an industrial protocol means you have a routing bypass or a misconfiguration.

Translate vendor behaviour into concrete rules. For example, QPN renews both its classical and post-quantum handshakes every two minutes and never falls back to unencrypted traffic after a line failure; it retries automatically instead. On such a link, a rule that alerts when no rekey has been seen for more than one interval, and a rule that alerts on any decoded industrial protocol on the WAN segment, together cover availability and bypass. Because that gateway sends no telemetry, health data has to come from your own taps, flow records and monitoring systems, which suits air-gapped and regulated environments.

Feed these signals into the same SIEM or OT monitoring console as the protocol alerts. A tunnel flap that lines up with a burst of PLC communication errors tells an operator something that neither alert shows on its own.

Does IEC 62443 require network monitoring to keep working when conduits are encrypted?

IEC 62443-3-3 has no clause that addresses encrypted conduits specifically. But SR 6.2 (Continuous monitoring) applies whether or not a conduit is encrypted, so the monitoring capability has to survive the change.

Under IEC 62443-3-3, conduit encryption usually falls under SR 4.1 (Information confidentiality) and SR 3.1 (Communication integrity), while SR 6.2 sits under Foundational Requirement 6, Timely response to events. In the security level mapping, SR 6.2 - Continuous monitoring is required at SL 2, 3 and 4. Analyses of the standard describe the requirement as a measure that continuously monitors the network for security violations without affecting the operational performance of the control system. Meeting SR 4.1 by encrypting a conduit while leaving SR 6.2 with no cleartext vantage point would trade one requirement for another.

NIST SP 800-82 Rev. 3, final as of 09/28/2023, points the same way with its emphasis on boundary and internal monitoring. A Rev. 4 draft was released on 09/21/2026, so check it for updated wording. SP 800-82 has been downloaded more than 3 million times since its initial release in 2006, which makes it a common reference point in audits. CISA’s long-standing advice is direct: “Watch IP traffic on ICS boundaries for abnormal or suspicious communications.” With an encrypted conduit, the boundary you watch is the protected interface at each end of it.

How do I check that monitoring still works after the gateways go live?

Run a short acceptance test at each site that proves both protocol visibility and tunnel visibility, and repeat it after every routing change.

1. Before cutover, generate known, harmless protocol activity (a read of a test register or a scheduled historian query) and confirm the OT sensor decodes it on the protected side.
2. After cutover, repeat the same activity and confirm it appears with the same real host addresses, in both directions.
3. Confirm the WAN-side sensor decodes nothing industrial and shows only gateway-to-gateway flows.
4. Pull the WAN cable briefly during a maintenance window. Confirm that the tunnel-down and recovery alerts fire, and that no cleartext appears during recovery.
5. Compare asset counts and baselines with the pre-change export after a full production cycle.

CISA’s guidance on post-quantum migration in OT recommends deploying platforms with crypto-agile encryption management mechanisms. Monitoring needs the same agility. When an algorithm or rekey interval changes later, update the tunnel-health rules along with it, so that your alerts keep matching how the link actually behaves.