NDR for OT Environments: Why Passive Monitoring Is the Only Safe Architecture

The problem with inline monitoring in OT networks

When we talk about NDR (Network Detection and Response) in IT contexts, the inline deployment model is a legitimate option: the sensor sits in the traffic path, inspects packets in transit, and can block suspicious communications in real time. In IT this approach makes sense because the systems are designed to tolerate latency variations on the order of milliseconds.

In OT networks, placing any inline system between SCADA and PLC is a choice that can cause real industrial incidents.

The reason is simple: industrial control systems operate on deterministic cycles with precise timing. A PLC that receives a positioning command from a SCADA system expects the response within time windows defined by the physical process it controls. A chemical dosing system, a centrifuge, a robotic arm, a pressure control system: all have tight timing parameters, measured in milliseconds, that allow no variation.

Adding an inline network hop, even a seemingly harmless hop of 5 to 10 ms, can cause protocol timeouts to expire, desynchronize control cycles, and generate abnormal states in the physical process. The system does not pause: it faults, with everything that entails at the operational level and for physical safety.

What happens when industrial protocols miss their timing

OT protocols were not designed with the redundancy and latency resilience typical of modern IT protocols. Modbus TCP, PROFINET, EtherNet/IP, DNP3: all assume that the communication medium is predictable and low-latency.

Modbus TCP has configurable timeouts but historically short ones: many legacy implementations use values on the order of 100 to 300 ms. An inline sensor that introduces even a variable delay (jitter) within that window generates communication errors that the Modbus master interprets as an unreachable device.

PROFINET IRT (Isochronous Real Time) is even more stringent: it operates with cycles on the order of 31.25 microseconds. Any non-PROFINET-certified device inserted inline into an IRT network breaks bus synchronization.

EtherNet/IP in implicit I/O mode uses UDP connections with a Requested Packet Interval (RPI) that often drops below 10 ms. An inline system that introduces variability over UDP cannot guarantee delivery within the required times.

The result is not "the system performs worse": it is that the control system enters error states the process designer never anticipated, with consequences that depend on the specific plant but that, in critical contexts, can affect the physical safety of operators and of the plant.

The right architecture: passive out-of-band monitoring

The solution is not to give up OT visibility, which is indispensable, but to fundamentally change the monitoring architecture.

The principle is zero interference with the control path: the network sensor must never sit in the path of the packets that connect SCADA to field devices. It must receive a copy of the traffic, analyze it, and generate alerts, without ever touching the original packets.

There are two tools for doing this:

Network TAP (Test Access Point): a passive hardware device that creates an optical or electrical copy of the traffic on the segment and sends it to the sensor. The TAP has no IP address, introduces no measurable latency on production traffic, and cannot be configured remotely (it has no attack surface). It is the safest option for critical segments.

SPAN port (Switch Port Analyzer): most managed industrial switches support configuring a mirror port that replicates the traffic of one or more ports toward the sensor. The impact on production traffic is null or negligible; the main limitation is that, under high-volume traffic, the switch may drop some mirrored packets, which affects the completeness of the telemetry but not the production network.

In both cases, the analysis sensor receives traffic in read-only mode, has no ability to inject packets into the production network, and its malfunction does not affect the control systems in any way.

From telemetry to action: isolation and network changes

Passive monitoring solves the visibility problem, but it immediately raises the question of response: if the sensor cannot block traffic inline, how do you respond to a detected threat?

The answer requires a shift in perspective compared to IT: in OT, the response action is not the inline blocking of a packet, but the modification of the network architecture as a containment tool.

Isolation at the switch level: managed industrial switches support dynamic reconfiguration of VLANs. An OT device showing anomalous behavior (communications toward unexpected addresses, scanning patterns, abnormal traffic toward the SCADA master) can be moved into a quarantine VLAN via the switch API, with no physical intervention on the plant.

Dynamic updating of ACLs on OT firewalls: firewalls placed at boundary zones (typically between the SCADA zone and the field network, or between OT and IT) can receive automatic updates to their access control lists in response to sensor alerts. Traffic toward an anomalous destination is blocked at the zone level, not at the level of a single hop.

Selective blocking of remote access: one of the most exploited attack surfaces in OT environments is remote access for maintenance. In response to an alert indicating suspicious activity on a remote access session, the first action is to revoke the session and temporarily disable the remote access channel for that system, pending verification.

Progressive microsegmentation: the long-term response to OT incidents often leads to a more granular segmentation of the network. A plant that previously had a single flat field network can be segmented into zones based on process criticality, with explicit communication rules between zones. This is a permanent architectural change that reduces the attack surface for future incidents.

Managing OT alerts: operational context first

Passive monitoring generates alerts that must be contextualized before they become actionable. This is the point where many implementations fail: an alert of "anomalous communication over Modbus" may be an attack, but it may also be a maintenance technician using a laptop with an unregistered IP address, or a scheduled firmware update that was not communicated to the security team.

The effectiveness of an OT monitoring system depends on three elements:

Accurate baseline: before going into production with monitoring, you need an observation period in which you establish the network's normality: which devices communicate with which, how often, on which ports and protocols. A poorly calibrated baseline generates a volume of false positives that saturates the team's response capacity.

Integration with the operational calendar: planned maintenance, firmware updates, and scheduled configuration changes must be visible to the monitoring system in order to suppress legitimate alerts. An OT sensor that is not integrated with the plant's operational processes produces low-quality alerts.

Escalation coordinated with operations: when an alert requires an isolation action, the decision cannot be made unilaterally by the security team. The operations manager must be involved before any intervention on the production network, because they know the current state of the plant and can assess the operational consequences of isolation.

Visibility without risk: the guiding principle

Monitoring OT networks is non-negotiable for any industrial organization that wants a real rather than nominal security posture. The attack vectors toward OT environments (lateral movement from IT, compromise of remote access, supply chain attacks on field devices) are all detectable through network traffic analysis.

But visibility must be built with the awareness that an OT environment is not an IT environment with different devices. It is an environment where the reliability of the physical process has absolute priority, and any security tool that compromises it, even only potentially, introduces a risk that exceeds the risk it intends to mitigate.

Passive monitoring, response through the network architecture, coordination with operations: these are the principles that make it possible to build real OT visibility without putting the continuity of the industrial process at risk.

The MON5 angle

The architecture described in these pages, an out-of-band sensor on a TAP or SPAN with zero interference on the control path, is the same one the PROTECT phase of MON5 is built on. The sensor works in a completely passive way and decodes native industrial protocols: Modbus, Siemens S7, OPC UA, PROFINET, EtherNet/IP. ML anomaly detection starts from a baseline built on the plant's real traffic, reducing the false positives that saturate teams.

The path is modular: you start with visibility and activate detection capabilities in phases. If you want to assess where to position the sensors in your network, request an OT assessment.