OT Security

Overview

What operational technology security is, why it exists as a distinct field, and what makes it fundamentally different from securing traditional IT systems.

Where you will see it: Relevant in industrial environments, critical infrastructure, and wherever IT networks connect to operational technology systems.

What it is

Operational technology security covers the protection of hardware and software that monitors and controls physical equipment, processes, and events. This includes industrial control systems, SCADA systems, PLCs, RTUs, and the networks that connect them. The field exists because these systems have unique architectures, protocols, constraints, and threat models that traditional IT security does not address.

Key points

OT systems control physical processes in real time, where a security failure can have immediate physical consequences.
Most OT environments run legacy hardware and software that cannot be patched or updated on a normal security cycle.
Safety and availability are the primary operational priorities, which fundamentally shapes every security decision.
IT security practices cannot be applied directly to OT without understanding how industrial protocols, architectures, and constraints differ.

How it works in broad strokes

Understand that OT environments are defined by their physical process. The security model follows from what the system controls and what failure would mean.
Map the environment using the Purdue Model or IEC 62443 zone and conduit approach to understand what is connected to what and where boundaries should exist.
Identify which systems are safety-critical versus production-critical versus monitoring-only, because risk and acceptable controls differ for each.
Apply network segmentation to isolate OT from IT, restrict data flows to what is necessary, and ensure that a compromise in IT cannot directly reach control systems.
Build visibility before trying to harden. Passive monitoring of OT networks is often safer than active scanning, which can crash legacy devices.

Concrete example

A power utility connects its substation control systems to a corporate IT network for remote monitoring and billing data. Without segmentation, an attacker who compromises a corporate email server could potentially pivot to the operational network and interact with equipment that controls the grid. OT security addresses exactly this class of risk, defining where the boundary sits, what can cross it, and how to detect when something unexpected happens.

Why it matters

OT systems run the infrastructure society depends on. An attack that corrupts a financial database is serious. An attack that shuts down a water treatment plant, trips a power grid, or causes a chemical plant to behave unexpectedly is a different category of problem entirely. As OT systems became networked and connected to IT environments, they inherited IT-world exposure without the decades of security hardening that IT systems have received.

Security angle

In OT, availability and safety come before confidentiality. A security control that risks a system crash or an unsafe physical state is usually the wrong control.
Patching is often impossible or severely delayed in OT. Compensating controls like network segmentation, application whitelisting, and monitoring become the primary defenses.
Threat actors targeting OT environments include nation-state actors with long dwell times and specific physical outcomes as objectives, not just data theft.

Common pitfalls

Applying IT security tools directly to OT networks without testing. Active vulnerability scanners have crashed PLCs and caused unplanned outages.
Assuming air gaps that no longer exist. Most modern OT environments have some form of IT connectivity, often through maintenance laptops, vendor remote access, or historian servers.
Focusing only on network security while ignoring physical access, which is often the most realistic attack path into an OT environment.

DEEP DIVE

▾

Where OT security comes from

Industrial control systems have existed since long before cybersecurity was a concept. PLCs were introduced in the late 1960s to replace relay logic in manufacturing. SCADA systems grew to manage geographically distributed infrastructure like pipelines and power grids. For decades, these systems operated in isolation, physically separate from corporate networks and the internet, speaking proprietary protocols that only specialists understood.

That isolation created a false sense of security known as security through obscurity. The assumption was that if outsiders could not reach a system and did not understand its protocols, it was safe. This assumption started breaking down as organizations connected OT to IT for legitimate business reasons: remote diagnostics, real-time production data, vendor support connections, and integration with enterprise systems.

The 2010 discovery of Stuxnet changed how the security community understood OT risk. Stuxnet was sophisticated malware that specifically targeted Siemens PLCs used in uranium enrichment centrifuges. It demonstrated that industrial control systems could be targeted with precision, that attackers could understand OT protocols well enough to manipulate physical processes, and that even air-gapped systems were not immune. After Stuxnet, OT security became a serious discipline rather than a niche concern.

