OT Security 101: Protecting SCADA and Industrial Control Systems

IT security protects laptops, servers, and databases. OT security protects power grids, water treatment plants, pipelines, and factory floors. Those sound like the same problem wearing a different hat. They are not — and treating them as the same problem is how OT security programmes fail.

The Constraint That Changes Everything

Confidentiality, integrity, and availability are the three pillars everyone learns in security fundamentals, and in IT security, confidentiality is usually treated as the priority — protect the data, and if a system needs to go offline to patch a vulnerability, it goes offline. Downtime is a cost, but it’s a manageable one.

In OT, that priority order inverts. Availability comes first, by a wide margin. A production line stopping mid-shift, a water treatment plant losing control visibility, or a power distribution system going dark aren’t inconveniences — they’re safety incidents. This single constraint explains almost every way OT security methodology diverges from IT:

• You cannot patch a PLC the way you patch a server. Many industrial controllers run firmware that’s a decade or more old, with no vendor patch path, because replacing them means replacing physical hardware on a production line.
• You cannot install endpoint detection and response on a SCADA system. These devices often can’t run modern agents at all, and even where they technically could, IT-style active scanning has been known to crash OT equipment that was never tested against that kind of network traffic.
• You cannot take a production line offline for a routine security update the way you’d patch a web server during a maintenance window. The maintenance window might be measured in months, not hours.
• Air gaps, where they still exist on paper, mostly don’t exist in practice. IT and OT networks are connected in most enterprises today — for remote vendor access, for production data flowing into business systems, for the convenience that drove the connection in the first place. The result is that a compromise starting in the business network has a real path to the factory floor.

What OT Security Actually Looks Like in Practice

Because the constraints rule out most of the IT security toolkit, OT security methodology is built around working within an environment you can’t touch, rather than instrumenting it directly.

Asset discovery, done passively. Most OT environments have never had a complete inventory of every device, protocol, and connection on the network — many organisations are surprised by what passive discovery finds. It’s done by listening to network traffic rather than actively probing devices, so it can be deployed without any risk of disrupting operational systems.

Network segmentation along the Purdue model. The Purdue Enterprise Reference Architecture defines zones from the physical process layer up through enterprise IT, with monitored boundaries (DMZs) between them. Properly implemented, it means a compromise on the corporate network doesn’t have a direct path to a programmable logic controller.

Passive monitoring for anomaly detection, tuned specifically for industrial protocols — Modbus, DNP3, IEC 61850 — rather than detection rules adapted from IT traffic patterns, which mostly don’t transfer.

Remote access hardening. Always-on VPNs for vendor access are a common, underappreciated risk in OT environments — replacing them with secure, audited, time-boxed access pathways closes a door that’s frequently left wide open.

Structuring the whole programme around IEC 62443, the international standard for industrial automation and control systems security, which gives OT security work an audit-ready, recognised framework rather than an ad hoc collection of controls.

The Takeaway

If your OT security plan is “extend what we already do for IT,” it’s worth pressure-testing that assumption before deploying anything. The tools, the priorities, and the failure modes are different enough that treating OT as a variant of IT security tends to produce either false confidence (tools that report clean because they were never able to actually see the OT network) or actual operational disruption (active tooling destabilising equipment it was never validated against). SG2’s OT / ICS Security Configuration is built around the passive-first, availability-first constraints this actually requires.