OT/ICS Cybersecurity: Securing Operational Technology Networks
Operational technology security is not IT security applied to different hardware. OT environments — industrial control systems (ICS), SCADA networks, distributed control systems (DCS), and programmable logic controllers (PLCs) — operate under constraints that invalidate most IT security assumptions. Availability is paramount: a refinery control system cannot be rebooted for a patch; a power grid substation RTU cannot accept an EDR agent; a water treatment SCADA cannot tolerate active network scanning. Meanwhile, the threat has become existential: CISA's Volt Typhoon advisories document that PRC-sponsored actors have pre-positioned in US critical infrastructure OT networks specifically to enable disruptive attacks in a future conflict. This guide covers the security controls that work within OT's operational constraints.
OT vs. IT Security: Where the Assumptions Break
Understanding why IT security practices fail in OT requires understanding the priority inversion between the two environments.
Availability over confidentiality
IT security prioritizes CIA in that order. OT security inverts this: availability is paramount (process uptime), integrity matters (a modified setpoint can cause physical damage), confidentiality is last. A security control that risks process interruption is often unacceptable regardless of the security benefit.
Long asset lifecycles
IT hardware is replaced every 3-5 years. OT assets run for 20-30 years. PLCs and RTUs installed in the 1990s with known vulnerabilities cannot be replaced on IT timelines. Compensating controls rather than patching are the primary risk management approach.
No agent support
Most OT devices (PLCs, RTUs, HMIs, engineering workstations running Windows XP/7) cannot support EDR agents. Some vendor support agreements explicitly prohibit installing third-party software. Security monitoring must be passive and network-based.
Patch windows measured in years
OT patches require vendor qualification, maintenance window scheduling, process shutdown, and sometimes physical access to isolated systems. Critical patches that would be applied in hours in IT may take 12-24 months to reach OT assets.
Proprietary protocols
OT environments use specialized industrial protocols (Modbus, DNP3, IEC 61850, EtherNet/IP, PROFINET) that IT security tools do not parse. Security monitoring requires OT-protocol-aware tooling.
The Purdue Model and Its Modern Limitations
The Purdue Enterprise Reference Architecture has been the dominant OT network segmentation model since the 1990s. It defines hierarchical zones from Level 0 (physical process) through Level 5 (enterprise network) with security boundaries between levels. The model remains useful as a reference, but the assumption of strict zone separation has been eroded by IT/OT convergence: remote access requirements, historian databases that aggregate process data for business systems, and vendor remote maintenance connections all cross Purdue boundaries by design.
“Volt Typhoon actors pre-positioned on OT-adjacent IT networks where lateral movement to OT would be possible. The IT/OT convergence that enables remote monitoring also enables adversary movement from IT to OT.”
CISA Advisory AA24-038A, February 2024
Level 0-2: OT core
Physical process devices (Level 0), sensors and actuators (Level 1), and supervisory control systems (Level 2). These levels should have no direct internet connectivity and severely restricted access from IT networks. Change here causes physical consequences.
Level 3: Operations management
Historians, batch management, and operational data aggregation. The Level 3 DMZ is the controlled crossing point between OT and IT. All IT/OT data exchange should be unidirectional (data diode) or through an explicit DMZ proxy — not direct connectivity.
Unidirectional security gateways
Data diodes (Waterfall Security, Owl Cyber Defense) provide hardware-enforced unidirectional data flow: process data can flow from OT to IT for monitoring and analytics, but no IT-originated traffic can reach OT. This eliminates the IT-to-OT attack path entirely for historian data flows.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
OT Asset Inventory: The Unsolved Problem
You cannot protect assets you cannot see. OT asset inventory is uniquely difficult because active scanning can crash PLC firmware and violate vendor support agreements. Passive discovery is the only safe approach.
Passive network discovery
OT-specific passive discovery platforms (Claroty, Dragos, Nozomi Networks, Armis for OT) monitor network traffic to build asset inventories by analyzing protocol communications — no packets sent to devices, no disruption risk. They identify device type, firmware version, vendor, communication patterns, and open protocols from traffic observation.
Asset intelligence enrichment
Raw passive discovery identifies devices; enrichment adds vulnerability context. OT asset management platforms correlate identified device/firmware combinations against vendor advisories and ICS-CERT advisories to surface known vulnerabilities without requiring active scanning.
Physical walkdowns
Network-invisible assets (field devices on serial networks, isolated PLCs) require physical inventory. Annual physical walkdowns combined with passive network discovery provide the most complete picture.
Configuration backups
PLC and DCS configurations are forensically critical and frequently not backed up. Implement scheduled configuration backup for all programmable devices. A misconfigured PLC after an incident without a known-good configuration backup can result in extended outages.
OT-Specific Threat Detection
OT threat detection requires understanding what normal looks like in an industrial environment. OT networks are highly deterministic: the same devices communicate with the same destinations on the same schedules. Deviations from baseline are anomalies.
Protocol-aware behavioral baselining
Establish baselines for normal OT communication flows: which PLCs talk to which HMIs, which historian polls which devices, which engineering workstations issue programming commands. Any new communication pair or unexpected command is an alert candidate.
ICS command monitoring
Monitor for high-risk ICS commands: firmware download, program change, configuration modification, and direct device control commands (STOP, RUN) issued outside of maintenance windows. Industroyer/CRASHOVERRIDE used legitimate ICS protocol commands to open circuit breakers — command-level monitoring catches this.
Engineering workstation activity
Engineering workstations are the highest-privilege access point in most OT networks. Monitor for unexpected programming sessions, after-hours access, connections from new IP addresses, and bulk configuration changes. Engineering workstation compromise is a common precursor to ICS-targeted attacks.
Historian and remote access monitoring
Historians and remote access systems (vendor VPN, jump servers) are the OT/IT boundary crossing points. Monitor all remote access sessions with full session recording for OT-destined connections. Historian write attempts (not just reads) are anomalous and should trigger investigation.
Remote Access Security for OT
Remote access to OT environments is the most common initial access vector for OT-targeted attacks. Secure Sockets Layer VPN services exposed to the internet on OT networks have been exploited in multiple nation-state campaigns.
Jump server architecture
All remote access to OT should transit a hardened jump server in the DMZ, not connect directly to OT assets. The jump server logs all sessions, enforces MFA, and provides session recording for forensic review.
Vendor access management
Third-party vendor remote access is the highest-risk remote access scenario. Implement vendor-specific accounts with limited privilege, time-bounded access tokens, and session monitoring. Vendor remote access should be explicitly approved before each session, not persistently available.
MFA for all remote access
CISA advisories document that the most common initial access vector for OT intrusions is valid credentials used through internet-exposed remote access. MFA eliminates credential stuffing and most phishing as viable remote access attack vectors.
Internet-facing OT service elimination
Audit for OT systems with internet-facing interfaces and eliminate them. Internet-exposed ICS devices are trivially discoverable via Shodan. Any internet-exposed OT system that cannot be immediately isolated should be treated as compromised pending investigation.
OT Incident Response: Different Priorities
OT incident response prioritizes process safety and continuity in ways that IT incident response does not. The standard IT response of isolating infected systems may not be appropriate when that system controls a physical process.
Safety-first containment
Before isolating a compromised OT system, verify that isolation will not cause an unsafe process state. Consult operations engineers before network isolation of any OT device. Process safety overrides security containment speed.
Manual operation capability
OT incident response plans must include manual operation procedures for critical processes. If SCADA is compromised and must be isolated, operators need trained procedures for manual control. This capability requires investment outside of security — operational resilience training with the operations team.
ICS-specific forensics
Standard IT forensics tools do not parse OT protocol traffic or PLC memory. OT forensics requires preserving historian data, network captures with OT protocol context, and PLC configuration snapshots before any remediation. Engage vendors with OT incident response capability (Dragos, Mandiant OT, Claroty) early in significant incidents.
Regulatory notification
OT incidents in critical infrastructure trigger sector-specific notification obligations: CISA for critical infrastructure sectors (16 sectors under CIRCIA), TSA directives for pipelines and rail, NERC CIP for electric utilities, NRC for nuclear. Know your sector's notification requirements before an incident.
The bottom line
OT security requires accepting the constraints that make it different from IT security — long asset lifecycles, no-agent environments, availability priority, and operational safety requirements — and building a defensive program within those constraints. Passive asset discovery, network behavioral monitoring with OT protocol awareness, hardened remote access, and OT-specific incident response planning are the foundation. The threat is real and nation-state adversaries are already in critical infrastructure networks. The question is whether defenders have the visibility to detect them.
Frequently asked questions
What is the difference between OT, ICS, and SCADA?
Operational Technology (OT) is the broad category covering hardware and software that monitors and controls physical processes. Industrial Control Systems (ICS) is a subset of OT referring specifically to computerized systems for industrial process control — includes SCADA, DCS, and PLCs. SCADA (Supervisory Control and Data Acquisition) is a specific ICS architecture where a central system supervises distributed field devices. All SCADA systems are ICS; not all ICS are SCADA.
Why can't standard IT security tools be used in OT environments?
IT security tools make assumptions that break in OT: they require agents (many OT devices cannot run third-party software), they use active scanning (which can crash PLC firmware), they assume regular patching (OT assets may go years without patches), and they do not understand OT protocols (Modbus, DNP3, IEC 61850). OT security requires passive, OT-protocol-aware monitoring tools and compensating control strategies instead of patching-first approaches.
What is the Purdue Model?
The Purdue Enterprise Reference Architecture is a hierarchical segmentation model for ICS networks with five levels: Level 0 (physical process), Level 1 (sensing and actuation), Level 2 (supervisory control), Level 3 (operations management), and Levels 4-5 (enterprise IT). Security zones and boundaries between levels are supposed to limit lateral movement from IT to OT. In practice, IT/OT convergence — remote access, historians, vendor connections — has eroded strict level separation in most organizations.
What is Volt Typhoon and why does it matter for OT security?
Volt Typhoon is a PRC-sponsored threat actor that CISA, NSA, and FBI jointly attributed to pre-positioning activities in US critical infrastructure IT networks — water, energy, transportation, communications — for potential future disruptive attacks. Volt Typhoon specifically uses living-off-the-land techniques to avoid detection and has been found in OT-adjacent IT networks where lateral movement to OT would be possible. It represents the most publicly acknowledged strategic OT pre-positioning threat.
How do you detect threats in OT environments without active scanning?
OT threat detection relies on passive network monitoring using OT-protocol-aware platforms (Dragos, Claroty, Nozomi Networks) that analyze traffic without sending any packets to OT devices. These platforms build communication baselines and alert on deviations: new communication pairs, unexpected engineering commands, off-hours access, firmware modifications, or ICS protocol anomalies. Behavioral baselining is particularly effective in OT because normal OT communication patterns are highly deterministic compared to IT environments.
What should an OT incident response plan include that IT plans do not?
OT incident response plans must include: (1) process safety assessment before any containment action, (2) manual operation procedures for critical processes in case SCADA must be isolated, (3) operations engineer involvement in all containment decisions affecting OT systems, (4) sector-specific regulatory notification procedures (NERC CIP, TSA directives, CIRCIA), and (5) OT-specific forensics capability — standard IT forensics tools cannot process OT evidence. The fundamental difference is that IT incidents have data/system consequences; OT incidents can have physical, safety, and environmental consequences.
What are data diodes and when should they be used in OT?
A data diode is a hardware device that enforces unidirectional data flow at the physical layer — data can pass in only one direction and the hardware makes reverse flow physically impossible. In OT, data diodes are used at the IT/OT boundary to allow process data to flow from OT to IT systems (historians, monitoring dashboards) without creating a return path that could be exploited for IT-to-OT attacks. Data diodes eliminate an entire class of attack paths; their limitation is that they do not support bidirectional protocols or remote management that requires return traffic.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.