What Is OT Security? Operational Technology Defense

When a vulnerability scanner sweeps a corporate laptop, the worst case is a reboot and a help-desk ticket. When the same scan hits a programmable logic controller running a turbine, the worst case is the turbine. OT devices were built to do one thing reliably for twenty years, not to absorb a probe they never expected. An aggressive port scan has knocked controllers offline. A routine patch reboot has stopped a production line. The reflexes that keep IT safe can break OT, and that gap is the whole reason OT security exists as its own discipline.

Operational technology (OT) security is the practice of protecting the hardware and software that monitor and control physical processes: the controllers, sensors, and actuators that run a factory floor, a power grid, a water plant, or a pipeline. It is not IT security pointed at industrial gear. The assets are different, the priorities are inverted, and a failure does not leak data, it spills, overheats, or stops. This guide covers what OT is, why its security model differs from IT, the Purdue model that structures it, the standards that govern it, the threats that have actually hit it, and the controls that work without breaking the process.

What is operational technology (OT) security?

Operational technology is the set of systems that interact with the physical world. Where information technology moves and stores data, OT measures a temperature, opens a valve, spins a motor, or trips a breaker. The category covers industrial control systems (ICS), supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS), programmable logic controllers (PLCs), remote terminal units (RTUs), and the human-machine interfaces (HMIs) operators use to watch and adjust them.

OT security is the protection of those systems and the physical processes they govern. Its goal is to keep the process running safely and predictably while keeping attackers out, and when those two aims conflict, safety and availability win. That ordering is the single most important thing to understand about the field. In IT, the classic priority is confidentiality, then integrity, then availability. In OT it inverts: availability and safety come first, integrity second, confidentiality last. A leaked spreadsheet is a bad day. A safety system that fails to trip is a catastrophe.

The stakes are physical and they are public. OT runs critical infrastructure: electricity, water, oil and gas, transportation, and manufacturing. An incident does not end at a data breach notification. It can mean a blackout, contaminated water, a halted production line, or, at the extreme, injury and loss of life. That is why OT security treats safety and uptime as the controlling constraints rather than afterthoughts.

Why OT security is not IT security

The two disciplines share words and almost nothing else in their constraints. The differences are not stylistic, they decide which controls are even usable.

Priorities are inverted. IT optimizes for confidentiality. OT optimizes for availability and human safety. A control that improves IT security by adding latency, forcing reboots, or blocking traffic during inspection can be unacceptable in OT, where a few hundred milliseconds of delay or an unplanned restart has physical consequences.

Lifecycles are measured in decades. A corporate laptop is replaced every three or four years. A PLC or DCS can run for fifteen to twenty-five. That means OT environments are full of equipment that predates modern security entirely: systems running unsupported operating systems, protocols with no authentication, and firmware that cannot be patched without a scheduled plant outage that may come once a year, if at all.

Patching is a scheduling problem, not a technical one. In IT, you patch on Tuesday. In OT, patching a controller may require taking a live process offline, which has a cost measured in lost production and, sometimes, in safety risk. Many OT devices also lose vendor warranty or certification if modified. So the IT answer, patch fast, is often simply not available, and compensating controls have to carry the load instead.

The protocols assume a trusted network. Modbus, DNP3, PROFINET, and EtherNet/IP were designed for isolated, physically secured networks where every device was assumed friendly. Most carry no authentication and no encryption by default. A command to open a valve looks identical whether it comes from the engineering workstation or an attacker who reached the same network segment.

Scanning and probing can break things. Standard IT security tooling, active vulnerability scanners, aggressive discovery, automated agents, can crash or destabilize fragile OT devices that were never tested against that traffic. This is why OT monitoring leans heavily on passive, read-only techniques rather than the active scanning that IT takes for granted.

The Purdue model: how OT networks are structured

The Purdue Enterprise Reference Architecture, usually just the Purdue model, is the layered blueprint most OT environments are organized around. It divides the environment into levels by function and uses the boundaries between them to control where traffic can flow. NIST SP 800-82 Revision 3, the primary US guidance on OT security, builds its architecture chapter around this segmentation.

The levels run from the physical process up to the enterprise:

• Level 0, the physical process. Sensors and actuators: the valves, pumps, motors, and instruments that do and measure the actual work.
• Level 1, basic control. PLCs and RTUs that read sensors and drive actuators in real time.
• Level 2, area supervisory control. HMIs and SCADA systems where operators monitor and adjust a process area.
• Level 3, site operations. Production management, historians, and engineering workstations that coordinate a whole site.
• Levels 4 and 5, the enterprise. Business IT: ERP, email, the corporate network and the internet.

