Official intent
Continuously monitor OT so abnormal behavior is seen before it becomes downtime. The official source remains authoritative.
Read the official campaign ↗Why it matters
OT traffic is repetitive, which makes anomalies unusually meaningful — a new connection to a PLC is rarely benign. Monitoring turns that predictability into early detection of intrusions and of failing equipment, often before either causes a stoppage. Without it, the first sign of trouble is the process itself going wrong.
Deploying monitoring must not disturb the process. Use passive collection (taps, SPAN) rather than active scanning or agents on control devices, and place sensors with the process owner so nothing loads or interrupts real-time traffic. Visibility is the goal; a monitoring rollout that risks a trip has defeated its purpose.
Minimum / Strong / Advanced
Key OT network traffic is captured passively and a baseline of normal behavior exists.
An OT-aware monitoring tool alerts on anomalies — new assets, unexpected flows, protocol and logic changes — and alerts reach someone who acts.
Monitoring is continuous across zones, integrated with IT detection/response, and tuned so alerts are actionable and investigated.
Implementation timeline
- Identify where you can passively capture OT traffic (SPAN/taps)
- Confirm no monitoring will be placed as an agent on control devices
- Deploy passive capture on a critical segment
- Baseline normal traffic and assets with the process owner
- Enable anomaly alerts (new devices, unexpected connections, protocol/logic changes)
- Route alerts to a named responder
- Extend coverage across zones and sites
- Integrate OT alerts with IT detection and response
Implementation steps
- Identify passive capture points (SPAN ports, network taps) that see critical OT traffic.
- Deploy an OT-aware monitoring capability without placing load or agents on control devices.
- Baseline normal assets and communications with the people who run the process.
- Alert on meaningful anomalies — new devices, unexpected flows, protocol errors, controller logic changes.
- Route alerts to a responder, tune out noise, and connect OT detection to your overall response.
Validation
- Introduce a benign test device or connection and confirm monitoring detects it.
- Verify sensors are passive and add no measurable load to control networks.
- Confirm recent alerts reached a named person and were investigated, not just logged.
Evidence to retain
OT monitoring plan naming coverage, sensors, and alert ownership
Sensor placement and detection/alerting configuration
Alert investigation records and baseline documentation
Detection test result and sensor passivity confirmation
Common failure modes
Buying a monitoring tool and letting its alerts pile up unread, trying to run agents on fragile controllers, and baselining once but never updating it as the plant changes. An alert nobody owns is not monitoring.
Framework mappings
Independent mappings are aids, not authoritative equivalence or compliance determinations.