What is OT cybersecurity?

These terms are often used interchangeably, but they have slightly different scopes. OT (Operational Technology) is the broadest term: it encompasses all hardware and software that monitors and controls physical processes and devices, including building automation, transportation systems, and industrial manufacturing, not just traditional industrial automation.

ICS (Industrial Control Systems) is a subset of OT that specifically refers to systems that directly control industrial processes: PLCs, DCS, RTUs, safety instrumented systems, and the engineering workstations and historians that support them. ICS security is a more specific term for the security of that control system layer.

SCADA (Supervisory Control and Data Acquisition) is a category of ICS that typically refers to systems monitoring and controlling geographically distributed assets: pipelines, power grids, water distribution networks. SCADA security addresses the specific challenges of that distributed architecture. In practice, "OT cybersecurity" is the dominant umbrella term in current usage, with ICS and SCADA understood as components within it.

IT security tools were designed for general-purpose computing environments. The most critical issue is active scanning: vulnerability scanners and network discovery tools that generate high volumes of probe traffic can overload or crash legacy PLCs, DCS controllers, and RTUs that were designed for deterministic, low-overhead communication. Active scan traffic can cause network congestion on time-sensitive control networks, potentially disrupting the real-time control loops that PLCs execute. Several documented incidents have involved plant disruptions caused by IT security teams running scans on OT networks without understanding these constraints.

Beyond scanning, IT security tools typically do not understand OT-specific protocols. An intrusion detection system that does not recognize Modbus, EtherNet/IP, or DNP3 traffic cannot distinguish normal OT communication from an anomalous one. An endpoint protection agent running on a SCADA server may flag legitimate industrial process control software as suspicious. These tools need OT-aware variants that understand industrial protocols and have been specifically validated against OT system constraints before deployment in production OT environments.

IEC 62443-2-3 provides an OT-specific patch management framework built around risk-based assessment rather than fixed timelines. For each unpatched vulnerability, evaluate its exploitability in your specific OT network context (is the affected service exposed to the IT network? is the device accessible from outside a well-controlled zone?) and its potential impact (does this device control a safety-critical process?). Then implement compensating controls appropriate to the risk: network isolation that prevents the vulnerability from being reached, OT-aware monitoring that would detect exploitation attempts, or temporary access restrictions while a patch is prepared.

Document the accepted risk formally: what vulnerability is unpatched, what compensating controls are in place, and what is the target timeline for remediation tied to the next validated maintenance window. Coordinate with the equipment vendor for patch validation in a test environment before production deployment. Never apply patches in a production OT environment without vendor validation and a tested rollback procedure.

The Purdue Model's physical layer hierarchy is less applicable than it was in the 1990s, because IIoT devices now connect directly to cloud platforms, edge nodes publish MQTT data across network boundaries, and remote operations centers access plant-level data from central IT infrastructure. Some practitioners argue this makes the model obsolete.

The more useful framing is that the Purdue Model's core principle, that systems with different security requirements and operational functions should be separated by controlled interfaces, remains as relevant as ever. The iDMZ at Level 3.5 is more important as a security control now than when the model was designed, because the number of legitimate data flows crossing the IT/OT boundary has increased. Most current OT security frameworks, including NIST SP 800-82 Rev. 3 and IEC 62443's Zone and Conduit model, are extensions and adaptations of the Purdue hierarchy rather than replacements for it. The practical answer is to use the Purdue Model as a mental framework for segmentation planning while accepting that modern OT architectures require adapting its physical topology assumptions to cloud and IIoT realities.

Zero trust in IT means never trusting network location as a proxy for trustworthiness: every user and device must authenticate and authorize for every resource request, regardless of whether they are inside the corporate network perimeter. This is well-suited to IT environments where devices are general-purpose computers that can run authentication agents and participate in identity management systems.

Applying zero trust to OT environments requires adaptation. Legacy PLCs and RTUs cannot run authentication agents, cannot participate in modern identity management systems, and cannot tolerate the latency that continuous authentication might introduce in time-critical control loops. Zero trust for OT is better understood as micro-segmentation (making zones small enough that the blast radius of any compromise is limited), strict conduit controls (ensuring every device-to-device communication path is explicitly authorized), privileged access management (requiring step-up authentication for all engineering and administrative access), and continuous behavioral monitoring (alerting on communications that deviate from established baselines). These principles implement zero trust intent within the operational constraints of OT environments.

Applicable requirements vary significantly by sector and geography. In North America, NERC CIP applies mandatory requirements to bulk electric system owners and operators. Chemical sector facilities handling certain quantities of hazardous chemicals are subject to CISA Chemical Facility Anti-Terrorism Standards (CFATS). Water utilities over a certain size must conduct cybersecurity assessments under America's Water Infrastructure Act. Nuclear facilities have NRC cybersecurity requirements. In the EU, the NIS2 Directive sets minimum cybersecurity requirements for operators of essential services, including energy, water, transport, and digital infrastructure, with implementation in member states' national law.

Beyond sector-specific mandates, insurance requirements have become a significant driver. Industrial cyber insurers increasingly require evidence of OT security controls, network segmentation, and asset inventory before offering coverage or setting premiums. Many organizations find that insurance requirements are a more immediately actionable driver of OT security investment than regulatory compliance, particularly in sectors without mandatory cybersecurity standards.