Two environments, two sets of priorities
Security professionals moving from IT into OT often carry across a set of instincts that served them well in the office environment and that do not transfer cleanly to a plant floor. This is not a matter of OT being harder or more complex in some general sense. It is that the two environments are built around different priorities, and controls designed around the wrong priority tend to create risk rather than remove it.
The clearest way to see this is through the classic security triad of confidentiality, integrity, and availability. In most IT contexts, confidentiality is weighted heavily, since the primary asset being protected is often data. In most OT contexts, the ordering effectively inverts: availability and integrity of the physical process take priority, because the consequence of failure is not a data breach but a process upset, a safety event, or unplanned downtime with direct financial and physical consequence.
Patching looks simple until you try it on a live process
In IT, patch management is largely a scheduling problem. Patches are tested, deployed on a defined cadence, and a reboot during a maintenance window is an inconvenience rather than a crisis. In OT, the same patch that closes a vulnerability on a workstation can be the reason a control system becomes unavailable at exactly the wrong moment.
Many OT devices cannot be patched without vendor validation, since an unvalidated patch might interact badly with the specific configuration of that control loop. Some devices cannot be patched at all without replacing them, either because they are no longer supported or because taking them offline requires a planned outage that might only occur once a year. A mature OT security programme accounts for this by building compensating controls, such as network segmentation and monitoring, around assets that cannot be patched promptly, rather than treating unpatched systems purely as a gap to be closed on the same timeline as IT.
Standard security tools can behave differently on OT devices
Tools that are unremarkable in an IT environment have a track record of causing problems when applied directly to OT. Active vulnerability scanners, which send probing traffic to identify open ports and services, have been documented to crash programmable logic controllers that were never designed to handle unexpected or malformed requests. Endpoint detection agents, designed for general-purpose operating systems, can consume resources or interfere with real-time processes on systems where a millisecond of latency has operational consequences. Even routine actions like an antivirus scan can affect the timing-sensitive behaviour of a control application in ways that would be invisible on a standard office laptop.
This does not mean OT environments should go unmonitored. It means the monitoring approach needs to be built for the environment: passive network monitoring rather than active scanning in most cases, application allowlisting rather than signature-based antivirus where feasible, and careful, vendor-validated testing before any new tool is deployed against live control systems.
The consequences of failure are different in kind, not just degree
An IT security incident, even a serious one, is usually contained to the digital domain: data is exposed, systems are unavailable, recovery involves restoring from backup and notifying affected parties. An OT security incident can extend into the physical world. TRISIS, the 2017 attack on a Saudi petrochemical facility, specifically targeted the safety instrumented system, the layer of protection designed to prevent a catastrophic release or explosion if the process control system fails. The attackers were not trying to steal data. They were attempting to disable the last line of defence against physical harm.
This is why OT security decisions cannot be made purely on the basis of an IT-style risk calculation weighted towards data sensitivity and financial exposure. The right question in OT is frequently what happens to the physical process, and to the people near it, if this control fails.
What this means for how teams are structured
The practical implication is that OT security cannot simply be an extension of the IT security team’s remit, applying the same tools and playbooks to a different network. It requires people who understand both security and the operational process being protected, working from a risk model built around safety and availability, using tools and change management processes suited to systems that were never designed with security as a primary consideration. Organisations that recognise this early, and build governance and technical capability accordingly, tend to avoid the costly cycle of deploying an IT-style control, discovering it causes an operational disruption, and rebuilding the approach from scratch.
