OT vs IT Security: Why Industrial Environments Need Different Protection

OT vs IT Security: Why Industrial Environments Need Different Protection article by Dr Erdal Ozkaya

Understanding the Importance of OT vs IT Security

There is a question I ask every CISO who manages or oversees industrial environments, and the answer almost always tells me everything I need to know about their OT security maturity: When did you last take an inventory of every device on your operational technology network?

Most cannot answer it. Some give me a number that is years out of date. A handful admit they have never done it at all. And this is not incompetence — these are smart, experienced security leaders. The problem is that OT environments were never designed with security visibility in mind, and the tools and mental models that work perfectly well in IT environments simply do not translate.

Understanding why requires going back to basics.

The Fundamental Difference: Uptime Is the Security Model

In IT security, the classic triad is confidentiality, integrity, and availability in roughly that order of priority for most organisations. A data breach is catastrophic. A period of downtime is bad. A ransomware attack that encrypts your files is serious. But in most IT environments, you can patch, reboot, update, and recover. The system is designed for change.

OT environments flip this entirely. Availability is not just the top priority in many cases, it is the only priority that matters to the people running the environment. A pharmaceutical production line that goes down unexpectedly can cost millions per hour and trigger regulatory consequences. A water treatment facility that loses control of its processes creates a public safety incident. A power substation that trips offline at the wrong moment can cascade into a grid failure affecting hundreds of thousands of people.

This means that the normal security hygiene we take for granted in IT patch on Tuesday, restart on Wednesday, deploy the new endpoint agent Friday simply does not work in OT. Many industrial control systems run on embedded operating systems that cannot be patched at all. Others run on Windows XP or Windows 7 because the control software vendor has never validated their product against a newer OS. Rebooting a PLC that controls a critical industrial process is not an option you can take unilaterally, no matter what your vulnerability scanner is telling you.

The security implication is profound: the standard IT security playbook can actively cause harm in an OT environment if applied without adaptation.

Why IT Security Tools Break in OT Environments

This is something I feel strongly about, because I have seen it go wrong firsthand. Well-meaning security teams deploy the same tooling they use across their IT estate vulnerability scanners, network monitoring agents, endpoint protection into OT environments, and they create problems they never anticipated.

Active network scanning is the most common example. In IT, running a vulnerability scanner across a subnet is routine. In OT, sending active scanning packets to a Programmable Logic Controller (PLC) or a Remote Terminal Unit (RTU) can cause the device to crash, freeze, or behave unexpectedly. These devices were not built to handle the volume of network packets that a modern scanner generates. I have heard of active scanning triggering emergency shutdowns in industrial environments. This is not a theoretical risk.

Endpoint agents are another frequent casualty. Industrial workstations running SCADA software often have strict application whitelisting requirements enforced by the control system vendor. Installing an endpoint protection agent that is not on the approved list voids the support agreement, may cause application instability, and could require a full system reinstallation that involves a planned maintenance window not something you can schedule on short notice.

And then there is the simple issue of network architecture. IT networks are built for connectivity, segmentation-as-needed, and relatively flat designs that can be restructured. OT networks are built around the Purdue Model a hierarchical architecture that physically separates different levels of the control system, from enterprise systems at the top down to field devices at the bottom. The connections between these levels are limited by design, which is a security feature but it also means that OT networks often have almost no monitoring visibility at the lower levels where the most critical assets actually sit.

The ICS and SCADA Threat Landscape in 2026

The threat landscape for industrial control systems has changed dramatically over the past decade, and not in a good direction. ICS-targeting attacks are no longer rare nation-state operations they are increasingly commoditised, with ransomware groups actively targeting industrial environments because the operational impact of downtime creates enormous pressure to pay.

A few patterns I see consistently:

The IT-to-OT pivot. Threat actors who have compromised an IT network will look for pathways into connected OT systems. The convergence between IT and OT driven by Industry 4.0 initiatives, remote monitoring requirements, and cloud connectivity — has created far more of these pathways than most organisations realise. The attacker does not need to understand industrial protocols if they can find a workstation in the DMZ that has RDP access into the OT environment.

Living off the land in OT. Just as in IT environments, sophisticated OT threat actors increasingly use legitimate tools and protocols — Modbus, DNP3, OPC to blend in with normal industrial traffic. They do not need malware if they can speak the native language of the control system. This makes detection extremely difficult for teams that are not specifically monitoring OT protocol behaviour.

Targeting engineering workstations. Engineering workstations the computers used by automation engineers to program and configure PLCs are high-value targets because they have trusted connections to the deepest levels of the OT network. Compromise an engineering workstation and you have the keys to the control system. Yet these workstations are often poorly protected, infrequently updated, and connected to both IT and OT networks simultaneously.

Supply chain attacks on ICS vendors. The ICS vendor ecosystem is a significant attack surface. Control system vendors, software update mechanisms, remote support connections all of these represent pathways into OT environments that bypass the perimeter controls organisations have built around their plants. The SolarWinds incident demonstrated the scale of supply chain risk in IT; the equivalent in OT would be targeting a major SCADA vendor’s update infrastructure.

