OT/ICS Security Best Practices: Protecting Operational Technology in 2026

The Purdue Enterprise Reference Architecture (PERA), commonly called the Purdue Model, provides the conceptual framework for OT network segmentation. Understanding it is prerequisite to understanding both the historical security design and its current challenges.

The Purdue Model defines five levels: Level 0 (physical process: sensors, actuators, motors); Level 1 (basic control: PLCs, RTUs, DCS controllers managing the physical process); Level 2 (area supervisory control: SCADA systems, HMI workstations displaying process state to operators); Level 3 (site operations: historian servers, batch management, site-level data aggregation); Level 3.5 (the DMZ separating OT from IT); and Level 4/5 (enterprise IT: business systems, ERP, email, corporate network).

The original Purdue design assumed physical air gaps between levels. Communication moved strictly upward from the physical process to business systems; no direct connectivity existed between corporate IT and industrial controllers. This model provided strong security by architectural isolation.

The air gap has eroded extensively in modern OT environments. Business drivers for OT/IT convergence are real: operational data fed directly to ERP systems for production planning, remote vendor access for equipment maintenance, cloud-connected industrial IoT devices, and corporate IT tools deployed on Level 2 and 3 systems. Each connectivity bridge creates a potential path for IT-born malware to reach OT systems and for OT-focused attackers who have compromised IT networks to traverse into the operational layer.

The security task is not to restore the original air gap, which is neither practical nor desirable in most operations, but to implement controlled connectivity with appropriate detection and segmentation at each boundary.

OT environments face a distinct threat actor landscape from corporate IT. While ransomware groups occasionally reach OT systems through IT/OT convergence (as in the Colonial Pipeline incident), the most sophisticated OT threats are nation-state groups with specific ICS capabilities and objectives.

Dragos tracks 13 dedicated ICS threat groups, the most significant of which include: VOLTZITE (overlaps with Volt Typhoon), assessed as Chinese state-aligned, which has been documented pre-positioning in US water, power, and communications infrastructure. VOLTZITE's TTPs emphasize living-off-the-land techniques and long-term persistent access designed to enable future disruption operations, not immediate impact. ELECTRUM (assessed Russian state-aligned), responsible for the CRASHOVERRIDE/Industroyer malware used against Ukrainian power infrastructure. KAMACITE, which serves as an initial access broker for Russian state-aligned groups targeting energy sector OT environments.

ICS-specific attack patterns differ from IT attacks in important ways. OT attackers invest significant time in reconnaissance before taking any action with physical consequences. They learn the specific process they intend to disrupt: what equipment is running, what protocols are in use, what process values are normal, and what manipulations would cause damage. The ZionSiphon malware analyzed by Darktrace contained hardcoded facility names and specific process parameter values for Israeli water infrastructure, demonstrating the depth of reconnaissance that precedes sophisticated OT attacks.

For defenders, this reconnaissance phase is the best detection opportunity. Anomalous HMI queries, unusual protocol traffic between levels, and unauthorized read operations against process historians often precede the destructive phase by weeks or months.

OT asset inventory is more complex than IT inventory for two reasons: OT devices often cannot respond to standard network scanning without disrupting their control functions, and OT networks contain a wider variety of proprietary protocols (Modbus, DNP3, S7comm, EtherNet/IP, PROFINET) that standard IT network tools cannot parse.

Passive network monitoring is the OT-safe approach to asset discovery. OT-specific platforms including Dragos, Claroty, Nozomi Networks, and Microsoft Defender for IoT analyze network traffic in span or tap mode, identifying OT assets, their communication relationships, and their protocol behaviors without sending any active scanning traffic that could affect control system operation. These platforms build an asset inventory from observed traffic, identify protocol anomalies, and detect communication patterns inconsistent with baseline OT behavior.

Vulnerability management in OT operates under a different risk framework than IT. The CVSS-based SLA model (critical vulnerabilities patched in 24 hours) is unworkable when patching a PLC requires a maintenance window, vendor support, and potentially recertification of the device's safety functions. ICS-CERT advisories provide the primary vulnerability intelligence source for OT systems.

The Dragos Platform and Claroty both offer OT-specific vulnerability prioritization that accounts for whether a vulnerability is exploitable via the protocols and network paths present in your specific environment, not just the CVSS score. This context-aware prioritization is essential for managing the large volumes of vulnerabilities in legacy OT systems that will never be patched in a typical enterprise timeframe.

OT detection strategy must balance two requirements that are in tension: detecting threats effectively, and doing so without active interrogation of control systems that could interfere with operational processes.

The primary detection architecture for OT is passive network traffic analysis with protocol-aware inspection. Industrial protocols like Modbus, DNP3, and S7comm have defined vocabularies of function codes and register addresses. A Modbus write command to a register address that controls a pump speed, arriving from a workstation that normally only reads process data, is anomalous. Protocol-aware detection engines can identify these anomalies even without understanding the specific physical process they control.

The detection hierarchy for OT should cover four layers: the IT/OT boundary (firewall logs, VPN access events, DMZ traffic); the OT network (protocol anomalies, new device appearances, unusual communication paths between levels); individual OT devices where possible (historian access logs, HMI command logs, PLC program change events); and the physical process (process variable anomalies that could indicate manipulation, such as a valve position that does not match the commanded position).

SIEM integration for OT events requires custom parsers for OT-specific data sources, since most SIEMs are designed for IT log formats. Dragos and Claroty both offer SIEM integrations that normalize OT events into SIEM-compatible formats. Build OT-specific correlation rules: an OT engineer who normally accesses the SCADA HMI during business hours accessing the historian at 2 AM from a new IP address warrants different treatment than the same activity from a standard IT account.

For OT environments that use standard IT protocols (Windows-based HMIs, active directory-joined engineering workstations), standard IT detection techniques apply at those layers. The presence of lateral movement techniques on Windows systems in OT environments, such as Pass-the-Hash or PsExec, is a critical detection signal because these techniques are inconsistent with normal OT operations.

OT incident response requires adapting standard IR procedures to account for the physical consequences of containment decisions. In IT, isolating a compromised endpoint from the network is a routine early-stage containment action. In OT, isolating a compromised HMI that is actively displaying process state to operators, or a historian that is feeding data to a safety system, could create immediate operational and safety risks.

The fundamental difference is that OT incident response must involve operations leadership from the first decision point, not just security and IT. The decision to isolate, shut down, or continue running a potentially compromised OT system is an operations and safety decision as much as a security decision. Define the decision authority and escalation chain before an incident, not during one.

OT-specific IR planning should define: which systems can be isolated without operational impact (engineering workstations, historian clients); which systems require a controlled shutdown procedure before isolation (HMIs actively controlling processes); which systems cannot be safely isolated without first transitioning the process to manual control; and what the manual operation fallback procedures are for each critical process.

Forensic investigation in OT requires OT-specific expertise. Standard digital forensics tools may not correctly acquire or parse data from PLCs, DCS controllers, or proprietary historian databases. Dragos, Claroty, and specialized ICS security firms offer OT incident response services with the engineering expertise to safely investigate OT systems without interfering with operational recovery.

Post-incident, the OT security program should address the root cause with the same rigor as an IT incident. If the breach path was an overprivileged vendor VPN account, that is a systemic access control gap, not a one-off event.