OT Network Monitoring: Passive Detection Without Adding Attack Surface

01Key takeaways

1. 01

   OT network monitoring is mostly passive: it observes a copy of the traffic instead of probing live control systems, because active scanning can disrupt fragile devices.

2. 02

   Passive monitoring delivers asset inventory, protocol-aware baselining, and anomaly and threat detection from a SPAN or TAP feed, with no agents on PLCs or RTUs.

3. 03

   Effective detection in OT combines behavioral baselining with known-bad signatures and mapping to MITRE ATT&CK for ICS techniques.

4. 04

   Standards expect this: NIST SP 800-82 Rev. 3 and ISA/IEC 62443 both call for continuous monitoring designed around OT safety and availability.

5. 05

   The monitoring stack itself is attack surface. Sending its data out through one-way transfer keeps the SOC informed without opening an inbound path into the OT zone.

02What OT network monitoring is

OT network monitoring is the continuous observation of traffic, devices and behavior inside an operational technology network. It covers the systems that run physical processes: programmable logic controllers (PLCs), remote terminal units (RTUs), human-machine interfaces (HMIs), engineering workstations, historians and the protocols that connect them.

The purpose is threefold: know what is on the network, know how it normally communicates, and know when something deviates. In IT, this is routine. In OT, the assets are often old, undocumented, intolerant of unexpected traffic, and tied to safety and availability, so the monitoring method matters as much as the data it produces.

Short version: OT network monitoring is industrial visibility and detection done without degrading the process it watches.

03Why OT monitoring is passive by default

IT security tools often discover assets by actively scanning them: sending probes and reading responses. In OT, that approach carries real risk. Many control devices have small network stacks and limited processing headroom. An aggressive port scan or a malformed probe has been known to crash PLCs, trip safety functions or cause process upsets.

Passive monitoring avoids this by never originating traffic toward the control devices. It receives a mirrored copy of network traffic and analyzes it out of band. Nothing new is injected onto the wire, so there is no probe that could destabilize a sensitive endpoint. NIST SP 800-82 Rev. 3 explicitly favors passive techniques in OT and treats active scanning as something to be used cautiously, if at all, and ideally only in test or maintenance windows.

Passive monitoring

Analyzes a copy of existing traffic from a TAP or SPAN port. Adds no packets to the OT network and cannot disturb endpoints.

Active scanning

Sends queries to devices to discover and fingerprint them. Faster and richer, but it can disrupt fragile OT assets and is usually restricted to controlled windows.

Selective polling

A narrow, vendor-aware form of active query used sparingly to enrich passive data, with conservative timing and explicit asset approval.

04Why visibility is the foundation of OT defense

Defenders cannot respond to activity they never observe. Most OT environments grew over decades, with assets added by different integrators, vendors and shifts. The result is networks where nobody holds a complete, current inventory. Monitoring is how that inventory becomes real and stays current.

Visibility also underpins detection. Incidents such as the 2015 and 2016 attacks on the Ukrainian power grid, and the 2017 TRITON/TRISIS attack on a safety instrumented system, showed that adversaries operate inside OT networks for weeks before acting. They use legitimate engineering protocols and stolen credentials, so they blend in. Without traffic-level monitoring, that activity is invisible until the process is already affected.

Passive monitoring is also one of the few controls that does not depend on patching. Where an asset cannot be patched or hardened, watching its behavior is often the most realistic compensating control available.

05How passive OT monitoring works

Passive monitoring starts at the physical layer. A network TAP or a switch SPAN/mirror port produces a copy of the traffic crossing a segment. That copy is fed to a sensor that performs deep packet inspection on industrial protocols such as Modbus/TCP, EtherNet/IP, DNP3, PROFINET, OPC UA, IEC 60870-5-104 and S7comm.

From that traffic the sensor extracts assets, communication relationships and process variables. It learns a baseline of normal behavior: which devices talk to which, on which protocols, in what sequence, at what rate. Once the baseline is established, deviations become alertable events. The analysis happens off the production path, so the OT network is never waiting on the monitoring system.

• Capture: a TAP or SPAN port mirrors traffic to the sensor without touching endpoints.
• Parse: deep packet inspection decodes industrial protocols down to function codes and process values.
• Inventory: assets, firmware versions, and conversations are discovered from observed traffic.
• Baseline: the sensor models normal communication patterns over a learning period.
• Detect: anomalies, known-bad signatures, and policy violations are flagged for analysts.
• Forward: enriched alerts and metadata are sent to a SIEM, historian or SOC for correlation.

06What OT monitoring actually detects

Good OT monitoring blends two detection styles. Behavioral detection flags deviations from the learned baseline: a new device, an unexpected conversation, an engineering command from an unusual host, or a configuration download outside a maintenance window. Signature detection matches traffic against known indicators and protocol abuse patterns.

The most useful platforms map findings to MITRE ATT&CK for ICS, so analysts can reason about adversary behavior rather than raw packets. Techniques worth watching include unauthorized engineering connections, program download and modification of control logic, manipulation of I/O image, denial of service against controllers, and the loss of view or loss of control that often precedes physical impact.

