OT cyber security is the practice of protecting operational technology systems, including industrial control systems, SCADA platforms, and the physical processes they govern, from cyber threats that could cause equipment failure, production loss, or physical harm to people. Unlike traditional IT security, where confidentiality sits at the top of the priority stack, OT security places availability and safety first because a compromised sensor or controller can shut down a power grid, contaminate drinking water, or trigger a pipeline explosion.
If you run industrial operations or advise clients who do, the convergence of IT and OT networks has fundamentally changed your threat surface. Systems that once ran in complete isolation now connect to enterprise networks, cloud dashboards, and vendor remote-access portals. That connectivity brings efficiency gains and real-time data that operations teams value, but it also exposes equipment designed in an era when network attacks were not a design consideration. The result, as of 2026, is an attack surface that grows faster than most organisations can defend.
This guide covers the Purdue model, the specific security priorities that define OT environments, the practical constraints around patching and scanning, and the frameworks, IEC 62443 and NIST SP 800-82 Rev 3, that give you a structured path forward.
Why OT Cyber Security Differs From IT Security
The CIA triad in IT security ranks confidentiality, integrity, then availability. OT security inverts that entirely. For a chemical plant or a water treatment facility, the sequence is safety, availability, integrity, and confidentiality last. That inversion drives every architectural and operational decision you make in an OT environment.
Consider a typical Windows server in an enterprise network. You patch it on Patch Tuesday, reboot it, done. In an OT environment, the programmable logic controller (PLC) running your process may have been operating continuously for three years. The vendor’s patch cycle might be annual. The maintenance window to take the system offline safely might be four hours once every eighteen months during a scheduled shutdown. Missing that window means waiting another year and a half. This is not negligence; it is operational reality, and any security programme that ignores it will fail. A programme that treats OT like IT in this regard will generate findings that operations teams cannot act on, destroying the credibility of the security function before it has a chance to add value. The Purdue model, covered in the next section, gives you the segmentation vocabulary to explain why OT and IT patch cycles cannot be identical.
Then there is the safety dimension. In IT, a misconfigured firewall rule costs you some traffic. In OT, a misconfigured control loop can send a centrifuge to destructive speed, release toxic gas, or cause a boiler to over-pressurise. The Triton/Trisis attack, discovered in 2017 at a Middle Eastern petrochemical facility, targeted the Safety Instrumented System (SIS) directly, attempting to disable the last line of automated protection between a process excursion and a physical catastrophe. That incident permanently changed how the industry thinks about OT threats. Prior to Triton, most practitioners assumed adversaries would stop at disrupting availability. Triton demonstrated that nation-state actors were willing to target the systems specifically designed to prevent mass casualties, which means physical safety is now a first-order security concern, not a secondary consequence of availability failures. Any OT cyber security programme that does not address SIS protection in critical industries is incomplete.
The Purdue Model: Levels 0 Through 5 Explained
The Purdue Enterprise Reference Architecture, originally developed at Purdue University in the 1990s and still the dominant reference model for ICS network segmentation, divides industrial environments into six hierarchical levels. Each level has a specific function, specific device types, and specific security requirements. Understanding where a system sits in the model tells you what traffic should and should not cross that boundary.
| Level | Name | Typical Devices | Security Priority |
|---|---|---|---|
| 0 | Physical Process | Sensors, actuators, motors, valves | Physical safety; no direct network access |
| 1 | Basic Control | PLCs, RTUs, intelligent electronic devices | Process integrity; strictly limited comms |
| 2 | Supervisory Control | SCADA servers, DCS, HMI workstations | Availability; air-gapped or tightly segmented |
| 3 | Manufacturing Operations | Historians, MES, batch management systems | Data integrity; controlled bi-directional access |
| 3.5 | Industrial DMZ | Data diodes, jump servers, proxy services | Enforced unidirectional or mediated transfer |
| 4 | Business Logistics | ERP, supply chain, enterprise IT | Standard IT security controls apply |
| 5 | Enterprise Network | Corporate LAN, WAN, internet | Full IT security stack |
The critical boundary sits between Level 3 and Level 4, where OT meets IT. Most serious compromises in industrial environments cross this boundary in one direction or the other. The Colonial Pipeline ransomware incident in 2021 caused the operator to shut down pipeline operations not because the operational systems were directly compromised, but because the IT network breach created enough uncertainty about the integrity of billing and operational data that management chose to halt the pipeline as a precaution. The OT systems were largely intact, but the IT/OT boundary was not managed in a way that allowed confident separation.
The industrial DMZ at Level 3.5 is where you enforce that separation in practice. Data flows up from Level 3 to Level 4 through proxies, historians, or data diodes that allow one-way transmission. Direct connections between enterprise IT and the OT control network should not exist. If your environment has them, that is your first remediation priority.
Asset Visibility in OT: Why You Cannot Just Run a Scanner
Any OT security programme begins with asset inventory. You cannot protect what you cannot see. The challenge is that the standard IT approach, running a network discovery scan, is actively dangerous in OT environments. A Nmap scan or vulnerability scanner that sends crafted packets to probe device states can crash a PLC, disrupt a SCADA polling cycle, or send unexpected commands to field devices.
I have seen this firsthand in an assessment for a water utility client: a junior consultant ran an active network scan against what they believed was a test VLAN. The target included a live SCADA historian feeding remote terminal units at pumping stations. Three RTUs stopped responding for eleven minutes. The operational team restored them manually, but the incident delayed the entire assessment by two weeks and nearly ended the engagement.
The correct approach in OT is passive monitoring. Tools designed for industrial environments, several of which are purpose-built for ICS visibility, capture traffic from a network TAP or span port, parse industrial protocols like Modbus, DNP3, EtherNet/IP, and PROFINET, and build an asset inventory from observed communications without sending a single probe packet. This is slower and less complete than active scanning, but it preserves process safety.
Complement passive discovery with manual inventory collection during maintenance windows, vendor documentation review, and physical walk-downs. The goal is a living asset register that maps each device to its Purdue level, firmware version, communication dependencies, and known vulnerabilities. Without that register, your threat and vulnerability management programme has no foundation to work from.
Patching Reality in OT: Compensating Controls When Updates Are Not Possible
OT patching is one of the areas where IT-trained security teams most frequently misjudge operational constraints. In IT, a missing patch is a clear finding with a clear fix timeline. In OT, the same logic fails because the conditions that allow patching often cannot be scheduled on security’s terms.
Several factors make OT patching structurally different. Vendor approval requirements mean that many control system vendors void equipment warranties or support agreements if you apply patches they have not certified. Certification cycles often lag Microsoft’s release cadence by six months or more. Continuous process environments, refineries, data centres with UPS systems, manufacturing lines with zero-downtime SLAs, simply cannot reboot a controller that manages an active process. And some legacy equipment runs operating systems that are no longer receiving patches at all: Windows XP embedded and Windows 7 remain common in OT environments across critical infrastructure as of 2026.
When patching is not feasible in a reasonable timeframe, compensating controls become the operational response. These include:
- Network segmentation that limits lateral movement even if a device is compromised
- Application whitelisting on HMI workstations and engineering stations
- Disabling unnecessary services and open ports on devices that cannot be fully patched
- Monitoring for anomalous protocol behaviour that might indicate exploitation
NIST SP 800-82 Rev 3, the Guide to Operational Technology Security, provides a comprehensive framework for documenting and justifying compensating controls when the standard control cannot be applied. Regulators and auditors increasingly accept this approach as long as the compensating control is specific, documented, and paired with a remediation plan.
IEC 62443: The International Standard for ICS Security
Where NIST SP 800-82 provides guidance primarily for US critical infrastructure operators, IEC 62443 is the international standard series that addresses security for industrial automation and control systems across the entire supply chain: asset owners, system integrators, and component manufacturers each have their own set of requirements.
The standard introduces two core concepts that shape how you architect OT security: Security Levels (SL 1 through SL 4) and the division of the OT network into Zones and Conduits. A Zone is a grouping of assets with similar security requirements, broadly analogous to the Purdue levels but more flexible in application. A Conduit is any communication path between zones, and every conduit must be explicitly defined, justified, and controlled.
Security Level 1 covers protection against casual or unintentional violation. Level 2 addresses intentional violation with simple means. Level 3 covers sophisticated attacks using ICS-specific knowledge. Level 4 is reserved for state-sponsored, nation-level threats with extensive resources. Most commercial industrial environments target SL 2 as a baseline, with critical infrastructure operators aiming for SL 3 in the most sensitive zones.
Practically, IEC 62443 drives you toward documenting a Security Requirements Specification for each zone, conducting risk assessments that result in target security levels, and verifying that both your own controls and the controls built into vendor equipment meet those targets. The CISA Industrial Control Systems resources at cisa.gov/topics/industrial-control-systems provide aligned guidance and a library of ICS advisories that map directly to the vulnerabilities you need to address in your zone risk assessments.
IT/OT Convergence: Managing the New Attack Surface
The business case for connecting OT networks to enterprise IT infrastructure is real. Real-time production data flowing to ERP systems eliminates manual data entry, enables predictive maintenance, and feeds supply chain optimisation models. Cloud-based SCADA and remote access for engineering support reduce the cost of running distributed assets. These gains are not going away.
What has changed, and what your security architecture must account for, is that every connection between IT and OT introduces a potential attack path. Ransomware groups have learned that OT environments make attractive targets precisely because operators are under enormous pressure to restore availability, which increases willingness to pay. The MITRE ATT&CK for ICS framework documents the specific techniques adversaries use once they reach Level 3 or Level 2 of the Purdue model: discovery of engineering workstations, collection of ladder logic and process configuration, manipulation of set points, and impairment of process control.
Your cloud network security controls and your OT segmentation strategy must be designed together, not separately. Remote access to OT systems should flow through a purpose-built jump server in the industrial DMZ, with multi-factor authentication, session recording, and time-limited access tokens. Vendor remote access should never reach directly into Level 2. Every exception to this principle is a threat vector.
The NCSC publishes practical guidance on securing industrial control systems that is directly applicable to UK-based operators; their resources at ncsc.gov.uk include tailored guidance for sectors including energy, water, and transport.
ICS-Aware Monitoring: What Normal Looks Like in an OT Network
Standard security information and event management (SIEM) platforms are built for IT environments where event logs, authentication records, and DNS traffic are the primary data sources. OT networks generate different signals. A PLC polling a temperature sensor every 250 milliseconds produces a highly predictable traffic pattern. Any deviation from that pattern, a change in polling interval, an unexpected protocol message, a new device appearing on a process network segment, is potentially significant.
ICS-aware intrusion detection systems parse industrial protocols natively and establish baselines of normal process behaviour rather than relying solely on signature matching. When a Modbus write command appears on a segment where only read commands have ever been observed, the system flags it. When a device at Level 1 attempts to communicate directly with a system at Level 4, bypassing the expected path, the alert fires. This behavioural approach is what separates effective OT monitoring from simply forwarding OT syslogs to an IT SIEM and hoping for the best.
Building this monitoring capability requires the passive asset discovery work described earlier. You cannot baseline normal traffic until you know what devices should be communicating and what protocols they should be using. The monitoring architecture and the asset inventory programme are the same programme, built from the same network tap data.
Building an OT Security Programme That Accounts for Operational Constraints
The most effective OT security programmes share a common characteristic: they were built with operations stakeholders at the table from the beginning, not handed down from IT or security teams who learned about the process environment after the fact. Control system engineers understand the availability and safety requirements that define acceptable risk. Security teams understand the threat picture and the controls. Both perspectives are required.
A practical starting structure for an OT security programme draws from IEC 62443 and NIST SP 800-82 in combination. Start with an asset inventory built from passive discovery and manual enumeration. Map those assets to Purdue levels and IEC 62443 zones. Conduct a risk assessment against each zone using realistic threat scenarios, including insider threats, supply chain compromise, and ransomware that enters through the IT network. Define target Security Levels for each zone based on consequence analysis. Then close the gap between current state and target state through a prioritised remediation roadmap that accounts for patching constraints, maintenance windows, and the compensating controls that will cover unpatched systems in the interim. Document every compensating control with specificity: which device, which vulnerability, which mitigating measure, and what the trigger is for full remediation when a maintenance window becomes available.
Reviewing that roadmap annually and updating it after any significant change to the OT environment, a new vendor connection, a process expansion, a system upgrade, keeps the programme current. OT networks that looked static five years ago are changing rapidly as organisations add remote monitoring and cloud analytics. The programme must change with them.
OT Security: Common Questions
What is OT cyber security?
OT cyber security protects operational technology systems, including industrial control systems, SCADA platforms, PLCs, and RTUs, from cyber threats. Unlike IT security, it prioritises safety and availability over confidentiality because a compromised controller can cause physical harm, equipment damage, or production loss.
What is the Purdue model?
The Purdue model divides industrial environments into six levels, from physical process equipment at Level 0 through enterprise IT at Level 5. It defines which devices belong at each level and where network boundaries must be enforced, particularly at the industrial DMZ between Levels 3 and 4 where OT and IT networks meet.
Why is patching difficult in OT environments?
OT systems often run continuously with limited maintenance windows, require vendor approval before applying patches, and include legacy equipment running unsupported operating systems. When patching is not feasible, organisations document compensating controls such as network segmentation, application whitelisting, and anomaly monitoring as accepted mitigations.
What is IEC 62443?
IEC 62443 is the international standard series for industrial automation and control system security. It covers asset owners, system integrators, and component vendors. It introduces Security Levels 1 through 4 and the Zone and Conduit model, which defines how OT network segments are grouped and how communication between them is controlled.