The fundamental tension: safety vs. security

In IT, the CIA triad (confidentiality, integrity, availability) is a useful framework for thinking about security priorities. In OT, the order is almost inverted and a fourth concern is added: safety. The primary obligation of an industrial control system is to control a physical process reliably and safely. Security measures that could disrupt that obligation are not acceptable, regardless of how effective they might be from a pure cybersecurity standpoint.

This creates real constraints. You cannot patch a PLC running a continuous chemical process during business hours. You cannot install an endpoint agent on firmware-based equipment the vendor does not support. You cannot respond to an intrusion by taking a critical system offline without understanding whether doing so causes a worse physical outcome than the intrusion itself. Every security decision must account for the operational reality of the system it is protecting.

This does not mean OT systems cannot be secured. It means security must be designed into the architecture rather than bolted on at the endpoint level. Network segmentation, unidirectional gateways, passive monitoring, and access control at the perimeter achieve security outcomes without putting hands on the devices themselves. The engineering challenge is understanding the system well enough to design controls that protect without interfering.

Why legacy systems are the hardest problem

OT environments are built to run for decades. A PLC installed in a water treatment plant in 2002 may still be in production today, running firmware that has not been updated since installation. The vendor may no longer exist. The engineering team that designed the system may have retired. The documentation may be incomplete. And the organization cannot simply replace the equipment because doing so would require a full plant shutdown and re-engineering project that costs millions.

This longevity creates a security challenge with no clean solution. The system is running an operating system with known, publicly documented vulnerabilities. It speaks protocols that have no authentication. It was designed in an era where connecting it to a network was not part of the threat model. And yet it cannot be patched, cannot be replaced, and must continue to operate reliably.

The practical response is to focus security at the network and access level rather than at the device level. If a vulnerable PLC can only be reached by authorized engineering workstations on a segregated network, its internal vulnerabilities become much harder to exploit. This approach, compensating controls around unpatchable assets, is the dominant pattern in mature OT security programs and is explicitly addressed in standards like IEC 62443.

The IT/OT convergence problem

Modern OT environments are not truly isolated. Business pressure has driven integration of OT and IT for legitimate reasons: collecting production data for analytics, enabling vendor remote support, integrating with ERP systems, and providing management dashboards. Each integration is justified individually, but collectively they create a network topology where the separation between corporate IT and operational systems is less clear than it appears on paper.

The typical risk path is indirect. An attacker compromises a corporate endpoint through a phishing email. From there they pivot to systems that have access to the OT environment: historian servers that aggregate production data, engineering workstations with remote access software, or vendor VPN connections with broad network access. None of these systems are the actual target, but each is a stepping stone toward the control layer.

Addressing this requires understanding actual connectivity, not assumed connectivity. Organizations often discover their OT network is more connected than documented, through maintenance laptops that connect to both networks, wireless access points installed for convenience, or industrial routers with default configurations. Accurate asset discovery and network mapping are the starting point for any serious OT security program.

Who attacks OT and why

The threat landscape for OT differs significantly from IT. Ransomware operators have discovered that encrypting IT systems adjacent to OT environments is often enough to cause operational shutdowns, even without directly touching control systems. The Colonial Pipeline incident in 2021 demonstrated this clearly. The operators shut down the pipeline preemptively because they could not confirm their OT systems were unaffected.

Nation-state actors represent the more sophisticated end of the threat spectrum. Groups have demonstrated the capability to compromise OT environments, understand industrial protocols, and position themselves to cause physical effects. Attacks on Ukrainian power infrastructure in 2015 and 2016 showed that these capabilities are not theoretical. They have been used to cause real grid outages affecting hundreds of thousands of people.

The implication for defenders is that the threat model must include actors with patience, resources, and specific physical objectives. Long dwell times, living off the land with legitimate tools, and careful reconnaissance before action are characteristics of advanced OT-targeting campaigns. Detection strategies must account for subtle anomalies in process behavior and network communication patterns, not just obvious malware signatures.