Active vs. Passive Monitoring in OT: The Question Nobody Wants to Answer

Passive monitoring is usually the first recommendation security practitioners make when they enter an OT environment. Watch the network. Listen. Capture traffic. Build a baseline. Do not touch anything. It sounds like a reasonable approach, and it minimizes the risk of disruption. In environments where any change to a running process is treated as a potential hazard, passive feels like the responsible choice. It is also, if taken too literally, a strategy that produces a large amount of data and a limited amount of actionable understanding.

The appeal of passive monitoring rests on a valid observation: active interrogation of OT systems carries real risk. Sending queries to a PLC, polling a field device, or running a network scan against industrial assets can trigger responses that control systems were not designed to handle. Older Modbus implementations can fault on unexpected message sequences. Some RTUs have fixed packet buffers that overflow under scan conditions. The concern is not hypothetical. Engineers who have worked in brownfield environments carry specific memories of specific failures caused by someone running NMAP where it did not belong.

But the passive-only position, held too firmly, creates its own category of problem. Passive monitoring tells you what is on the network that is talking. It does not reliably tell you what is on the network that is not talking. Dormant devices, installed years ago and no longer in active service but still powered and connected, are invisible to passive sensors until they generate traffic. That is precisely the kind of asset that attackers find useful: known to no one in the security organization, reachable from the network, and unlikely to be monitored for anomalies it never generates.

There is also the asset inventory problem. Most OT environments were not built with asset management as a priority. Drawings are out of date. Spreadsheets are incomplete. Physical walk-downs are infrequent. Passive monitoring can supplement an incomplete inventory, but it cannot build one from scratch. If a device has never sent a packet since the sensor was installed, it will not appear in the passive dataset. Asset discovery that relies entirely on observed traffic will always be an undercount.

The answer is not to simply apply active scanning to OT networks. The answer is to think about interrogation risk with the same rigor applied to any process change. Some queries are low-risk. Reading a coil status from a Modbus device at a low poll rate is structurally similar to what the SCADA system itself does continuously, and it is not inherently more dangerous than normal operation. Querying an EtherNet/IP device using CIP identity requests is a standard mechanism for device identification, and most modern PLCs respond to it without incident. The risk profile of active interrogation is not uniform. It is device-specific and context-specific.

This means the right framework is a tiered interrogation model, not a binary active-or-passive choice. Establish a passive baseline first, understand the communication patterns, identify the talking assets, and map the protocols. Then apply targeted, low-rate active queries to specific device classes where the interrogation method is known to be safe for that device type. For devices where active interrogation carries meaningful risk, such as older serial-connected RTUs and legacy safety instrumented systems, maintain passive monitoring and supplement with physical inspection or out-of-band data collection from the engineering workstation. The goal is coverage, not methodology purity.

What makes this difficult in practice is that it requires someone who understands both network security and process engineering to make those determinations. The security team knows what information they want. The engineering team knows what the process can tolerate. Neither group, working alone, can make good decisions about interrogation risk. This is a recurring pattern in OT security: the technical question is straightforward once you understand both domains, but the organizational structure rarely puts people with both kinds of knowledge in the same room.

The monitoring question matters beyond inventory. Detection capability in OT environments is almost entirely dependent on having an accurate picture of what normal looks like. Anomaly detection without a reliable baseline is noise generation. And a baseline built only from passive observation of currently-active assets will have gaps that correspond, almost exactly, to the assets an attacker would most want to use.

Passive-first is the right starting point. Passive-only is a comfort strategy.