This is one of the reasons why OT network threat detection is different from standard IT security monitoring. In an office network, a new endpoint agent, vulnerability scanner or active discovery tool may be treated as a normal part of the security stack. In an OT environment, the same approach can introduce operational risk. A fragile controller, legacy engineering workstation or unmanaged industrial device may not tolerate unexpected traffic, software changes or aggressive probing.
At the same time, industrial environments can no longer rely on isolation as their main defense. IT/OT convergence has expanded the attack surface. Remote access is now common. Industrial Ethernet is widely used. SCADA systems exchange data with business applications. Maintenance teams, vendors and integrators need controlled access to systems that were once treated as separate from the corporate network.
This creates a difficult requirement: industrial organizations need better OT visibility and threat detection, but they need it without disrupting the processes they are trying to protect.
Flow-based detection offers a practical answer to that requirement. By analyzing communication metadata instead of actively probing devices or deploying software agents on fragile assets, security and network teams can detect anomalies, monitor segmentation, identify unexpected communication paths and investigate suspicious behavior with minimal interference in production environments.
Table of Contents
Why OT networks are blind by design
Many OT networks are not blind because nobody cares about visibility. They are blind because the environment was designed around different priorities.
Industrial systems often have long lifecycle expectations. A PLC, HMI, RTU, safety controller or engineering workstation may remain in production for 10, 15 or even 20 years. Hardware and software are replaced only when there is a strong operational reason, because every change requires planning, testing, approvals and maintenance windows. In many plants, the unofficial rule is simple: if the line is working, do not touch it.
This creates visibility gaps that are rarely seen in modern IT environments. Asset inventories may be incomplete. Network diagrams may not reflect years of small operational changes. Some devices may run outdated firmware or unsupported operating systems. Vendor-managed systems may be treated as black boxes. Remote access paths may exist for maintenance purposes but remain poorly monitored. Industrial protocols may communicate in clear text and may lack strong authentication or encryption by design.
OT communication also behaves differently from typical enterprise traffic. In many cases, industrial traffic is repetitive and deterministic. The same HMI communicates with the same PLCs. The same engineering station reaches a small number of controllers. The same historian collects process data at expected intervals. The same SCADA server exchanges traffic with known field devices.
This predictability is a strength for detection, but only when communication is actually monitored. Without network visibility, abnormal behavior can remain hidden inside routine operations. A new host speaking to a controller, a workstation crossing into another zone, an unexpected Modbus connection or a sudden increase in traffic between control segments may be visible on the wire, but invisible to the security team.
OT blindness is therefore not only an asset inventory problem. It is a communication problem. Organizations need to understand not only which devices exist, but also which systems communicate, which protocols they use, which zones they cross and whether those patterns are expected for the industrial process.
Why the IT security playbook breaks in OT
A direct transfer of IT security practices into OT can create more risk than value. The difference is not only technical. It is operational. IT security often optimizes for confidentiality, rapid patching and broad endpoint control. OT security has to account for safety, uptime, vendor certification, process integrity and the physical consequences of disruption.
Why you can’t install agents on OT devices
Endpoint agents are a central part of many IT security programs. They provide process visibility, malware detection, behavioral analytics and response capabilities. In OT, the agent-based model is much harder to apply.
Many industrial devices cannot support agents at all. PLCs, RTUs, sensors, drives and safety controllers are not general-purpose computing platforms. Even where Windows or Linux systems exist, such as engineering workstations, operator stations or historians, installing additional software may require vendor approval, validation testing and careful coordination with production teams.
The main concerns are practical:
- performance overhead on systems with limited resources;
- compatibility issues with legacy software;
- vendor support restrictions;
- unplanned reboots or service interruptions;
- difficulty maintaining agents across isolated networks;
- operational resistance to changing stable production assets;
- lack of agent support for proprietary or embedded devices.
This is why agentless OT security is more than a convenience. In many industrial environments, it is a requirement. Security monitoring has to observe the environment without modifying the devices that control production.
Why active scanning can destabilize industrial systems
Active scanning is another IT security practice that requires caution in OT. Vulnerability scanners, port scanners and discovery tools generate traffic toward target devices. In enterprise IT, this is usually acceptable when properly scheduled and tuned. In industrial environments, unexpected packets can cause problems for fragile equipment, legacy protocol stacks or devices with limited processing capacity.
The issue is not that every scan will break a PLC. The issue is that industrial operators cannot accept unnecessary uncertainty around production systems. A controller that behaves unpredictably during a scan, an HMI that loses communication, or a device that requires manual intervention can create operational and safety consequences that go far beyond a normal IT incident.
Passive OT monitoring became common for this reason. Instead of querying devices directly, passive monitoring observes communication already present on the network. This reduces the risk of disrupting the process and gives security teams visibility into actual communication patterns.
Active testing may still have a place in OT security, but it belongs in controlled conditions: lab environments, maintenance windows, approved segments and carefully scoped assessments. It should not be the default method for day-to-day visibility in live production networks.
The IT/OT convergence problem
The traditional view of OT as isolated from IT no longer reflects reality in many industrial organizations. Production environments increasingly depend on data exchange with business systems, centralized management, remote support, cloud analytics and third-party integrations.
This convergence creates new paths into OT:
- remote access used by vendors and maintenance teams;
- engineering laptops moving between IT and OT networks;
- historians exchanging data with enterprise applications;
- industrial DMZs connecting production systems with business systems;
- wireless and IIoT devices added to legacy environments;
- shared identity, backup or monitoring infrastructure;
- cloud-connected platforms and predictive maintenance tools.
Each connection can be legitimate and operationally necessary. Each connection can also become an attack path if it is not monitored and controlled. The security challenge is no longer limited to protecting the boundary between IT and OT. Teams also need to detect suspicious movement across zones, conduits and internal segments.
Passive, active… and a third way — flow-based detection
OT monitoring is often described as a choice between passive and active approaches. Passive monitoring observes traffic without interfering with devices. Active monitoring queries, scans or tests systems to discover assets and vulnerabilities. This distinction is useful, but it does not fully explain the architectural options available to industrial security teams.
Flow-based detection can be treated as a third operational layer within passive OT monitoring. It does not require endpoint agents. It does not actively scan controllers. It does not need to store every packet payload in order to detect many important anomalies. Instead, it uses flow metadata from network devices, probes or exporters to analyze communication patterns across the OT environment.
Flow-based detection focuses on questions such as:
- which systems are communicating across OT zones;
- which hosts are using industrial protocols;
- which communication paths violate segmentation rules;
- which devices have started talking for the first time;
- which internal hosts are communicating east-west in unusual ways;
- which OT assets are communicating with IT, internet or vendor networks;
- whether traffic volume, timing or direction has changed from the baseline.
This approach is especially valuable in industrial networks because OT traffic is often stable. Once normal communication is baselined, deviations become meaningful. A new host talking to a PLC, a controller communicating outside its zone, a workstation using Modbus for the first time, or an unexpected connection from IT to Level 2 can be detected as a change in communication behavior.
Flow vs deep packet inspection in OT
Deep packet inspection and flow-based monitoring are both useful, but they operate at different levels of detail. DPI analyzes packet contents and protocol semantics. Flow-based monitoring analyzes communication metadata, such as source, destination, ports, protocols, timing, volume and direction.
| Approach | What it sees | Strength in OT | Main limitation |
|---|---|---|---|
| Deep packet inspection | Packet payload, protocol commands, function codes, detailed application context | Strong protocol-level analysis, useful for specific industrial commands and process-aware detection | Higher storage and processing requirements; may require packet access and protocol parsers |
| Flow-based detection | Metadata about communication between systems | Scalable visibility, long retention, segmentation monitoring, anomaly detection, low operational impact | Does not show payload or full command-level detail |
| Active scanning | Responses from queried devices | Asset discovery and vulnerability assessment in controlled conditions | Can introduce operational risk in live OT environments |
| Endpoint agents | Process, file and system-level activity on supported hosts | Strong visibility on engineering workstations and servers | Often impossible or undesirable on industrial devices |
DPI is valuable when the analyst needs to understand specific industrial commands, such as read/write operations, function codes or protocol-specific behavior. Flow-based monitoring is valuable when the organization needs broad, scalable and low-friction visibility across zones and conduits.
In practice, the two approaches can complement each other. Flow data can identify where communication is abnormal, which segment requires deeper inspection, and which time window should be reviewed. DPI can then provide additional protocol-level detail where packet visibility is available and operationally appropriate.
How flow-based monitoring maps to the Purdue Model
The Purdue Model remains a useful way to describe industrial network architecture, even though modern environments are often more complex than the original layered model. Flow-based monitoring fits naturally into this structure because it focuses on communication between levels, zones and conduits.
A simplified monitoring view may look like this:
| Purdue level | Typical systems | Flow-based monitoring focus |
|---|---|---|
| Level 5 | Enterprise IT systems | Connections toward industrial DMZ, remote access, business applications |
| Level 4 | Site business planning and logistics | Data exchange with historians, reporting systems, production applications |
| Level 3.5 | Industrial DMZ | Controlled conduits between IT and OT, jump servers, patch repositories, remote access brokers |
| Level 3 | Operations management | SCADA servers, historians, engineering workstations, OT management systems |
| Level 2 | Supervisory control | HMIs, operator stations, control room systems |
| Level 1 | Basic control | PLCs, RTUs, controllers, protection relays |
| Level 0 | Physical process | Sensors, actuators, field devices |
Flow-based monitoring can be placed at key boundaries: IT/OT edge, industrial DMZ, control network core, inter-zone firewalls, data center links, remote access points and selected aggregation points inside the OT network. The objective is to see communication across conduits, not to interfere with devices.
A simple conceptual diagram:
Enterprise IT
|
| monitored conduit
v
Industrial DMZ
|
| monitored conduit
v
Operations / SCADA / Historian
|
| monitored conduit
v
HMI / Engineering / Control Network
|
| monitored conduit
v
PLC / RTU / Controller Segments
From a detection perspective, the most important question is whether communication follows the expected architecture. If Level 4 systems can directly reach controllers, if a vendor VPN bypasses the DMZ, if a workstation in one production cell talks to another cell, or if a controller initiates outbound communication toward IT, flow data can make those violations visible.
Establishing a baseline in a deterministic network
OT anomaly detection works best when the baseline reflects the actual process. Industrial networks often have stable communication patterns because production systems perform repetitive tasks. This makes flow-based detection well suited for identifying deviations.
A useful OT baseline should include:
- normal host-to-host communication;
- expected protocols for each zone;
- approved conduits between levels;
- typical communication timing and frequency;
- normal traffic volume by system and segment;
- known engineering workstation behavior;
- approved remote access paths;
- expected communication with historians, SCADA servers and HMIs;
- maintenance-window exceptions.
Once this baseline exists, the detection logic becomes more meaningful. The goal is not to flag every unknown packet as a critical incident. The goal is to identify changes that matter in the industrial context: a new talker, a new protocol, a new cross-zone path, an unexpected increase in traffic, or communication from a host that should remain isolated.
This approach also helps reduce false positives. Instead of applying generic IT rules to an industrial environment, detection is based on what is normal for that specific plant, line, cell, zone or process.
What an attack looks like in OT flow data
OT attacks do not always begin with dramatic process disruption. They often begin with reconnaissance, unauthorized access, quiet movement across zones or misuse of legitimate protocols. Flow data can reveal these early stages before the attacker reaches the point of process manipulation.
Reconnaissance and unexpected talkers
Reconnaissance in OT may appear as a host attempting to communicate with many devices, ports or segments that it does not normally access. The source may be a compromised engineering workstation, a remote access server, a vendor laptop, an IT host or a system placed in the industrial DMZ.
Flow-based indicators include:
- one host communicating with many OT assets in a short period;
- connections to multiple industrial protocol ports;
- communication attempts across several production cells;
- new traffic from IT networks toward OT systems;
- repeated failed or short-lived sessions;
- new devices appearing in controller or HMI segments.
In a deterministic environment, unexpected talkers are often more important than raw traffic volume. A small number of connections from the wrong host to the wrong controller can be more significant than a large amount of routine historian traffic.
Cross-zone and east-west traffic breaking segmentation
Segmentation is one of the foundations of OT security. Zones and conduits define which systems should communicate and under what conditions. Flow data helps validate whether the network behaves according to that design.
Suspicious patterns include:
- direct communication from enterprise IT to control systems;
- traffic bypassing the industrial DMZ;
- communication between production cells that should be isolated;
- remote access paths reaching controllers directly;
- new east-west traffic between engineering workstations and HMIs;
- traffic from one vendor-managed segment into another;
- controller communication outside its expected zone.
These patterns matter because many OT attacks require movement through intermediate systems. Attackers may compromise an IT host first, then move to a jump server, historian, engineering workstation or HMI before reaching controllers. Flow-based monitoring can expose the path before the final stage of the attack.
Unauthorized use of industrial protocols
Industrial protocols such as Modbus, DNP3, S7, OPC UA, EtherNet/IP and IEC 60870-5-104 are normal in OT environments. Their presence alone is not suspicious. The important question is whether the right systems are using the right protocols in the right direction and at the right time.
Examples of suspicious flow patterns include:
| Pattern | Why it matters |
|---|---|
| New host using Modbus toward a PLC segment | May indicate unauthorized engineering activity or reconnaissance. |
| DNP3 traffic from an unexpected source | May suggest misuse of a protocol outside approved paths. |
| S7 communication from a workstation outside the engineering zone | May indicate unauthorized access to Siemens controllers. |
| OPC UA traffic bypassing the DMZ | May violate approved architecture and expose process data. |
| Industrial protocol traffic outside maintenance windows | May indicate suspicious activity or unauthorized change attempts. |
Flow data will not show the full command semantics in the way DPI can. It can, however, show that a protocol appeared in an unexpected place, from an unexpected source, or across a conduit where it should not exist. That signal is often enough to trigger a deeper investigation.
Lessons from real OT attacks
Real industrial incidents show why visibility inside OT matters.
TRITON, also known as TRISIS, targeted Schneider Electric Triconex safety instrumented systems. Its significance was not only that malware reached an industrial environment, but that it targeted systems designed to protect physical processes. For defenders, the lesson is clear: monitoring should not stop at the IT/OT boundary. Safety, control and engineering paths require visibility as well.
Industroyer, also known as CrashOverride, was designed to affect electric grid operations and was used in the 2016 Ukraine power grid attack. Industroyer2 later showed that ICS-specific capabilities remained relevant in subsequent attacks against Ukrainian energy infrastructure. These cases underline the importance of monitoring protocol use, control-system communication and activity around substations, SCADA systems and engineering environments.
PIPEDREAM, also known as INCONTROLLER, demonstrated another important point: advanced OT attack tools can be built to interact directly with industrial devices and automation systems. Once an attacker has access to the OT network, the ability to discover, interact with and manipulate controllers becomes a serious risk.
The common detection lesson across these cases is not that every organization will face the same malware. The lesson is that attackers need communication paths. They need to reach engineering systems, controllers, safety systems, remote access points, industrial servers or protocol gateways. Flow-based monitoring helps reveal those paths, especially when the traffic crosses a zone boundary or deviates from normal process behavior.
Mapping detection to MITRE ATT&CK for ICS
MITRE ATT&CK for ICS provides a useful framework for describing adversary behavior in industrial environments. Flow-based evidence can support this mapping at the communication and behavior level.
| Flow-based observation | Possible ATT&CK for ICS mapping | Detection value |
|---|---|---|
| One host connecting to many OT assets or ports | Discovery | Indicates reconnaissance or asset enumeration. |
| New communication between IT and OT zones | Initial Access / Lateral Movement | Shows a possible path from enterprise systems into production. |
| Use of remote services across OT segments | Lateral Movement | Helps identify movement through engineering or supervisory systems. |
| New or unauthorized industrial protocol traffic | Command and Control / Impair Process Control, depending on context | Highlights protocol use that violates expected behavior. |
| Communication with controllers outside maintenance windows | Execution / Impair Process Control, depending on evidence | May indicate unauthorized interaction with process devices. |
| High-volume or unusual data transfer from OT systems | Collection / Exfiltration | Supports investigation of data movement or process information theft. |
| Traffic to known malicious or suspicious infrastructure | Command and Control | Indicates possible external attacker communication. |
The mapping should remain precise. Flow data can support a finding, but it does not automatically prove the full technique. A new Modbus connection from an engineering workstation may be legitimate during a maintenance window and suspicious at 2:00 AM from an unknown laptop. Context determines the conclusion.
A strong OT detection report should therefore combine three elements:
- observed flow evidence;
- industrial context, such as zone, asset role and maintenance schedule;
- ATT&CK for ICS mapping where the behavior supports a known tactic or technique.
This gives the security team a common language for reporting without losing operational nuance.
Compliance — how flow-based monitoring supports IEC 62443, NERC CIP and NIS2
Flow-based monitoring is not a compliance tool by itself, but it supports several capabilities that industrial security frameworks and regulations expect organizations to develop.
IEC 62443 emphasizes risk-based segmentation, zones and conduits, system integrity and defense-in-depth. Flow data helps validate whether zones and conduits are working in practice. It can show whether communication follows the approved architecture, whether unexpected paths exist, and whether new devices or protocols appear in sensitive areas.
NERC CIP, relevant to the North American Bulk Electric System, includes requirements around electronic security perimeters, access control, incident response and protection of critical cyber systems. Flow-based monitoring can support evidence of controlled communication paths, detection of unauthorized access attempts, review of network activity and incident investigation.
NIS2 raises expectations for cybersecurity risk management, incident handling, continuity and reporting across essential and important entities in the EU. For industrial organizations in scope, flow-based visibility supports the ability to detect suspicious activity, reconstruct incidents, assess impact and provide evidence for reporting and remediation.
Across these frameworks, the recurring operational need is similar: organizations must understand their communication paths, detect deviations, document incidents and prove that security controls are operating as intended. Flow data provides a practical evidence layer for those tasks.
Flow-based OT monitoring in practice with Sycope
In an OT environment, Sycope can support passive, flow-based monitoring by collecting and analyzing NetFlow, IPFIX, sFlow or related flow telemetry from network infrastructure, probes or key boundary points. The approach does not require installing agents on PLCs, controllers or other fragile industrial devices, and it does not depend on active scanning as the primary source of visibility.
A practical Sycope-based OT monitoring workflow may include:
- Collect flow data from the IT/OT edge, industrial DMZ, core switches, routers, firewalls or selected OT aggregation points.
- Map communication between zones, conduits, production cells and critical systems.
- Establish a baseline of normal OT communication by host, protocol, port, time and traffic volume.
- Detect new talkers, unauthorized protocols and cross-zone communication that violates segmentation.
- Monitor remote access paths, engineering workstations, historians, SCADA servers and key control-system segments.
- Alert on unusual communication patterns, such as new east-west traffic, suspicious external destinations or unexpected protocol use.
- Support investigation with historical flow data, filtering by host, port, protocol, time window or conversation.
- Document findings in a timeline that can support incident response, audit and compliance work.
This approach is especially useful when industrial teams need visibility without operational disruption. Flow-based detection does not replace protocol-aware DPI or specialist OT security controls, but it provides a scalable visibility layer that helps teams understand what is happening across the network.
For OT security managers, the value is reduced blind spots and better evidence. For NetOps teams in industrial environments, the value is clearer communication mapping and faster troubleshooting. For SOC teams, the value is earlier detection of movement, misuse and policy violations inside environments where endpoint telemetry is limited.
The practical result is a more defensible OT monitoring model: passive by design, focused on communication behavior, aligned with segmentation, and suitable for environments where production stability is the first priority.
FAQ
Can you monitor an OT network without installing agents?
Yes. OT networks can be monitored without installing agents by using passive network monitoring and flow-based detection. Instead of deploying software on controllers, PLCs or other industrial devices, the monitoring system analyzes traffic metadata collected from network infrastructure, probes or telemetry exporters.
This approach is particularly important in OT environments where devices may be legacy, vendor-managed, resource-constrained or too sensitive to modify without extensive testing.
Will network monitoring disrupt industrial processes?
Passive monitoring and flow-based detection are designed to minimize disruption because they observe existing communication rather than actively probing devices. When implemented correctly, they do not generate scanning traffic toward PLCs, HMIs or controllers.
Active scanning and vulnerability testing require more caution. They should be planned, approved and tested carefully, especially in live production environments, because some industrial systems may react unpredictably to unexpected traffic.
What’s the difference between passive and active OT monitoring?
Passive OT monitoring observes traffic that already exists on the network. It is commonly used for continuous visibility, anomaly detection and communication mapping because it reduces the risk of interfering with industrial processes.
Active OT monitoring sends queries, probes or scan traffic to devices. It can provide useful asset and vulnerability information, but it introduces more operational risk and should be used carefully, especially around fragile or legacy systems.
Flow-based detection is a passive approach that focuses on metadata: source, destination, protocol, ports, timing, volume and direction.
What protocols do OT networks use?
Common OT and ICS protocols include Modbus, DNP3, OPC UA, Siemens S7, EtherNet/IP, PROFINET, IEC 60870-5-104, IEC 61850 and vendor-specific protocols. The exact protocol mix depends on the industry, equipment vendors, architecture and age of the environment.
From a detection perspective, the question is not only which protocols exist, but whether they are used by expected systems, across approved paths and during normal operational windows.
How does flow-based detection map to the Purdue Model and IEC 62443?
Flow-based detection maps well to the Purdue Model because it can monitor communication between levels, such as enterprise IT, industrial DMZ, operations management, supervisory control and controller segments. It helps identify whether traffic follows expected paths or bypasses approved conduits.
It also supports IEC 62443 concepts such as zones and conduits. By analyzing flow data, teams can verify whether communication between zones matches the intended segmentation design and detect traffic that violates security assumptions.
