OT Security

IT vs OT

How information technology and operational technology differ in purpose, design philosophy, threat model, and what those differences mean for security practice.

Where you will see it: Relevant in industrial environments, critical infrastructure, and wherever IT networks connect to operational technology systems.

What it is

IT refers to the systems used to process, store, and communicate data: servers, workstations, cloud infrastructure, enterprise applications, and the networks connecting them. OT refers to the systems used to monitor and control physical processes: PLCs, RTUs, SCADA systems, distributed control systems, and the industrial networks they run on. Both categories involve computers and networks, but they were designed with different goals, different constraints, and very different definitions of what failure means.

Key points

IT systems prioritize confidentiality and integrity. OT systems prioritize availability and physical safety above everything else.
IT operates on refresh cycles measured in years. OT equipment runs for decades, often without updates or vendor support.
IT security tools and methods were built for a different environment and can cause serious harm when applied to OT without adaptation.
Convergence between IT and OT networks is growing, which transfers IT-world risk into environments that were never designed to handle it.

How it works in broad strokes

Before touching an OT environment, understand what the physical process is and what an unplanned interruption would mean in operational and safety terms.
Map which systems are IT and which are OT, paying attention to where the two environments connect, because those connection points are where risk transfers between worlds.
Avoid applying IT security tooling directly to OT without vendor confirmation and testing in a non-production environment first.
Recognize that change management in OT is far more conservative than in IT. Updates, reconfigurations, and interventions follow planned maintenance windows and require cross-functional approval.
Build separate monitoring strategies for OT that rely on passive observation rather than active interrogation of devices.

Concrete example

A security team responsible for both IT and OT at a manufacturing company decides to roll out endpoint detection software across the entire environment. In IT, this goes smoothly. When the same agent is deployed on an older Windows-based HMI in the production facility, the additional CPU load causes the interface to become unresponsive, triggering an unplanned line stop. The difference was not the tool. It was the environment the tool was deployed into.

Why it matters

Security teams trained in IT often encounter OT environments and apply familiar tools and thinking without realizing how different the context is. Running a port scan against a corporate server is routine. Running the same scan against a PLC on a manufacturing floor can crash it. Rebooting a server for a patch is normal IT practice. Rebooting a controller managing a chemical process is an operational event that requires careful planning and coordination. These differences are not edge cases. They are the rule in OT, and ignoring them creates risk rather than reducing it.

Security angle

The right security controls for OT are often architectural rather than endpoint-based: segmentation, access control at the boundary, and unidirectional data flows rather than agents and scanners on the devices themselves.
Incident response in OT must account for the physical process. Isolating a compromised system may need to wait until the process reaches a safe state, which is a constraint that simply does not exist in IT.
Visibility is the first priority in most OT environments. You cannot defend what you cannot see, and most OT networks have very little monitoring in place.

Common pitfalls

Assuming that a tool or practice that is safe in IT is safe in OT. The environments are different enough that this assumption should never be the starting point.
Underestimating how long change takes in OT. A security improvement that would take days to deploy in IT can take months in OT due to operational windows, vendor dependencies, and safety reviews.
Ignoring the people dimension. OT environments are often operated by engineers and technicians whose primary expertise is the physical process, not cybersecurity, which shapes how security programs must be designed and communicated.

DEEP DIVE

▾

Different jobs, different design priorities

IT systems exist to move and process information. Their design priorities reflect that: reliability matters, but so does flexibility, rapid iteration, and the ability to update and replace components. When an IT system fails, the consequence is usually operational disruption. Users cannot access a service, data is unavailable, a business process stalls. These are serious outcomes, but they are recoverable and do not typically involve physical harm.

OT systems exist to control physical processes in real time. Their design priorities are availability and determinism. A PLC controlling a motor must respond to its inputs within a fixed time window, every time, without exception. A SCADA system managing a water treatment plant must remain operational continuously because the alternative is not an inconvenience but a public health risk. This is why availability sits at the top of the OT priority stack in a way that simply does not apply to most IT environments.

