What is OT Security? And Why You Can't Just Run It Like IT

December 2015. Western Ukraine. Three power distribution companies lost control of their grid for several hours.

The attackers didn't go after email. They didn't steal customer data. They reached the controllers that physically open and close circuit breakers, and they flipped them. Around 230,000 people sat in the dark while operators watched their own substations get clicked off remotely, unable to stop it.

SANS published a detailed analysis of that incident in 2016. Every OT security practitioner I know read it. The lesson stuck because it was unfamiliar to most of the security industry at the time. You could break things you could touch.

That's the world OT security operates in.

Quick Answer: OT security protects the systems that run physical processes — plants, pipelines, power grids, water treatment, hospitals. It's not IT security in a hard hat. The priorities flip: safety and uptime come first, confidentiality comes last. Equipment runs for decades. Patches are rare. The IEC 62443 standard and NIST SP 800-82 Revision 3 (2023) define how it's done.

What we actually mean by OT

Operational technology is the family of systems that interact with the physical world. The acronyms pile up fast. ICS for industrial control systems. SCADA for the bigger distributed ones — pipelines, grids. DCS for plant-wide control. PLCs, the small ruggedized computers doing the actual work on the floor. Safety instrumented systems, the last line of defense before something explodes or overflows.

OT security is the discipline of keeping all of that running safely while attackers get more interested in it every year. It overlaps with, but is distinct from, connected-device defense — and if your environment blends the two, our work on IoT security and this primer on Internet of Things security are useful companions to this guide.

Two reference documents matter more than the rest. The IEC 62443 series, updated through 2024, is the international standard. NIST SP 800-82 Revision 3 (2023) is the U.S. government's detailed guide. If you're building a program from scratch, those two are where you start — anchored to recognized NIST standards and ISO standards for governance.

Here's the bit most IT people miss. In IT, the classic security triad puts confidentiality first. Data leaks are the nightmare. In OT, that order completely inverts. A leaked spreadsheet is bad. A turbine running outside its safe operating envelope can kill people. Availability wins. Safety wins. Confidentiality comes last.

Why OT security isn't an academic question anymore

The attackers showed up

Colonial Pipeline, May 2021. Ransomware hit the IT network. Colonial shut down the pipeline itself as a precaution. Fuel shortages rippled across the U.S. East Coast for days.

The technical detail people missed: the OT systems weren't directly compromised. The IT side was. But the company couldn't be confident the infection hadn't spread, so they pulled the plug on operations to be safe. That decision exposed how thin the wall between IT and OT had become — and why cyber resilience now has to span both.

The Dragos Year in Review reports keep tracking the same trend year after year. More groups developing capabilities aimed specifically at industrial environments. Some state-aligned. Some criminal. The targeting isn't theoretical, and it's reshaping how the wider cybersecurity field thinks about physical consequence.

The walls came down

For a long time, OT security relied on isolation. The control network was air-gapped. Or close enough. Then Industry 4.0 happened. Plants got connected to enterprise networks for analytics. To the cloud for predictive maintenance. To vendor support portals for remote diagnostics.

Most of those connections happened for good business reasons. Few of them were designed with security as a first thought. The air gap is now a polite fiction in most environments, and the security model needs to catch up to that reality — which is exactly why a credible zero trust strategy matters as much in OT as in IT.

What's genuinely different about defending OT

Let me walk through this concretely, because the differences from IT aren't subtle.

Equipment lives forever. A server in a corporate data center has a refresh cycle of maybe five years. A PLC controlling a refinery process? Could be twenty years in service. Sometimes more. The vendor may not exist anymore. Patches? Often unavailable. Sometimes the firmware hasn't been touched since 2007.

Patching isn't routine. In IT, you patch Tuesday night. Done. In OT, patching a controller in a continuous process plant requires months of planning, coordination with the vendor, validation testing, and a scheduled production outage that costs real money. "Apply critical patches promptly" means something different here.

The protocols are weird. Modbus. DNP3. Profinet. OPC UA. Designed decades ago, mostly for reliability, often with no authentication built in. Traditional IT security tools can't parse them. Which is why companies like Dragos, Claroty, and Nozomi built an entire product category for OT-specific monitoring — capability that pairs naturally with a protocol-aware security operations center.

Consequences are physical. This is the one IT folks struggle with the most. A bad patch in IT causes downtime. A bad patch in OT can release toxic chemicals into the environment, damage equipment worth millions, or hurt people. That's not hypothetical. It's why every change in OT goes through a process that would feel paranoid to an IT team — and why tested business continuity management is non-negotiable.

What good OT security looks like

Segment the network using IEC 62443 zones and conduits. The standard groups assets into zones with shared security requirements and defines controlled communication paths (conduits) between them. The Purdue Reference Model is the conceptual layer underneath. Done well, this means an incident in the corporate IT environment can't reach the safety instrumented systems on the production floor.

Inventory what's actually on your network. Most plants don't really know. Passive discovery tools built for OT protocols can map an environment without sending the kind of traffic that crashes old controllers. CIS Controls v8 makes asset inventory Controls 1 and 2 because everything else depends on it. In OT this work is harder, takes longer, and matters more.