• New or rogue assets appearing on a segment that should be static.
• Engineering-protocol commands (program upload/download, stop/start) from unexpected sources.
• Changes to PLC logic, set points or I/O configuration.
• Cleartext credentials, plaintext protocols and weak authentication on conduits.
• Scanning, brute force or protocol fuzzing originating inside the OT zone.
• Communication crossing zone boundaries that the segmentation policy should forbid.

07Designing a monitoring architecture by zone

Sensor placement follows the network architecture, not the other way around. ISA/IEC 62443 organizes OT into zones and conduits, and the Purdue model layers the plant from field devices up to enterprise systems. Effective monitoring places sensors where the most security-relevant traffic crosses: at conduits between zones, at the boundary between the control network and the DMZ, and within critical cells.

Hardware TAPs are preferable to SPAN ports for high-value links because they are fail-safe, do not drop frames under load, and cannot be reconfigured by a compromised switch. SPAN ports are convenient and acceptable for lower-criticality segments where occasional frame loss is tolerable. Wherever possible, the sensor's capture interface should be receive-only at the physical layer, so the sensor itself cannot transmit into the monitored network.

A monitoring sensor with a transmit-capable management interface on the OT side is a new pivot point. Treat the sensor as an asset to be protected, not just a tool that protects others.

08How it maps to standards and compliance

Continuous monitoring is not optional under current frameworks. NIST SP 800-82 Rev. 3 builds on the SP 800-53 control families, including the audit and accountability (AU) and system and information integrity (SI) families, and tailors them for OT constraints. ISA/IEC 62443-3-3 defines system requirements that include detection of security events and continuous monitoring of conduits.

Sector regulation reinforces this. In North American bulk electric systems, NERC CIP standards such as CIP-007 require security event monitoring on applicable cyber systems. In the EU, the NIS2 Directive obliges operators of essential services to detect and report significant incidents, which is difficult without OT-aware monitoring. CISA's cross-sector performance goals likewise call for network visibility and detection in critical infrastructure.

NIST SP 800-82 Rev. 3

OT security guide; recommends passive monitoring and tailors SP 800-53 AU and SI controls for industrial constraints.

ISA/IEC 62443-3-3

System security requirements, including security-event detection and monitoring across zones and conduits.

NERC CIP-007

Requires security event monitoring and logging for applicable bulk electric system cyber assets.

09Common pitfalls that break OT monitoring

Monitoring projects fail less from bad sensors than from bad design and operations. The most common mistake is deploying detection without anyone to act on it. Alerts that nobody triages create noise, and noise trains operators to ignore the console.

• Relying on SPAN ports that silently drop frames under load, leaving blind spots during the busiest moments.
• Treating active scanning as safe and probing controllers that cannot tolerate it.
• Tuning the baseline during an abnormal period, so the 'normal' it learns is wrong.
• Generating alerts without a triage process, response runbook or owner.
• Forgetting that the monitoring server, its management network and its data feed are themselves attack surface.
• Sending OT telemetry to the SOC over a bidirectional link that becomes an inbound path into the plant.

The last point is the one most often overlooked. Adding visibility should not add reachability. A monitoring deployment that opens a routable, bidirectional connection from the enterprise SOC into the OT zone can quietly become the most dangerous path on the network.

10Where one-way transfer fits

Monitoring data has to leave the OT zone to be useful: it feeds the SIEM, the SOC and long-term analytics. The question is how to export it without creating a return path. This is where unidirectional transfer is a natural fit. The monitoring feed is, by definition, publication-only: data flows out, and nothing needs to come back in.

A data diode or unidirectional gateway lets logs, alerts and packet metadata cross from the OT side to the enterprise side while physically preventing traffic from returning through that boundary. The SOC gets full visibility; the OT zone gains no new inbound route. Combined with passive sensors that never transmit into the control network, the entire monitoring chain can be designed to add observation without adding exposure.

It is one control among several. A diode does not triage alerts, tune baselines or replace segmentation. For teams weighing the options, an AIRGAPNET controlled connectivity pattern can sit alongside passive sensors, TAPs and SOC integration as part of the same monitoring design, so the decision is about which boundaries must be online, one-way, or disconnected by default.

11A practical starting sequence

Start where the risk and the traffic concentrate, then expand. Visibility delivers value quickly because most environments have never seen their own asset list and communication map.

• Map the network and identify zones, conduits and the highest-consequence segments.
• Place a TAP or SPAN feed at the OT-to-DMZ boundary and the most critical cell first.
• Run a passive sensor in learning mode and build an asset inventory and baseline.
• Tune detections to the process, map findings to MITRE ATT&CK for ICS, and assign alert ownership.
• Export alerts and metadata to the SOC through a one-way path so visibility never becomes an inbound route.
• Expand sensor coverage zone by zone, validating that no monitoring component can transmit into the control network.

The objective is not perfect coverage on day one. It is to convert an opaque OT network into one you can see, baseline and defend, while keeping the monitoring itself from becoming the next way in.

FAQFrequently asked questions

SRCSources of record