# Security Monitoring Architecture for OT
Security Monitoring Architecture for OT is the structured framework of sensors, collection points, data flows, analysis engines, and response workflows that provides security teams with continuous awareness of what is happening inside operational technology networks. This architecture exists because OT environments present security challenges that differ fundamentally from those in enterprise IT networks.
Industrial control systems, SCADA platforms, programmable logic controllers, and distributed control systems were designed for reliability and deterministic performance, not security visibility. These systems control physical processes in manufacturing plants, power generation facilities, water treatment systems, and critical infrastructure. The consequences of undetected compromise are not data breaches: they are physical damage, safety incidents, regulatory violations, and operational shutdowns.
OT monitoring architecture spans passive network monitoring, protocol-aware deep packet inspection, asset inventory and behavioral baselining, log aggregation, anomaly detection, alerting, and incident response integration. It defines where sensors are placed, how data is collected without disrupting process communications, where analysis occurs (on-premises, at the DMZ, or in a centralized SOC), and how findings are acted upon.
This architecture is distinct from IT security monitoring in several critical ways. OT monitoring cannot rely on host-based agents installed on PLCs or RTUs because those devices typically lack compute resources, and any unapproved software poses a stability risk. Active scanning is generally prohibited because polling traffic can disrupt real-time control loops. Protocols such as Modbus, DNP3, EtherNet/IP, and PROFINET require specialized parsers that generic SIEM tools do not natively provide.
Without a deliberate architecture, monitoring efforts are fragmented, incomplete, and operationally risky. The architecture must evolve as the OT environment changes while maintaining strict operational constraints that prioritize availability over security convenience.
Passive Network Monitoring Foundation
The foundation of OT security monitoring is passive traffic capture on OT network segments. Span ports or network taps are placed on switches at the Purdue Model Level 1 (field devices) and Level 2 (supervisory control) boundaries. These taps mirror traffic to dedicated monitoring appliances without injecting any packets into the control network. The monitoring appliance performs deep packet inspection using OT-protocol-aware parsers that understand industrial communication patterns.
For example, in a natural gas compression facility running Modbus TCP between a supervisory workstation and field-mounted compressor controllers, the passive sensor reads every Modbus function code and register address seen on the wire. It builds a baseline of expected read/write operations during normal operation. When an unexpected write command targets a coil address outside the historical baseline, the system generates an alert before the command completes its effect on the physical process.
The passive approach is operationally critical. A correctly deployed network tap introduces no traffic into the control network and cannot disrupt process communications. This distinguishes proper OT monitoring from poorly designed implementations that poll devices or inject test traffic.
Asset Discovery and Inventory
OT monitoring tools construct an asset inventory from passively observed traffic. Every device that communicates on the network, including those not documented in any CMDB, is identified by MAC address, IP address, vendor OUI, and protocol behavior. This process is continuous: when a new device appears (a technician's laptop, an unauthorized wireless access point, a replaced PLC with different firmware), the architecture detects the change automatically.
This capability addresses a chronic operational problem. OT asset inventories are notoriously incomplete. A 2023 Claroty survey found that 38 percent of OT assets discovered through passive monitoring were unknown to the asset owners before monitoring began. Unknown assets cannot be protected, and they represent immediate blind spots for threat detection.
Behavioral Baselining and Anomaly Detection
Once a stable traffic baseline is established (typically over two to four weeks of normal operations across multiple shift cycles and production modes), the monitoring system applies rules and machine learning models to identify deviations. Detection categories include:
Data Collection and SIEM Integration
OT monitoring data must be aggregated and correlated with IT-side data at an appropriate boundary. The industrial DMZ (Purdue Level 3.5) serves as the collection and forwarding layer. Syslog, SNMP traps, and OT-specific event feeds from the monitoring appliance are normalized into a common event format and forwarded to the SIEM or SOC platform.
Critically, this data flow is unidirectional from OT to IT. Firewall and data diode configurations ensure that correlation data leaves the OT environment but no unsolicited traffic returns into it. This maintains the operational integrity of control networks while enabling enterprise-wide threat correlation.
Concrete Scenario: Detecting Lateral Movement Post-HMI Compromise
Consider a water treatment plant where an attacker has obtained credentials to an HMI workstation through a phishing email sent to an operations supervisor. The attacker logs into the HMI remotely via VPN. The monitoring architecture observes:
Each signal individually might be low confidence. Correlated in sequence by the monitoring architecture, they trigger a high-confidence alert that reaches the SOC within minutes. The response team isolates the HMI from the control network before the chemical dosing command executes.
This scenario mirrors the Oldsmar, Florida water treatment incident of February 2021, where an attacker accessed a SCADA system and attempted to increase sodium hydroxide levels to 111 times the normal concentration. Monitoring architecture that correlated remote access events with process command anomalies would have provided earlier detection than the operator who visually noticed cursor movement on the screen.
Without a defined security monitoring architecture, OT environments operate effectively blind. Operators know what their process is doing through instrumentation, but they have no visibility into whether the control systems directing that process have been manipulated. Attackers who compromise OT environments typically spend weeks or months in reconnaissance before taking destructive action. That dwell time is the window in which monitoring can detect and eject them.
The business impact of undetected OT compromise is severe. Physical damage to equipment requires capital replacement, not just software remediation. A turbine damaged by manipulated control logic, as occurred in the Aurora Generator Test in 2007, is not restored by reimaging a server. Production downtime in manufacturing environments costs tens of thousands to hundreds of thousands of dollars per hour. Safety incidents expose organizations to regulatory liability, litigation, and reputational damage that persists for years.
The most common misconception about OT security monitoring is that it is too risky to implement because monitoring traffic might disrupt operations. This is a misunderstanding of how properly designed passive architectures work. When vendors and operators raise availability concerns about monitoring, those concerns almost always apply to poorly designed implementations, not to architectures built on established OT monitoring principles.
A second misconception is that existing IT security monitoring (a SIEM receiving firewall logs) is adequate for OT visibility. Firewall logs show what crosses network boundaries. They provide no visibility into what happens within the control network segments where most adversarial activity occurs after initial access.
The 2021 Colonial Pipeline ransomware attack illustrates this point. The attack did not directly compromise OT systems, but the operators shut down the pipeline because they lacked confidence that their OT systems were clean, having insufficient monitoring to verify. A mature OT monitoring architecture would have provided the visibility needed to make an informed operational decision rather than a precautionary shutdown that cost approximately $4.4 million in ransom and immeasurable economic disruption.
Organizations that delay implementing OT monitoring architecture often cite cost concerns, but the cost of monitoring is trivial compared to the cost of unplanned downtime. A passive monitoring deployment for a mid-sized manufacturing facility typically costs less than two hours of production downtime.
CDA approaches Security Monitoring Architecture for OT through the Planetary Defense Model (PDM), treating OT environments as distinct planetary bodies with their own gravity, atmospheres, and threat exposures. The relevant PDM domains are SPH (Security Posture and Hygiene) and TID (Threat Intelligence and Detection), which together govern the continuous measurement, maintenance, and improvement of an organization's defensive state.
The CDA methodology governing this domain is Autonomous Posture Command (APC), described by the operational mantra: "Your posture adapts. Your hygiene never sleeps." In OT environments, this means that monitoring is not a periodic audit activity. It is a continuous operational function, and the architecture must be designed to support it without human initiation of each monitoring cycle.
CDA approaches OT monitoring architecture with several specific operational commitments that differentiate it from conventional approaches. First, CDA designs monitoring zones that map to actual OT network topology, not to idealized reference diagrams. Most OT networks have legacy flat segments, undocumented VLANs, and equipment that predates current segmentation designs. The monitoring architecture must work with the actual network, not the network that should exist on paper.
Second, CDA requires that every monitoring architecture include a formal process for alert triage that accounts for OT operational context. An alert about an unusual write command means something different during a scheduled maintenance window than during normal production. APC integrates maintenance scheduling, shift handover data, and work order systems into the alert context so that SOC analysts have the operational picture they need to make correct decisions quickly.
Third, CDA differentiates between monitoring coverage (what percentage of OT network traffic is observed by sensors) and monitoring effectiveness (what percentage of relevant threat behaviors would actually generate actionable alerts). Most organizations measure coverage. CDA measures effectiveness by running threat scenarios derived from MITRE ATT&CK for ICS against the deployed architecture and documenting detection gaps.