Build OT-specific incident response runbooks. Your IT runbooks don't translate. Isolating a compromised laptop means pulling its network cable. Isolating a compromised PLC might mean a controlled production shutdown coordinated with safety engineers. NIST SP 800-82 Rev. 3 (2023) has OT-specific guidance worth borrowing from, and pairing it with a real-time response capability turns the runbook into action.

Control vendor remote access ruthlessly. Permanent VPN tunnels into vendor networks are one of the most exploited paths in documented OT incidents. Replace them with jump servers, multi-factor authentication, recorded sessions, and time-limited access windows. Strong identity and access management is the backbone here. The convenience cost is real. The risk reduction is worth it.

Train both sides of the IT/OT gap. Security engineers need to understand process safety. Process engineers need to understand attacker behavior. The IEC 62443-2-4 module on security program requirements covers competency explicitly, and aligning it with your GRC function keeps accountability clear. Companies that invest in this end up with one team. Companies that don't end up with two teams arguing at each other.

Where I see OT programs fail

The most common pattern, by far, is treating OT as a flavor of IT. The IT team rolls out network scanning. PLCs crash. They deploy endpoint agents. Controllers run out of resources. They schedule automatic patching. Production stops at 2 AM. I've seen this exact sequence play out three times in the past five years at clients I've worked with. The intent is always good. The execution causes the incident.

The second pattern is what I call the perimeter delusion. Heavy investment in a firewall between IT and OT, then the assumption that everything behind it is fine. Real incident data tells a different story. Firewalls get bypassed through engineering laptops carrying USB sticks. Through vendor remote access that was supposed to be temporary three years ago. Through cloud connections set up for a pilot project that nobody documented. Defense-in-depth inside the OT network isn't optional anymore — a lesson the wider security operations center discipline learned the hard way.

Third pattern, and this one's harder to fix. Nobody owns OT security. The CISO assumes the plant manager has it. The plant manager assumes the CISO has it. Operations assumes IT has it. So investment falls through the gap. The Saudi NCA's OT Cybersecurity Controls (OTCC-1, 2022) and similar guidance from regulators in other regions have been getting more explicit about this for a reason. Somebody has to be named.

What's coming over the next two years

Regulators are getting noisier. The EU's NIS2 Directive, with national transposition through 2024, dramatically expands cybersecurity obligations across operators of essential services. A lot of OT scope sits inside it. The U.S. continues to add sector-specific rules through CISA, TSA, and EPA. Saudi Arabia's NCA published OT-specific controls and is moving into enforcement.

OT-aware threat detection is no longer cutting edge. It's becoming a baseline expectation for critical infrastructure. If you're operating a regulated facility without protocol-aware monitoring, that's a gap auditors will start flagging.

On AI in OT security, I'd offer caution. The marketing is loud. The practitioner consensus is more measured. Anomaly detection sounds useful, and sometimes it is. But in OT contexts, false positives can trigger unnecessary process responses that have safety implications. The deployments I've seen work well use AI to flag things for human review. The deployments that struggle gave it authority to act autonomously. That distinction matters.

So what do you do this week

OT security isn't IT security with safety boots on. The systems are different. The priorities are different. The consequences are different. Pretending otherwise is how well-intentioned security teams cause the incidents they're trying to prevent.

Try this. Pick one production-critical control system in your environment. Just one. Then answer three questions on paper. Who owns its cybersecurity? What's currently connected to it? How would you know if something compromised it? If any of those answers is fuzzy, that's where your program actually starts.

FAQ

What's the difference between OT, ICS, and SCADA?

OT is the umbrella term covering all operational technology. ICS sits inside OT and refers to industrial control systems, which includes SCADA, DCS, and PLCs. SCADA itself is one type of ICS, typically used for assets spread across geography — pipelines, power transmission, water distribution. The terms get used loosely in conversation. The distinctions matter when you're writing procurement specs or reading standards.

Can NIST CSF be used for OT environments?

Yes, with adaptation. NIST CSF 2.0 (2024) was built to be sector-agnostic and works fine as an organizing framework. For the technical depth OT engineers need, layer NIST SP 800-82 Revision 3 or IEC 62443 underneath it. CSF gives you the language for executive reporting. The OT-specific standards give you the controls detail.

How does ransomware specifically affect OT?

Most documented OT impacts from ransomware came indirectly. The IT environment got hit, operators shut down OT as a precaution because they couldn't be sure of containment. There are ransomware variants written for industrial environments specifically, but they're less common than the IT-spillover pattern. Strong segmentation between IT and OT reduces the chance an IT incident forces an OT shutdown.

Should IT and OT security be separate teams?

The model I see working best is integrated governance with specialized execution. One CISO function with overall accountability. A dedicated OT security team with specialized expertise inside it. Pure separation creates coordination failures during incidents. Pure integration ignores the genuine technical differences. The middle path is messier but tends to deliver better outcomes.