Between Level 3 and Level 4 sits the most important boundary in the model: the industrial demilitarized zone (IDMZ). It is a buffer network that brokers all traffic between the plant and the enterprise so that no IT system talks directly to a controller. NIST SP 800-82 Rev. 3 is explicit that firewall rules should prevent Level 4 devices from communicating directly with Level 2, 1, or 0 devices. The deeper a level, the more it is protected, because the deeper you go, the closer you are to the physical process and the harder the consequences of a compromise.

The value of the model for a defender is that it turns "secure the plant" into a set of enforceable boundaries. Each level becomes a place to segment, monitor, and choke off lateral movement, which is exactly how a real intrusion is contained before it reaches Level 0.

The standards: IEC 62443 and NIST SP 800-82

Two references anchor the field, and they complement rather than compete.

ISA/IEC 62443 is the international standard series for industrial automation and control system security. Its central construct is zones and conduits. A zone is a grouping of assets that share the same security requirements, for example a single process cell. A conduit is the controlled communication path between zones, and it must be secured to the level of the most critical zone it touches. The series also defines security levels (SL 1 through SL 4) that express how strong a zone's protection must be against increasingly capable attackers, which lets an organization match defense to risk rather than applying one blanket posture everywhere. The zones-and-conduits idea is the formalization of the segmentation that the Purdue model lays out structurally.

NIST SP 800-82 Revision 3, "Guide to Operational Technology (OT) Security," published in September 2023, is the US government's reference for securing ICS and other OT. It is descriptive rather than prescriptive: it explains the architecture, the threat landscape, and the control families to consider, and it maps them onto the NIST Cybersecurity Framework and SP 800-53 controls, tailored for environments where availability and safety dominate. Revision 3 broadened the original ICS scope to OT generally and updated the guidance for IT/OT convergence.

In practice the two are used together. IEC 62443 supplies the zone-and-conduit architecture and the security-level model; NIST SP 800-82 supplies the program structure and the control mapping. A mature OT program leans on both, alongside defense in depth as the organizing principle that no single control is trusted to hold alone.

The threats: what has actually hit OT

OT threats are not hypothetical, and the notable ones share a pattern: they cross from IT into OT, then act on the physical layer.

Stuxnet (discovered 2010) is the reference case. It targeted Siemens PLCs controlling uranium-enrichment centrifuges in Iran, spread through removable media and Windows zero-days, and altered centrifuge speeds while reporting normal readings back to operators. It proved that code can cause physical destruction.

Triton, also called Trisis (2017), targeted the safety instrumented systems (SIS) at a petrochemical plant, specifically Schneider Electric Triconex safety controllers. SIS exist to trip a process into a safe state when something goes dangerously wrong. Triton tried to disable that last line of defense, which is what made it uniquely dangerous: it attacked the system whose entire job is to prevent a catastrophe. The plant tripped to a safe state and the attack was caught because of a bug in the malware, not because a control stopped it.

Industroyer, also called CrashOverride (2016), was used against the Ukrainian power grid and spoke grid protocols (including IEC 61850 and IEC 60870-5-104) natively to open breakers and cause an outage. Its successor, Industroyer2, reappeared in 2022.

Beyond the marquee cases, the most common OT incidents today are more mundane and more frequent: ransomware that spreads from the IT network into OT, or that forces a precautionary OT shutdown even when it never touches a controller, as in the 2021 Colonial Pipeline incident, where the operator halted the pipeline because the billing IT systems were compromised. The lesson across all of them is the same: the path into OT almost always runs through IT first, which is why the boundary between them is the line that matters most.

The controls: securing OT without breaking it

OT defense is built around the constraints above. The controls that work respect the priority on availability and the limits on patching and scanning.

Asset inventory first. You cannot protect what you cannot see, and most OT environments have never had a complete inventory. The first control is a continuously maintained list of every device, its firmware, and how it communicates, built where possible through passive discovery so the discovery itself does not destabilize anything.

Network segmentation and the IDMZ. Enforce the Purdue boundaries. Put a hardened IDMZ between IT and OT, segment the OT network into zones, and write conduit rules so a compromise in one cell cannot reach another or descend toward Level 0. Segmentation is the single highest-leverage control in OT because it directly limits how far an intrusion can travel. It is a specialized application of network security adapted to fragile, flat industrial networks.

Passive monitoring. Because active scanning can break OT devices, detection relies on watching network traffic read-only: baselining normal protocol behavior and alerting on the abnormal, an unexpected command to a PLC, a new device on a segment, an engineering connection at 3 a.m. This is where OT-aware intrusion detection lives.

