If you've ever tried applying a standard IT security control to an operational technology environment — and watched it fail — you already understand the core problem this article addresses. OT and IT networks are not variations of the same thing. They are fundamentally different systems, built for different purposes, governed by different constraints, and exposed to different categories of risk. Security approaches designed for one do not transfer to the other, and treating them as equivalent has caused real damage: unplanned downtime, physical equipment failures, and, in documented cases, harm to people.
This article explains why. Not in abstract terms, but through the specific architectural, operational, and risk differences that make industrial cyber security a discipline in its own right.
IT networks are designed around data: moving it, storing it, processing it, protecting its confidentiality and integrity. The assets are servers, endpoints, and applications with lifecycles measured in three to five years. Patching is routine. Downtime is planned and recoverable. The CIA triad — confidentiality, integrity, availability — applies roughly in that order of priority.
OT networks are designed around physical processes: controlling machinery, managing energy flows, operating pipelines, running production lines. The assets are programmable logic controllers (PLCs), distributed control systems (DCS), remote terminal units (RTUs), and human-machine interfaces (HMIs) — many of which were never designed to be networked at all, let alone connected to systems that touch the internet.
The protocols that run these environments reflect their industrial origins. Modbus, developed in 1979, has no authentication mechanism — it was designed for closed serial networks where the assumption was physical isolation.[1] DNP3, used extensively in electric utilities and water systems, added some integrity features, but was not built for adversarial conditions. PROFINET and EtherNet/IP are more modern, but they are still deterministic industrial protocols engineered for real-time control, not security. These protocols transmit commands to physical actuators. A spoofed Modbus packet doesn't corrupt a file — it opens a valve, trips a breaker, or changes a temperature setpoint.
The topological model is also different. IT networks use a relatively flat architecture with segmentation enforced by firewalls and access controls. OT networks are traditionally organized in a hierarchical model — often described using the Purdue Reference Model — where the field device layer (level 0-1) connects upward through control systems (level 2) to supervisory and business systems (levels 3-4).[1] The assumption was that higher layers were isolated from external networks. That assumption has been systematically eroded by the convergence of IT and OT, remote access requirements, and cloud connectivity.
The asset lifecycle difference is perhaps the most practically consequential. An IT organization replaces laptops every three to five years and patches servers monthly. In OT, a PLC installed in 2005 may still be running production in 2025 — and its vendor may no longer exist. Industrial assets are expected to run for 15, 20, or 30 years.[1] The firmware is often fixed, often for compatibility reasons. The vendor patch cadence is slow, if patches exist at all. This is not negligence; it is the economics and operational logic of industrial infrastructure.
The failure modes are specific and predictable.
You cannot patch on the same schedule. In IT, a critical vulnerability prompts an emergency patch within days. In OT, patching a PLC in a running production environment may require a planned maintenance window weeks or months away. In some environments — nuclear, pharmaceutical, continuous chemical processes — patching may require a full production shutdown. The operational risk of the patch can exceed the security risk of the vulnerability. This is not an irrational tradeoff; it is an engineering reality that IT-centric security frameworks do not account for.
Availability is not a secondary priority — it is the primary one. An IT network can absorb downtime. A help desk goes offline; users are inconvenienced but the company continues to operate. In OT, availability failure has physical consequences. A natural gas compressor station that loses control system availability doesn't just lose data — it loses the ability to maintain pressure in a pipeline and customers lose service. A manufacturing line that goes offline unexpectedly can cost hundreds of thousands of dollars per hour [Citation Needed] and, depending on the process, the batch is unusuable or can create safety hazards. Security tools that introduce latency, require reboots, or generate traffic loads that stress low-bandwidth industrial links are not deployable in these environments without significant redesign.
Endpoint agents don't install on PLCs. The standard IT security playbook assumes you can install software on the endpoint: an EDR agent, a log collector, a vulnerability scanner. PLCs and RTUs are embedded systems. You cannot install an agent on a Siemens S7-1500 or a Rockwell ControlLogix. Visibility into these assets requires passive network monitoring — observing the traffic they generate rather than querying them directly. Active scanning — sending probe packets to map the network — can cause transient lockups in industrial devices. This is documented.[1] Several industrial device types will fault or reboot if they receive unexpected network packets, including standard ICMP pings.
Log sources are absent or non-standard. SIEM platforms are built on the assumption that assets generate structured logs — Windows Event Logs, syslog, application logs. Industrial assets generate process data: sensor readings, alarm states, setpoint changes. This data is valuable for detecting anomalous behavior, but it requires different collection, parsing, and analysis technology than IT log management. A historian database full of process telemetry is not the same as a SIEM-compatible log source.
Network segmentation designed for IT creates operational problems in OT. IT security commonly calls for aggressive micro-segmentation: isolate workloads, restrict lateral movement, implement zero-trust principles. In OT, control system traffic flows are deterministic and often cannot be interrupted. A redundant communication path that IT security wants to block might be the failover channel for a safety system. Applying IT segmentation logic without deep knowledge of the OT traffic model can cause process disruptions that are operationally indistinguishable from a cyber attack.
Beyond the architectural and tooling incompatibilities, there is a deeper structural difference in the nature of the risk itself.
Physical consequences. In IT, the worst-case outcome of a successful cyber attack is data theft, ransomware encryption, or business disruption. These are serious. In OT, the worst-case outcome includes physical destruction of equipment, environmental damage, and harm to people. The 2010 Stuxnet attack destroyed uranium enrichment centrifuges at Natanz.[2] The 2014 German Steel mill attack changed code in the blast furnace, preventing shutdown and causing significant physical damage.[3] The 2022 Industroyer2 attack targeted Ukrainian high-voltage substations with the explicit goal of triggering physical disconnection.[4] These are not theoretical scenarios.
Interdependencies with critical infrastructure. OT environments are not isolated business systems. They are frequently part of supply chains and infrastructure networks where a failure at one node propagates to others. An attack on a natural gas transmission operator affects industrial customers downstream. A compromise of an electricity distribution system has cascading effects across sectors. This interconnectedness means the blast radius of an OT security failure can extend far beyond the organization directly attacked.
Scarcity of historical loss data. IT cyber risk quantification benefits from decades of accumulated actuarial data: breach costs, ransomware payouts, incident frequencies by industry and company size. OT has far less. Incidents are underreported — organizations are reluctant to disclose attacks on critical infrastructure. The incident population is smaller. The consequence models are more complex because physical damage and production loss require engineering judgment, not just financial modeling. This data scarcity creates real challenges for industrial cyber risk management and makes traditional IT-based risk models unreliable in OT contexts.
Long-dwell, slow-burn attack patterns. OT attacks are frequently characterized by long reconnaissance phases and deliberate, precise execution. Adversaries operating in OT environments often spend months mapping assets, understanding process flows, and positioning for impact before executing. Industroyer, the malware used against Ukrainian infrastructure in 2016 and again in 2022, was engineered to speak native industrial protocols and execute impact operations with surgical precision.[4] Detection approaches calibrated for IT attack patterns — which tend to be faster and nosier — will miss OT-specific attacker behavior.
One of the most significant factors making OT security harder today is IT/OT integration — the deliberate or gradual connecting of industrial networks to corporate IT infrastructure and, increasingly, to the internet. The drivers are legitimate: remote monitoring reduces operational costs, integration with enterprise systems enables better production planning, cloud connectivity enables analytics at scale. The consequences for security are substantial.
When an OT network was genuinely isolated, the threat model was limited to physical access and insider threat. A motivated attacker would need to be in the building. Convergence eliminated that constraint. The 2014 German steel mill attack — in which attackers accessed the plant network via a spear-phishing email targeting the corporate network, then moved laterally into the OT environment — followed the same IT-to-OT path that has since become the standard initial access pattern for industrial attacks.[3] The Colonial Pipeline ransomware attack in 2021 targeted IT systems but caused the operator to proactively shut down OT operations out of uncertainty about the attack's scope.[5] The IT/OT boundary is now an attack surface, whether organizations have fully acknowledged it or not.
IT-OT integration and convergence also complicates the security architecture. Historian servers sit in IT/OT DMZs and communicate with both sides. Remote access solutions used by vendors for maintenance create channels from the internet directly into the OT network. Engineering laptops & workstations have been found connected to both corporate email and the plant control network simultaneously. Each of these is a potential crossing point for an adversary who has established a foothold in the IT environment.
Managing IT-OT integration securely requires both sides to understand the other's constraints — IT security teams need to understand why they cannot simply deploy their standard tooling in OT, and OT engineers need to understand the threat model that makes IT security teams uncomfortable with the network architecture they've inherited.
The practical implication of everything above is that industrial cyber risk management requires a purpose-built approach — not an IT security program with OT-specific add-ons.
This means starting from the physical process, not the network topology. The question is not "what vulnerabilities exist on these devices?" but "what would an attacker need to do to cause a specific physical outcome, and how likely are they to succeed?" This process-centric threat modeling is the foundation of frameworks like MITRE ATT&CK for ICS, which maps adversary tactics and techniques specifically to industrial control system environments.[6]
It means applying security standards that were designed with OT operational constraints in mind. IEC 62443 is the primary international standard for industrial control system security — built from the ground up for environments where availability takes precedence, assets have long lifecycles, and the consequence of a failure is physical, not just digital.[7]
And it means quantifying financial risk in terms that reflect OT's actual exposure profile. The financial impact of an OT cybersecurity incident is not measured in data records or notification costs — it is measured in production downtime, equipment replacement, regulatory penalties, and potential harm to people and infrastructure. The gap between IT risk metrics and OT operational reality is why generic risk scores and CVSS-based prioritization consistently fail to reflect true industrial exposure. Translating OT cyber risk in dollars — as Annual Expected Loss (AEL) and Value at Risk (VaR) — gives boards, insurers, and executives numbers they can govern against. Board level cyber risk reporting built on financial figures is fundamentally more defensible than one built on scores: a CFO can set a reserve against a dollar figure; a board can evaluate an insurance program against a VaR number. Neither can do anything useful with a red-amber-green heatmap. That translation requires modeling that accounts for process dependencies, failure scenarios, and consequence chains — not just vulnerability counts.
How organizations assess, quantify, and manage that exposure is what the DeRISK Platform is built to do — an OT cyber risk management platform that translates industrial security posture into Annual Expected Loss, Value at Risk, and a prioritized remediation plan in financial terms.
Want to assess where your organization stands?
Download the OT Security Readiness Checklist — 23 points to audit the security maturity of your industrial environment.
[1] National Institute of Standards and Technology (NIST), "SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security," September 28, 2023. URL: https://csrc.nist.gov/pubs/sp/800/82/r3/final
[2] CSO Online, "Stuxnet explained: The first known cyberweapon," August 31, 2022. URL: https://www.csoonline.com/article/562691/stuxnet-explained-the-first-known-cyberweapon.html
[3] SecurityWeek, "Cyberattack on German Steel Plant Caused Significant Damage: Report," December 18, 2014. URL: https://www.securityweek.com/cyberattack-german-steel-plant-causes-significant-damage-report/
[4] ESET, "Industroyer2: Industroyer Reloaded," April 12, 2022. URL: https://www.welivesecurity.com/2022/04/12/industroyer2-industroyer-reloaded/
[5] Cybersecurity and Infrastructure Security Agency (CISA), FBI, "DarkSide Ransomware: Best Practices for Preventing Business Disruption from Ransomware Attacks (AA21-131A)," May 11, 2021. URL: https://www.cisa.gov/news-events/cybersecurity-advisories/aa21-131a
[6] MITRE, "ATT&CK for ICS Matrix." URL: https://attack.mitre.org/matrices/ics/
[7] International Electrotechnical Commission (IEC), "Understanding IEC 62443." URL: https://www.iec.ch/blog/understanding-iec-62443