These different priorities produce different engineering cultures. IT teams are accustomed to patching frequently, deploying updates regularly, and accepting some downtime for maintenance. OT teams are accustomed to planning every change meticulously, testing in parallel environments, and treating unplanned downtime as a serious operational failure. Neither culture is wrong. They reflect the actual requirements of what each environment is built to do.

Lifespans and the patching problem

In IT, a server might be replaced every three to five years. Software is updated on a monthly or even weekly cycle. Security patches are applied as a routine operational task. The assumption built into most IT security frameworks is that assets can be updated when vulnerabilities are discovered, and that the update process is normal and expected.

In OT, this assumption breaks down almost immediately. Industrial equipment is expensive, deeply integrated into physical infrastructure, and validated as a complete system. A PLC controlling a turbine is not just a computer running software. It is a certified component of a safety system. Replacing or updating it requires re-validation of the entire system, which can take months and significant cost. Vendors may not release patches at all for older products. Some systems run operating systems that have been out of vendor support for a decade.

This means that in OT, the question is rarely how quickly can we patch this vulnerability but rather how do we operate safely with this vulnerability present for the foreseeable future. The answer is almost always compensating controls at the network and access level, reducing the exposure of the vulnerable device rather than fixing the device itself. This is a fundamentally different security posture from IT, and understanding it is essential for making realistic security plans in industrial environments.

Protocols built for reliability, not security

The protocols used in OT environments were designed in an era when industrial networks were physically isolated and security was not a design consideration. Modbus, developed in 1979, has no authentication and no encryption. DNP3, widely used in power and water infrastructure, was designed for reliable communication over noisy serial links, not for security in a networked environment. Many proprietary vendor protocols share the same characteristics.

These protocols assume that any device on the network is authorized to communicate. There is no concept of identity verification before a command is accepted. A Modbus master can send a write command to a PLC and the PLC will execute it without asking who sent it or whether the command is legitimate. This design is not a mistake. It was the right engineering choice for isolated industrial networks in 1979. It becomes a serious problem when those same protocols are now reachable from corporate networks or the internet.

The implication for security is that you cannot fix the protocol. You can only control who has access to the network segment where those protocols operate. Network segmentation, access control lists, and industrial firewalls that understand OT protocols become the primary security controls, because the protocols themselves will never provide authentication or encryption in legacy deployments.

Where IT and OT connect, and why that matters

The traditional model for OT security was the air gap: a complete physical separation between the operational network and everything else. In practice, true air gaps have become rare. Organizations connect OT to IT to collect production data for business analytics, to enable vendor remote support, to integrate with enterprise resource planning systems, and to provide management visibility into plant operations.

Each of these connections makes business sense individually. Collectively, they create a pathway from the IT world into the OT world. The risk is not theoretical. The attack pattern seen in real incidents follows a consistent shape: compromise a less-defended IT system, pivot toward systems with access to the OT environment, and from there reach the control layer. The IT network becomes the entry point, and the OT network becomes the target.

The security challenge is that most of these connections are not managed as security boundaries. A historian server that sits between IT and OT, collecting process data from the control layer and making it available to corporate reporting systems, is often configured with access to both networks without strict controls on what can flow in either direction. Identifying and hardening these bridging points is one of the most impactful things an organization can do to reduce IT-to-OT risk.

Getting security right across both environments

Organizations that manage both IT and OT well tend to treat them as separate disciplines that require coordination rather than unification. They have different asset inventories, different change management processes, different monitoring strategies, and different incident response playbooks. What they share is an understanding of where the environments connect and how risk can transfer between them.

Security standards like IEC 62443 provide a framework specifically designed for OT environments, with concepts like zones and conduits that map to the physical and operational reality of industrial networks. These standards are worth understanding because they offer a vocabulary and a structure that is appropriate for OT in a way that IT-centric frameworks are not.

The most practical starting point for any organization operating across both environments is an honest map of what is connected to what. Many organizations are surprised by what they find: undocumented connections, vendor access paths that were set up for convenience and never reviewed, and IT services that reach further into the OT network than anyone realized. That map is the foundation everything else is built on.