The Purdue Model vs Zero Trust What Actually Works in OT

There is a vigorous debate in the ICS security community about whether Zero Trust architecture can or should replace the Purdue Model in industrial environments. I have a nuanced view on this.

               

The Purdue Model is not broken — it was never designed to be a complete security architecture. It is a reference model for control system architecture that happens to have useful security properties: physical separation of levels, limited inter-level communication, and clear boundaries between enterprise and operational systems. These properties remain valuable and should be preserved.

What the Purdue Model does not provide is any kind of dynamic trust verification, lateral movement detection, or identity-based access control. It assumes that if something is inside the right level of the hierarchy, it is trusted. In a world where threat actors can reach OT environments through IT network pivots, supply chain compromises, and stolen remote access credentials, that assumption no longer holds.

What I advocate for is a pragmatic hybrid: preserve the Purdue Model’s segmentation properties while layering Zero Trust principles — specifically around identity verification, least privilege access, and continuous monitoring on top of them. This means:

• Enforcing MFA for all remote access into OT environments, including vendor remote support sessions
• Implementing jump servers or privileged access workstations for all access to OT systems, eliminating direct connectivity from IT endpoints
• Monitoring all inter-level traffic at the Purdue boundary using OT-native passive monitoring tools that do not generate active traffic
• Implementing role-based access control for engineering workstations, ensuring that operators cannot modify PLC logic and engineers cannot access process historian data they do not need
• Treating every remote access session as untrusted until verified, with session recording and anomaly detection

What a Real OT Security Programme Looks Like

I want to be practical here, because this is where a lot of OT security guidance goes wrong — it is theoretically correct but operationally useless. Here is what I actually recommend to organisations starting or maturing their OT security programmes.

Start with passive asset discovery. Before you can protect anything, you need to know what is there. Passive OT monitoring tools — platforms like Claroty, Dragos, Nozomi Networks, or Fortinet OT listen to network traffic and build an asset inventory without sending any packets. This is the OT-safe alternative to active scanning. Start here. You will almost certainly discover devices that nobody in your organisation knew existed.

Understand your process before you change anything. Spend time with the OT engineers and plant operators. Understand what the normal operation of the environment looks like which PLCs communicate with which historians, what the normal Modbus polling cadence is, which workstations have which connections. This knowledge is essential for building meaningful detection rules and for understanding what “abnormal” actually looks like in your specific environment.

Build a network architecture that supports monitoring. Most OT networks have no span ports or network taps at the lower Purdue levels. You cannot monitor what you cannot see. Work with your OT engineering team to add passive monitoring capability ideally at the Level 2/Level 3 boundary where the most interesting traffic flows. This requires planning and coordination, but it is not disruptive to operations.

Establish a clear incident response process for OT incidents. Your IT incident response playbook does not apply in OT. Isolating a compromised system in IT takes minutes. Isolating a compromised OT system without disrupting the production process requires coordination with operations, potential controlled shutdowns, and involvement of the control system vendor. Define the escalation path, the decision authority (who can authorise an OT network isolation?), and the communication plan before you need it.

Address the remote access problem. Remote access to OT environments for vendor support, for remote operations, for engineer access from home is one of the highest-risk surfaces in industrial cybersecurity. Implement a formal remote access programme with MFA, session recording, defined access windows, and vendor-specific jump server configurations. This is not glamorous, but it closes one of the most commonly exploited pathways into OT environments.

If you want to go deeper on this topic, I have written extensively about securing industrial environments in Safeguarding Industrial Operations one of my free books covering OT and ICS security in detail. It covers the technical architecture, the governance model, and the practical steps for building a programme that actually works in an industrial context.

The CISO’s OT Security Checklist

For those who want a quick diagnostic, here are the questions I ask when assessing an organisation’s OT security posture. If you cannot answer yes to most of these, you have significant work to do.

Getting to yes on all of those takes time often years for a complex industrial organisation. But knowing where you are is the essential first step, and it is one that too many organisations avoid because they are afraid of what the honest answer will be.

OT security is not a solved problem. The technology is evolving, the threat landscape is changing, and the operational constraints make standard security approaches unworkable without careful adaptation. But the organisations that are getting this right share one thing in common: they started by accepting that what works in IT does not automatically work in OT, and they built their programme from the ground up with that reality at its centre.

For the broader framework that OT security sits inside connecting to business continuity, incident response, and board-level risk governance — visit the Cyber Resilience Hub. And if you want the deep technical treatment, pick up Safeguarding Industrial Operations it is free, and it covers everything from the Purdue Model to ICS incident response in detail.

OT Network Segmentation: A Practical Guide for Security Teams

Safeguarding Industrial Operations

SCADA Security Best Practices fohttps://erdalozkaya.com/scada-security-best-practices-cisos/r CISOs

Zero Trust Network Security

ot security vs it security it and ot security differences between it and ot differences between ot and ot and it cybersecurity

Related CISO resources: Continue with Cyber Resilience Guide, Incident Response Hub, Zero Trust Strategy Guide, Free CISO Toolkit.