Strict access control. Tightly govern who and what can reach OT, especially remote vendor access, which is a recurring entry point. Enforce multi-factor authentication, just-in-time access, and jump hosts in the IDMZ so no one connects straight to a controller.

Compensating controls for what cannot be patched. When a device cannot be patched, wrap it: isolate it in its own zone, restrict its conduits to the minimum, and monitor it closely. The unpatchable asset is contained rather than fixed.

An OT-specific incident response plan. A generic IT incident response plan assumes you can isolate or reimage a host on demand. In OT you may not be able to, because pulling a controller offline can be more dangerous than the intrusion. OT incident response has to be written with the process engineers, with safety as the first constraint, and rehearsed before the day it is needed.

How OT security fits exposure management

OT does not sit outside the broader security program; it is one of the hardest parts of it. Exposure management asks what an attacker can reach and what they would hit first, and OT changes the answer in two ways. The reachable set now includes assets that cannot be scanned or patched on demand, so the program has to reason about exposure it cannot remediate the usual way. And the impact axis is no longer just data, it is physical, which pushes OT assets to the top of any honest prioritization.

The practical link is the IT/OT boundary. Because nearly every OT incident arrives through IT, the exposure that matters most is the path between the two: the flat segment, the dual-homed engineering workstation, the forgotten remote-access tool a vendor left behind. An exposure-management program that maps and watches that boundary is doing the highest-value OT security work there is, before an attacker ever reaches the plant floor.

Frequently Asked Questions

What is OT security in simple terms?

OT security is the protection of the systems that run physical processes, the controllers, sensors, and actuators behind factories, power grids, water plants, and pipelines. Its goal is to keep those processes running safely and reliably while keeping attackers out. Unlike IT security, it treats safety and availability as the top priority, above confidentiality.

What is the difference between IT and OT security?

IT security prioritizes confidentiality and patches frequently on short-lived hardware. OT security prioritizes safety and availability on equipment that runs for fifteen to twenty-five years, often cannot be patched without a plant outage, and uses protocols with no built-in authentication. Controls that are routine in IT, like active scanning and forced reboots, can physically damage or destabilize OT devices.

What is the Purdue model in OT security?

The Purdue model is a layered reference architecture that divides an OT environment into levels, from Level 0 (the physical sensors and actuators) up through controllers, supervisory systems, and site operations to the enterprise IT at Levels 4 and 5. The boundaries between levels are where traffic is segmented and controlled, and an industrial DMZ between the plant and enterprise IT keeps business systems from talking directly to controllers.

What standards apply to OT security?

The two main references are ISA/IEC 62443, the international standard that defines zones and conduits and security levels for industrial control systems, and NIST SP 800-82 Revision 3, the US guide to OT security published in 2023. They are complementary: IEC 62443 supplies the segmentation architecture, and NIST SP 800-82 supplies the program structure and control mapping.

What are examples of real OT cyberattacks?

Stuxnet (2010) physically damaged centrifuges by manipulating Siemens PLCs. Triton/Trisis (2017) targeted Schneider Triconex safety systems at a petrochemical plant, attacking the very controls meant to prevent disaster. Industroyer (2016) and Industroyer2 (2022) caused power outages in Ukraine by speaking grid protocols directly. Many incidents today are ransomware that spreads from IT into OT or forces a precautionary shutdown.

Why can't you just patch OT systems like IT systems?

Patching an OT device often means taking a live physical process offline, which carries production and safety costs and may only be possible during a rare scheduled outage. Many devices also run unsupported software or lose vendor certification if modified. So OT security relies on compensating controls, isolating, segmenting, and closely monitoring devices that cannot be patched, rather than patching on a fast cycle.

The bottom line

OT security protects the systems that run the physical world, and it is a separate discipline because its constraints invert IT's. Safety and availability come before confidentiality, hardware lives for decades, patching is tied to plant outages, the protocols assume a trusted network, and scanning can break the very devices it is meant to protect. Those facts decide which controls are usable.

The work is structured by the Purdue model and the IEC 62443 zones-and-conduits architecture, governed by NIST SP 800-82, and driven by a clear threat record from Stuxnet to Triton to grid attacks that all crossed from IT into OT before acting physically. The controls that hold are the ones that respect the constraints: a real asset inventory, hard segmentation with an IDMZ, passive monitoring, strict remote access, compensating controls for the unpatchable, and an incident response plan written with safety first. For an exposure-management program, the IT/OT boundary is the highest-value thing to map and watch, because that is the road every serious OT attacker has to travel.