OT and ICS Security: Protecting Operational Technology

When a security control can stop a turbine

In an IT environment, the worst case is usually stolen or encrypted data. In an operational technology (OT) environment, the worst case is physical: a pump running dry, a furnace overheating, a power feed dropping, a safety system failing to trip. OT is the world of industrial control systems (ICS) — the PLCs, SCADA systems, DCS platforms, and sensors that monitor and control physical processes in factories, utilities, pipelines, water treatment, and buildings. These systems do not process transactions; they move actuators and read gauges, and when they fail, the consequences are measured in downtime, damage, and sometimes safety.

That difference in consequence changes everything about how you secure them. For decades, OT was protected mainly by being isolated — separate networks, proprietary protocols, no internet connection. That "air gap" is largely gone. Digitization, remote monitoring, predictive maintenance, and the push for data from the plant floor have connected OT to IT and, through it, to the outside world. The systems were designed for a threat model that no longer exists, and the security practices that work for laptops and servers can actively break them. OT security is a distinct discipline, and treating it like IT is how well-meaning teams cause the outages they were trying to prevent.

Why IT security tools can break OT

The instinct to point existing IT security tooling at the plant floor is understandable and frequently disastrous. The constraints that make OT different are concrete:

• Availability outranks confidentiality. IT security prioritizes protecting data (the CIA triad, in that order). OT inverts it: availability and safety come first. A process that must run continuously cannot tolerate a control that might interrupt it. The priority order is closer to safety, then availability, then integrity, then confidentiality.
• You cannot patch on demand. A production line or a water plant cannot be taken down for Tuesday's patch cycle. Maintenance windows may come once or twice a year, and some systems cannot be patched at all without vendor recertification. Vulnerabilities often must be mitigated rather than fixed.
• Active scanning can crash devices. A routine vulnerability scan that a server shrugs off can knock a fragile PLC offline, because these devices have minimal compute and were never built to handle unexpected traffic. Aggressive IT tools are genuinely dangerous here.
• Decades-long lifecycles. IT refreshes hardware every few years; OT equipment runs for twenty or thirty. Environments are full of systems running unsupported operating systems that cannot be upgraded because the industrial application on top of them was certified against that exact version.
• Insecure-by-design protocols. Many industrial protocols (Modbus, DNP3, and others) were created for isolated, trusted networks and have little or no authentication or encryption. You often cannot bolt security onto the protocol; you have to protect the network around it.

These are not excuses — they are engineering realities. A security program that ignores them will be rejected by the plant, and rightly so.

Segmentation is the load-bearing control

Because you often cannot patch the endpoints, harden the protocols, or scan the devices, the network architecture does most of the defensive work. The foundational model is the Purdue model, which organizes an industrial environment into hierarchical levels — from physical processes and controllers at the bottom (Levels 0–2), through plant operations and site systems (Level 3), up to the enterprise IT network (Levels 4–5). Security follows the boundaries between those levels.

The core principles:

• Segment IT from OT rigorously. The boundary between the corporate network and the plant floor is the single most important control. A well-defined industrial DMZ between them ensures no direct path runs from a phished corporate laptop straight to a controller. Much real-world OT damage has come from attackers pivoting from a compromised IT network into an under-segmented OT one.
• Segment within OT. Zones and conduits — grouping systems by function and criticality and tightly controlling traffic between them — contain an intrusion so a compromise in one cell cannot spread across the plant. This is the network segmentation discipline applied to physical process control.
• Control remote access deliberately. Vendor remote access for maintenance is a leading intrusion path. It must run through brokered, monitored, authenticated channels — never a modem or a flat VPN into the control network — and align with zero-trust principles: verify every session, grant least privilege, and assume the connecting device may be hostile.

Figure: OT defense is architectural — the industrial DMZ isolates the plant floor from enterprise IT, and internal zones and conduits keep an intrusion in one cell from spreading across the process.

Visibility without disruption

You cannot protect what you cannot see, and most organizations have a poor inventory of what is actually on their OT network — which controllers, what firmware, communicating with what. The catch is that the usual way IT builds inventory, active scanning, is exactly what can crash fragile OT devices. The answer is a different technique:

• Passive monitoring. Purpose-built OT monitoring platforms watch a mirrored copy of network traffic without sending a single packet to the devices themselves. From that passive view they build an asset inventory, map communication patterns, and establish a baseline of normal process behavior — all without touching the endpoints.
• Baseline-driven anomaly detection. OT traffic is far more predictable than IT traffic; the same devices talk to the same devices in the same patterns continuously. That predictability is an advantage — a controller suddenly receiving commands from an unexpected source, or a new device appearing, stands out sharply against a stable baseline.
• Safe vulnerability awareness. Rather than scanning, OT-aware tooling correlates the passively discovered inventory (device models, firmware versions) against vulnerability databases to identify known issues without probing the devices, feeding a mitigation-focused workflow.

The output is an accurate picture of the environment and an alert when something deviates from the normal process — achieved without introducing the disruption that active tooling would cause.

Govern OT and IT security together

The final challenge is organizational, not technical. OT has traditionally been owned by engineering and operations, IT security by the security team, and the two often barely talk. That gap is where risk accumulates, because the connected reality means an IT compromise can become an OT incident. Bridging it requires deliberate structure:

1. Joint ownership and shared language. Security and engineering must plan together, with security respecting operational and safety constraints and engineering treating cyber risk as a real operational risk. Neither can secure OT alone.
2. OT-specific incident response. An IT playbook that says "isolate and reimage the host" may be exactly wrong for a system controlling a live physical process. OT incident response must account for safety and for the fact that pulling a system offline can itself cause harm. Reference frameworks like the NIST guidance on ICS security and the ISA/IEC 62443 standards give the program a defensible structure.
3. Safety systems as a distinct tier. Safety instrumented systems — the last-line controls that prevent physical catastrophe — warrant the strongest isolation and the most conservative change management of anything in the environment.

The organizations that do this well treat OT security as a partnership between the people who understand the process and the people who understand the threat, governed as one program rather than two.

Where to start

Begin with visibility and boundaries, because they are the highest-leverage and lowest-risk moves. Deploy passive monitoring to build an accurate OT asset inventory and behavioral baseline without touching a single device. Then verify and harden the IT/OT boundary — a real industrial DMZ, no flat paths from corporate to control — and lock down vendor remote access through brokered, monitored channels. Only with visibility and segmentation in place should you layer on the rest, always mitigating around constraints you cannot patch away.

intSignal secures converged IT and OT environments with the constraints of the plant floor in mind: passive OT visibility, IT/OT segmentation, controlled remote access, and network security governed jointly with your engineering team. Talk to our team and we will help you find the paths between your corporate network and your physical process before an attacker does.