Operational Technology (OT) environments – PLCs, DCS, SCADA, safety systems – were designed for determinism and availability, not security. For decades, the assumption of air-gap isolation meant real-time monitoring of OT network traffic was considered unnecessary overhead. That assumption is no longer valid. Nation-state threat actors, ransomware groups, and insider threats now target industrial control systems with documented, destructive intent.

The Reality Check

Dragos and Claroty both report that the majority of OT incidents they investigate show dwell times exceeding 200 days – meaning attackers are present inside OT networks for months before detection. Continuous monitoring compresses that dwell time to hours or days.

What Continuous Monitoring Means in OT

Continuous monitoring in OT context is not the same as IT Security Information and Event Management (SIEM). OT monitoring requires passive, non-intrusive traffic inspection – active scanning can disrupt legacy PLCs and field devices. Dedicated OT network monitoring platforms (Dragos Platform, Claroty Continuous Threat Detection, Nozomi Networks Guardian, Microsoft Defender for IoT) perform deep packet inspection of industrial protocols: Modbus, PROFINET, EtherNet/IP, DNP3, IEC 61850, OPC UA.

These platforms build an asset inventory automatically from observed traffic – identifying every controller, HMI, historian, engineering workstation, and field device communicating on the network – and then establish a behavioural baseline. Deviations from baseline generate alerts.

Why Periodic Assessments Are Not Enough

An annual OT security assessment or penetration test provides a point-in-time snapshot. It identifies vulnerabilities present on the day of testing. It does not detect:

  • A new rogue device connected to the OT network by a contractor the week after the assessment.
  • Malware delivered via a vendor’s USB drive during a maintenance visit.
  • A compromised IT system conducting lateral movement into the OT network via a misconfigured firewall rule.
  • An insider slowly exfiltrating control system logic over weeks.
  • Reconnaissance traffic from an attacker already inside the network who has established persistence.

Only continuous, real-time traffic monitoring can detect these threats while there is still time to respond before operational impact occurs.

The Purdue Model Context

IEC 62443 and the Purdue Enterprise Reference Architecture define zones and conduits: Level 0 (field devices), Level 1 (basic control – PLCs/DCS), Level 2 (supervisory – SCADA/HMI), Level 3 (operations – historian, batch management), and Level 3.5 (DMZ – the boundary between OT and IT). Continuous monitoring must have visibility across all these levels, particularly at conduit crossing points where threats move between zones.

Traffic between Level 3 and the DMZ is especially critical – this is where command-and-control communication from externally compromised assets is most likely to be visible, before an attacker achieves deeper access to Level 1 and Level 2 systems.

Key Threats That Continuous Monitoring Detects

  • Unauthorised asset discovery: new IP addresses or MAC addresses appearing on OT network segments not in the approved asset register.
  • Engineering workstation activity outside maintenance windows: PLC configuration downloads or firmware updates occurring at 2 AM are high-confidence indicators of malicious or unauthorised activity.
  • Protocol anomalies: a Modbus write command sent to a function code address that has never been written to before – possibly indicating a process manipulation attempt (as seen in the TRITON/TRISIS attack against a Schneider Electric Triconex safety system in 2017).
  • Lateral movement: an engineering workstation communicating with multiple PLCs it has never previously communicated with, consistent with reconnaissance or malware propagation.
  • Known malware signatures: OT monitoring platforms integrate threat intelligence specifically relevant to ICS malware – Industroyer/Crashoverride, BlackEnergy, EKANS/SNAKE ransomware – with detection based on behaviour rather than file signatures alone.

Implementation Considerations

Deploying OT monitoring passively via SPAN ports on managed switches is the standard approach – it introduces zero latency or risk to control network operation. Network taps provide physical port mirroring where managed switches are not available. Data is fed to a monitoring sensor (typically a hardened Linux appliance) that performs protocol decoding and analytics.

Integration with a Security Operations Centre (SOC) – either internal or a managed security service provider with OT expertise – ensures alerts are triaged and actioned. An unmanned monitoring console generates alerts that go unread provides no protection.

The Compliance Dimension

Continuous monitoring is increasingly mandated or strongly recommended by regulatory frameworks applicable to critical infrastructure operators: NERC CIP (power sector), IEC 62443, NIST SP 800-82, and the EU NIS2 Directive. Organisations in energy, chemicals, pharmaceuticals, and water treatment that have not yet deployed OT monitoring face both increasing regulatory exposure and demonstrably higher breach risk.

The Bottom Line

The question is not whether your OT network will be targeted – it is whether you will know when it is. Continuous monitoring converts an invisible threat into a visible one, giving operators and security teams the time and information required to respond before a process is disrupted, a safety system is compromised, or production is lost. In OT security, detection speed is the variable that separates an incident from a catastrophe.

What OT-Specific Monitoring Tools Provide

Generic IT security monitoring tools (Splunk, IBM QRadar, Microsoft Sentinel) were not built for OT environments. They do not understand Modbus, PROFINET, EtherNet/IP, or the normal communication patterns of a DCS. Applying IT SIEM tools directly to OT traffic produces large volumes of false positives that overwhelm operations teams and erode trust in the monitoring system.

OT-specific monitoring platforms — Claroty, Nozomi Networks, Dragos, and Microsoft Defender for IoT — understand industrial protocols and can baseline normal OT communication patterns. They detect anomalies specific to OT attacks: reconnaissance scans targeting PLC racks, unsolicited write commands to controller registers, unexpected firmware download attempts, and communication from engineering workstations at unusual hours.

These platforms also provide asset inventory as a by-product of monitoring — they passively observe network traffic and build a device inventory showing every PLC, HMI, historian, and switch on the monitored network. For many OT environments that have never had a formal asset inventory, this is itself a valuable output.

Building a Realistic OT SOC Capability

A Security Operations Centre (SOC) that monitors IT networks 24/7 is a standard capability for large enterprises. OT monitoring requires different analysts with different skills — people who understand what a DCS controller is supposed to be doing at 3 AM, and can distinguish a configuration download from an attacker attempting a firmware modification.

Most OT operators do not have dedicated OT security analysts. The practical options are:

  • Hybrid IT/OT SOC: The existing IT SOC monitors OT alerts from the OT monitoring platform. OT engineers are on-call to validate and respond to OT-specific alerts. Works best when the IT SOC has baseline OT training and clear escalation procedures.
  • Managed OT security service: A specialist firm (Dragos MDR, Claroty MDR, regional MSSPs) provides 24/7 monitoring of OT alerts with OT-trained analysts. More expensive but removes the need to build internal OT security expertise.
  • Operational team integration: OT monitoring alerts are routed to the control room and treated as operational events, not IT security events. The operations team validates alerts and escalates to engineering or IT security as needed. Lower overhead but relies on operations staff having basic cybersecurity awareness.

Compliance Drivers for OT Monitoring

Continuous OT monitoring is increasingly mandated, not just recommended. NERC CIP-007 requires security event monitoring for High and Medium impact BES Cyber Systems. IEC 62443-3-3 Security Requirement SR 6.1 requires that OT systems provide audit record generation capability. NIST SP 800-82 (Guide to ICS Security) recommends continuous monitoring as a key control. Regulatory frameworks in the EU (NIS2 Directive) and US (CISA guidance, TSA cybersecurity directives for pipeline operators) are adding monitoring requirements for critical infrastructure operators. Starting a monitoring programme now positions organisations ahead of mandatory compliance requirements rather than scrambling to implement them under regulatory pressure.