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.