OT security requires detection capabilities that serve both operational response and incident investigation — but the operational constraints of industrial environments shape those capabilities in ways that diverge sharply from IT security monitoring. This architectural difference creates detection requirements that cannot be satisfied by extending standard IT tooling to OT network segments.
The wrong model
Most organizations begin OT detection by deploying IT intrusion detection tools in OT network segments. This approach captures network anomalies but misses the detection capability that matters most: whether an event represents cyber activity targeting process manipulation or normal operational variation.
IT detection logic treats OT devices as network endpoints generating traffic patterns. But OT devices control physical processes where manipulation can create safety consequences or production disruption without generating network signatures that IT tools recognize as malicious.
It is worth distinguishing two categories of IT security tooling here. General-purpose network intrusion detection systems lack industrial protocol awareness entirely. Purpose-built OT network detection platforms — from vendors such as Claroty, Dragos, Nozomi, and others — already perform deep packet inspection of industrial protocols including Modbus, DNP3, S7comm, EtherNet/IP/CIP, OPC UA, and IEC 61850.
The real gap is not protocol parsing, which these platforms address, but process context: understanding whether a correctly formed, protocol-valid command represents legitimate operational activity or an attack. That distinction requires knowledge of normal process behavior, operational modes, and physical constraints — not just protocol semantics.
This gap has been exploited in documented incidents. Stuxnet manipulated PLC logic while replaying normal sensor values to operators, making process disruption invisible to monitoring systems that lacked physical process context. Industroyer/CrashOverride used native ICS protocols to send commands that were protocol-valid but operationally destructive.
TRITON/TRISIS targeted safety instrumented systems directly, and PIPEDREAM/INCONTROLLER demonstrated modular capability against multiple industrial control platforms. Each of these attacks would have been difficult or impossible to detect through protocol anomaly detection alone, because the commands were not malformed — they were contextually wrong.
A prerequisite for any of the detection capabilities described below is a current asset inventory. Without knowing which controllers exist, which engineering workstations communicate with them, and what normal operational behavior looks like for each asset class, detection rules cannot be calibrated and alert volume becomes unmanageable. Asset inventory is not a parallel workstream; it is a dependency.
What IT detection does not produce in OT
Network intrusion detection systems identify protocol anomalies, unusual connection patterns, and traffic volume changes. In OT environments, even protocol-aware tools face three critical detection gaps without process context.
Detection cannot distinguish between authorized operational changes and unauthorized process manipulation when both generate identical, valid protocol traffic. A legitimate setpoint change during production startup creates the same Modbus write commands as an attack that manipulates process parameters. The difference is context: who initiated the command, from which system, during which operational mode, and whether the resulting parameter falls within a physically plausible range for the current process state.
Endpoint detection tools designed for IT workstations generate false positives on engineering workstations where PLC programming software performs operations that appear suspicious from an IT security perspective. Normal engineering workflow includes direct device communication, configuration file modification, and elevated privilege operations — all of which look anomalous to IT endpoint logic.
IT boundary monitoring treats IT/OT network crossing points as standard network segments rather than directional security boundaries. Modern OT network architecture uses a demilitarized zone (DMZ) layer — consistent with the Purdue Model and IEC 62443 — where historian replicas, data diodes, and application-layer gateways control data flow. Normal historian data replication from OT to IT creates baseline outbound traffic that can mask unauthorized lateral movement in the opposite direction, from IT systems reaching Level 3 or below.
The tradeoff is visibility versus context. Organizations that rely on IT detection alone can identify network anomalies but cannot determine whether those anomalies represent operational events or security events.
The Five detection capabilities
OT detection architecture requires five capabilities that understand industrial protocols, process behavior, and operational constraints. Each addresses detection requirements that IT monitoring logic — even protocol-aware IT monitoring — cannot fulfill without process context integration.
A note on passive monitoring: OT network detection is predominantly passive, using network TAPs or SPAN ports rather than inline agents or active scanning. TAP and SPAN placement must account for the topology of each network level, including serial links, legacy fieldbus segments (PROFIBUS, Foundation Fieldbus, DeviceNet), and non-IP protocols that may require hardware-level protocol converters or dedicated sensors.
Some sites use scoped active querying for asset discovery, but this carries higher risk on legacy PLCs with limited processing headroom and should be evaluated on a device-by-device basis rather than applied uniformly. Where passive coverage cannot reach a segment due to architecture or legacy protocol constraints, compensating controls — network segmentation, change control enforcement, physical access restrictions — should be documented.
The OT detection model
| Detection capability | What it monitors | Why protocol-aware detection alone is insufficient | OT operational constraint | Process context required |
|---|---|---|---|---|
| Industrial protocol anomaly detection | Control commands to PLCs and controllers, register reads and writes, configuration changes pushed to field devices, unexpected protocol commands across Modbus, DNP3, S7comm, EtherNet/IP/CIP, OPC UA, IEC 61850, and others | Protocol-aware tools can flag malformed packets; they cannot flag contextually wrong commands — valid writes to the wrong register, from the wrong source, during the wrong operational phase | Predominantly passive monitoring; active querying carries disruption risk on legacy devices and should be scoped carefully; detection must not generate traffic that triggers unintended device responses | What normal command patterns look like for each controller type; which registers are written by which systems under normal operation; which commands would only be sent during specific maintenance operations |
| Process behavior baseline monitoring | Sensor output values over time, setpoint changes, controller mode changes, alarm state changes, historian data trends | Process physics constrain what readings are plausible; sensor spoofing within individually plausible ranges — as demonstrated by Stuxnet-style replay — is invisible without cross-parameter correlation and physical process modeling; safety instrumented systems (SIS) and basic process control systems (BPCS) require separate baselines and different alert thresholds given the safety-critical function of the SIS | Process variation is normal during production changes, startups, and shutdowns; detection must be calibrated to distinguish abnormal conditions from expected operational variation; SIS assets warrant heightened alert sensitivity | Normal operating ranges for each process parameter; what parameter changes are expected during specific operational modes; which setpoint combinations are physically plausible for the current process state; SIS setpoint limits and expected actuation conditions |
| Engineering workstation activity monitoring | PLC programming software activity, configuration pushes to controllers, new connections initiated from workstation to OT devices, unusual access to engineering project files or historian data | IT endpoint detection does not understand engineering software behavior; normal PLC programming activity generates events that look unusual from an IT endpoint detection perspective | Engineering workstations must remain functional for maintenance operations; endpoint monitoring tools that disrupt workstation performance can prevent operators from completing time-sensitive tasks | Which engineers are authorized to make changes to which controllers; what programming activity is expected during a maintenance window; which types of configuration changes require change control authorization |
| Remote access and vendor session monitoring | Remote session source, destination systems reached, commands executed, files accessed, duration, and timing relative to scheduled maintenance windows | IT remote access monitoring does not understand OT operational context; a vendor reaching systems outside their authorized scope may appear as normal remote access activity without OT-specific session context | Remote access monitoring must not introduce latency that disrupts time-sensitive maintenance operations; monitoring must work with OT-specific remote access tools, including jump hosts and vendor portals | Which vendor should reach which systems; what commands are expected for the specific maintenance task; which maintenance operations justify which session durations; whether the session was pre-scheduled |
| IT/OT boundary correlation | Traffic direction at IT/OT boundary and DMZ, destination systems reached from IT side, connection initiation direction, traffic volume relative to normal data replication patterns, IT-initiated sessions reaching Level 3 or below | IT network monitoring does not enforce directional security logic; historian replication from OT to IT creates normal outbound baseline traffic that masks unauthorized inbound lateral movement; without DMZ architecture awareness, alerts conflate legitimate data flow with unauthorized access | The IT/OT boundary must remain available for operational data flow and historian replication; blocking normal data exchange disrupts business intelligence and operational monitoring | What the normal data flow pattern looks like in direction, volume, and timing; which IT systems legitimately initiate connections to DMZ-layer devices; which OT systems at Level 3 or below should never receive inbound connections from IT; expected historian replica synchronization patterns |
Remote access and vendor session monitoring deserve particular emphasis as an early-priority control. Vendor remote access represents one of the most consistently exploited attack surfaces in documented ICS incidents, and monitoring of vendor sessions — scope, timing, systems reached, and commands executed — provides high-value detection coverage relative to implementation complexity.
Process behavior baseline monitoring and industrial protocol anomaly detection provide detection coverage that IT tools cannot replicate, but organizations with limited initial resources should evaluate remote access monitoring alongside these two rather than treating it as a supplementary capability.
Where detection is not technically feasible — due to legacy protocol constraints, serial fieldbus segments, or asset fragility — compensating controls should be formally documented. Relevant standards including IEC 62443, NIST SP 800-82, and NERC CIP (for electric sector organizations) provide frameworks for characterizing detection gaps and selecting compensating controls.
Structured response as a detection requirement
OT detection architecture must couple detection capabilities with pre-defined response guidance — not because operations consultation should be eliminated, but because unstructured real-time consultation introduces delays that may exceed acceptable response windows.
Operations teams hold safety and process authority. Any response action that touches Level 0–2 assets — the physical process layer — requires operational authorization, and automated response at that layer is generally not appropriate. Automated response is more viable at the IT side of the boundary or in the DMZ: blocking a connection at the IT/OT firewall, isolating a compromised jump host, or terminating an unauthorized remote session through a vendor access platform. These actions can be executed without touching operational assets directly.
Detection rules should assign each alert to one of three response guidance categories:
Immediate automated response safe — Actions executable without operational consultation, typically confined to IT-side or DMZ assets. Example: blocking an unauthorized inbound connection at the IT/OT boundary firewall.
Pre-agreed consultation required — Actions that require operational authorization but follow a defined procedure with identified contacts and decision criteria. The consultation is structured, not improvised. Example: coordinating with the shift supervisor before isolating a controller segment showing unauthorized configuration writes.
No automated response; monitor and escalate — Situations where any response action carries operational or safety risk requiring senior operational and safety review. Example: anomalous commands detected on a safety-instrumented system.
The goal of pre-agreed response tiers is not to eliminate operations involvement but to reduce the time required for that involvement by establishing decision criteria in advance. Detection rules that generate alerts without a pre-defined response category create delays that can exceed acceptable response windows — particularly for process excursions, which can become consequential within seconds, not minutes.
This response architecture should be tested against the MITRE ATT&CK for ICS framework, which maps adversary techniques to detection opportunities and response considerations across the ICS attack lifecycle.
OT/IT detection coordination
OT detection capabilities coordinate with IT security monitoring at three integration points: shared alert correlation, boundary event correlation, and incident escalation coordination.
Shared alert correlation combines OT process behavior alerts with IT network anomaly alerts to identify attack progression spanning both environments. IT network monitoring detects lateral movement from corporate systems to OT boundary devices; OT detection identifies whether that movement reaches operational systems.
The coordination challenge involves time scale differences, but these require precise characterization. Process excursions can become safety-relevant within seconds. OT operational response — isolating a segment, coordinating with a shift supervisor — may need to occur within minutes. IT SOC investigation, by contrast, operates on hours-to-days timescales for forensic analysis and incident documentation.
Alert correlation logic must account for these different response cadences: an OT process behavior alert and an IT boundary alert that coincide within a defined time window indicate potential attack progression and should trigger OT-side operational assessment immediately, not queue for IT investigation cycles.
Organizations should establish alert correlation rules that trigger when IT boundary alerts coincide with OT process behavior anomalies within defined time windows. The correlation indicates potential attack progression rather than coincidental operational and security events. SIEM integration between OT detection platforms and IT security operations centers should preserve the operational urgency of OT alerts rather than normalizing them to IT investigation timelines.
Diagnostic question
OT detection architecture completeness can be evaluated through a diagnostic question that tests whether the detection program provides sufficient operational context for response decisions.
For any anomalous event detected in your OT environment, can the detection program answer: is this cyber activity or process variation, which operational systems are affected, and what pre-defined response tier applies?
If every alert requires unstructured real-time consultation to answer these questions, the detection model is incomplete. The detection capabilities should provide sufficient process context and pre-agreed response structure to enable timely decisions — with operations holding authority over process-layer actions, and that authority exercised through defined procedures rather than improvised coordination.
The test question for each detection capability: does this detection rule produce alerts with a pre-defined response tier, or alerts that require improvised consultation to determine what to do? Detection rules that consistently fall into the latter category indicate gaps in process context integration or response planning — not necessarily gaps in detection logic alone.
