OT security is the practice of protecting operational technology — the hardware and software that monitors and controls physical processes — in environments like power grids, water treatment, manufacturing lines, pipelines, and transport. It matters because a failure here is not a data breach but a physical one: a halted production line, an unsafe process, or a disrupted essential service. That physical stake is why OT security cannot be run as a copy of IT security; the underlying assumptions invert.

The technology in question is the layer beneath the office network — industrial control systems (ICS), the supervisory control and data acquisition (SCADA) software operators watch, and the programmable logic controllers (PLCs) that open valves, spin turbines, and move actuators. These are not general-purpose computers. They are purpose-built devices engineered to keep a physical process running safely for decades, and they behave nothing like the servers an IT security program is designed around.

Why IT security assumptions invert

The clearest way to understand OT security is by what it reverses. In IT, the classic priority order is confidentiality, integrity, then availability. In OT, that flips: safety and availability come first, confidentiality last. A confidentiality control that could take a turbine offline is unacceptable, because uptime and safe operation are the mission. This single inversion reorders everything downstream — and it means a false positive that halts a plant is itself an incident, not a nuisance alert.

Three practical constraints follow from that physicality:

  • Asset lifecycles run decades. Industrial equipment is specified for twenty or thirty years of service. Systems routinely outlive their vendors' patch support, so "just upgrade to a supported version" is often not an available move.
  • Patching requires physical maintenance windows. You cannot reboot a turbine controller on Patch Tuesday. Applying an update may mean scheduling a plant shutdown weeks in advance, so unpatched-but-known vulnerabilities can persist by design rather than by neglect.
  • Active scanning can crash fragile devices. Legacy controllers were never built to tolerate the probe traffic an ordinary vulnerability scanner generates; a single aggressive scan can knock a PLC offline. This is why OT inventory leans on the passive traffic-analysis method of asset discovery — watching the network rather than probing it — as the norm.
The metric trap

A program that measures success by patch coverage will report failure forever in OT — its highest-risk assets structurally cannot be patched on a normal cadence. Measure reduction of attackable exposure — segmentation, monitoring, and controlled access around the device — instead, or the metric will fight the mission.

IT/OT convergence: the risk driver

OT environments were historically air-gapped — physically isolated from corporate IT and the internet. That isolation is eroding, and the erosion is the story. Plants now connect control networks to enterprise IT for telemetry, predictive maintenance, and remote operations. Each connection delivers real operational value, and each is also a path an attacker can travel. The bridge between the two worlds is the attack surface.

The danger is that decades of OT design assumed the network was trusted and unreachable — flat plant-floor networks, protocols without authentication, devices with no defenses of their own. None of that mattered while the environment was islanded. Convergence removes the island without removing the assumptions, so a compromise on the corporate IT side can now reach controllers that were never designed to be defended.

A layered architecture with an enterprise IT zone and an OT control zone separated by a single controlled conduit that brokers and monitors all crossing traffic
Figure 1 — IT and OT separated by a single controlled conduit: every crossing is brokered and monitored, never a flat link.

Who attacks infrastructure

Two threat actors dominate the OT model. The first is nation-state actors with disruption or pre-positioning objectives, for whom interrupting an essential service is strategic leverage rather than a payday. The second, increasingly common, is ransomware crews: downtime pressure is their business model, and nowhere is downtime more unbearable than in critical infrastructure, which makes an operator that cannot run its process a high-value target. Ransomware often halts production without ever touching a controller — the operator shuts the line down as a precaution once the IT side is compromised.

10 daysglobal median attacker dwell time (Mandiant M-Trends 2024)
38%of intrusions began with an exploit — the top initial vector (Mandiant M-Trends 2024)
~1/3of breaches involved ransomware or extortion (Verizon DBIR 2024)

Those figures — from Mandiant's M-Trends 2024 and Verizon's 2024 DBIR — describe the IT intrusions that become OT incidents once the two networks are bridged.

Program priorities

OT security defends assets it usually cannot patch, so it invests in controls around the device rather than fixes inside it. Four priorities carry most of the weight.

Segment IT from OT with controlled conduits

The reference architecture is the Purdue model, which organizes an industrial environment into layered zones — from enterprise IT down to plant-floor controllers — and permits traffic between them only through defined, monitored conduits. IT and OT never share a flat network; every crossing is brokered and inspected. This is the single most important OT control, precisely because patching often is not an option.

Build a passive asset inventory and monitor continuously

You cannot protect what you cannot see, and you cannot safely scan for it. Passive discovery and continuous monitoring build the inventory and watch for the exploitation you cannot patch away — without the probe traffic fragile controllers cannot tolerate.

Harden remote access

The vendor VPN is the classic way in — a maintenance channel opened for a supplier, then left standing and under-monitored. Remote access into OT should be brokered, time-boxed, strongly authenticated, and logged — the highest-risk conduit, not a convenience.

Plan OT-aware incident response — safety first

An IR playbook written for IT can make an OT incident worse: isolating a controller mid-process, or forcing a reboot, can itself be a safety event. OT incident response is built with process and safety engineers in the room, where the first question is whether a containment action is safe to take — not just whether it stops the attacker.

The regulatory frame. Critical-infrastructure protection regimes exist across jurisdictions and are actively evolving — in India, the National Critical Information Infrastructure Protection Centre (NCIIPC) oversees designated critical sectors, while other jurisdictions apply their own sectoral rules for energy, water, and transport. Confirm every named authority, control, and obligation against the current source text for the sectors and countries you actually operate in.

Common confusions

"OT security is just IT security applied to the factory." No — the priority order inverts. Safety and availability outrank confidentiality, so controls that are routine in IT (aggressive scanning, forced patching, mid-incident isolation) can be unacceptable in OT.

"Our OT network is air-gapped, so it is safe." True air gaps are rare and porous. Telemetry links, maintenance laptops, and vendor VPNs cross them, and IT/OT convergence is steadily removing the gap while the plant-floor assumptions that depended on it remain.

"If the ransomware never reached a controller, the OT wasn't affected." Production still stops. Operators routinely shut a process down as a precaution when the connected IT environment is compromised, so an IT-only intrusion can still halt it.

Frequently asked questions

What is the difference between OT security and IT security?

They protect different things with inverted priorities. IT security protects data and generally ranks confidentiality first; OT security protects physical processes and ranks safety and availability first, with confidentiality last. That inversion changes which controls are acceptable — active scanning, forced patching, and mid-incident isolation are routine in IT but can be dangerous in OT.

Why can't operational technology just be patched like normal systems?

Because the assets are long-lived, safety-critical, and often unsupported. Industrial controllers are built for decades of service, frequently outlive their vendors' patch support, and can only be updated during scheduled physical maintenance windows — you cannot reboot a turbine controller on demand. The program compensates with segmentation, passive monitoring, and access control around the device rather than patching it.

Why is passive discovery the norm in OT environments?

Because active scanning can crash fragile devices. Legacy controllers were never designed to tolerate the probe traffic an ordinary scanner generates, and a single aggressive scan can knock a device offline — a production or safety event. Passive traffic analysis infers what assets exist from the conversations they already have on the network, without touching them.

Who attacks critical infrastructure, and why?

Primarily nation-state actors seeking disruption or long-term pre-positioning, for whom interrupting an essential service is strategic leverage, and ransomware crews, for whom the unbearable cost of downtime makes infrastructure operators high-value targets. Ransomware frequently halts production without ever reaching a controller, because operators shut the process down as a precaution.

Related reading

OT and manufacturing is one vertical in the broader security programs by industry map, which explains why each sector's asset mix, adversary, regulator, and risk tolerance reshape the same underlying program. For the discovery technique OT depends on, see the passive method in what is asset discovery, and for the adversaries behind infrastructure attacks, what is a threat actor.

CybersecurityAdvanced