Most cyberattacks on industrial infrastructure don’t start in the plant. They start in the office. A phishing email reaches an IT admin. A contractor connects a compromised laptop. A remote session gets hijacked. The IT network is breached first. The attacker pivots to OT from there.
That pivot is possible because IT and OT are connected. The business case for connecting them is real — production analytics, remote monitoring, predictive maintenance. But the security assumptions built into IT don’t transfer to OT. When they’re applied unchanged, they open attack paths that didn’t exist before the connection.
Understanding the IT/OT divide is the precondition for building a security architecture that actually holds.
IT vs OT in short: IT systems manage data, applications and business processes.
OT systems monitor and control physical industrial processes. IT security prioritizes confidentiality; OT security prioritizes availability, safety and process continuity. When IT and OT networks converge, the main risk is that an IT compromise can become a path into industrial control systems.
IT and OT: Two Different Worlds
Information Technology (IT) covers the systems that process, store, and transmit data: servers, workstations, enterprise applications, cloud infrastructure. The guiding framework is the CIA triad — Confidentiality, Integrity, Availability. Confidentiality leads. A system temporarily offline for patching is an acceptable trade-off. A system leaking data is not.
Operational Technology (OT) covers hardware and software that monitors and controls physical processes: PLCs, SCADA systems, DCS, RTUs, HMIs. These systems run power grids, water treatment plants, oil pipelines, manufacturing lines. The guiding priority is availability and physical safety. Minutes of downtime can trigger safety systems. An uncontrolled process can injure people or damage equipment worth millions.
Beyond priorities, OT equipment is physically different from IT equipment. OT devices are built for industrial environments — extreme temperatures, vibration, electromagnetic interference, remote and hazardous locations. A server rack engineered for a data center doesn’t belong in a substation or on a refinery floor. That physical separation reinforced the operational separation for decades.
IT (Information Technology) | OT (Operational Technology) | |
|---|---|---|
Primary priority | Confidentiality | Availability & physical safety |
Patch cycle | Weeks to months | Years to decades (or never) |
Typical lifespan | 3–5 years | 10–30 years |
Downtime tolerance | Low (hours) | Near zero (minutes can trigger safety systems) |
Protocols | TCP/IP, HTTP, TLS | Modbus, DNP3, OPC-UA, Profibus, IEC 61850 |
Authentication | Standard (MFA, SSO) | Often absent or minimal |
Physical environment | Controlled (data center) | Harsh (heat, vibration, remote sites) |
Security model | Defense in depth | Historically: physical isolation (air gap) |
Consequence of breach | Data loss, financial damage | Process disruption, safety risk, physical damage |
Two Teams, Two Cultures and One Shared Problem
IT and OT aren’t just different systems. They’re run by different people with different training, different vocabularies, and different definitions of what a successful day looks like.
IT teams — network administrators, security engineers, sysadmins — think in terms of patch cycles, vulnerability scores, access controls, and incident response. Downtime is a metric to minimize. Security is a core mandate.
OT teams — control engineers, machine operators, process specialists — think in terms of uptime, process stability, and safety. A proposed security change that requires a system restart is a production risk, not a routine maintenance window. Security is important, but it competes directly with availability.
That tension is real and it matters. Security decisions made by IT teams without OT input routinely create operational risk. A patch deployed on a SCADA server without validating it against the production configuration can disrupt a running process. A firewall rule that blocks a legitimate OT protocol brings down a production line.
The IT/OT security problem isn’t just technical. It’s organizational. The teams responsible for securing industrial infrastructure don’t always speak the same language — and attackers know it. |
Bridging that gap requires security architecture that doesn’t depend on perfect coordination between teams. A hardware boundary that physically enforces data flow direction removes the organizational failure mode — it works regardless of whether the IT and OT teams are aligned on any given day.
Why Convergence Is Happening and What It Opens Up
For most of industrial history, IT and OT operated in separate silos. OT networks were air-gapped by default — physically disconnected from enterprise networks. That isolation wasn’t a designed security architecture. It was a byproduct of proprietary protocols and incompatible standards. But it worked as a de facto boundary.
Industry 4.0 and IIoT have dismantled that boundary. The business case is legitimate: real-time production data in enterprise analytics, predictive maintenance cutting unplanned downtime, remote monitoring reducing on-site headcount. Every one of those use cases requires a data path between OT and IT.
The cloud layer adds a third tier
Cloud adoption has extended the architecture further. Platforms like Azure IoT Hub, AWS IoT Greengrass, and cloud-hosted historians now sit between OT data sources and enterprise analytics. An edge gateway collects data from PLCs and SCADA systems, normalizes it, and pushes it to a cloud endpoint.
Each layer introduces a new attack surface. The edge gateway runs software that needs patching. The cloud connection requires credentials that can be compromised. An attacker who compromises the cloud environment, or the credentials connecting it to the OT edge, has a path that didn’t exist in the air-gap era — and if the gateway is bidirectional, that path runs both ways.
Every data path created for operational efficiency is also a potential attack path. That’s not a reason not to connect. It’s a reason to be precise about how. |
The Asset Visibility Problem
Before any security architecture can be designed, operators need to know what’s on the network. That sounds obvious. In practice, most OT environments don’t have a complete, accurate asset inventory. Equipment is added over decades, vendors connect devices for maintenance without documenting them, legacy systems run protocols that passive scanning tools don’t recognize.
An attacker doesn’t need your inventory list. They can enumerate assets themselves using the same unauthenticated protocols your devices respond to. Modbus, DNP3 and Profibus respond to any query on the segment — no credential required, no log entry generated. A full topology map of a poorly segmented OT network takes minutes.
Asset visibility matters for another reason: you can’t patch what you don’t know you have. Hardware segmentation at the network boundary limits the blast radius of unknown assets — an attacker who reaches the IT network still can’t enumerate the OT segment if there’s no return channel through the boundary.
Why IT Security Controls Don’t Transfer to OT
The standard IT security stack — firewalls, EDR, SIEM, patch management, MFA — was engineered for IT constraints. Applied to OT, each component hits assumptions that don’t hold.
Firewalls are software. Software can be misconfigured.
A firewall enforces a policy. Policies can be misconfigured, exploited, or bypassed. In 2024, threat actors exploited vulnerabilities in Ivanti, Palo Alto Networks, and Fortinet firewalls to achieve initial access. The firewall that was supposed to enforce the IT/OT boundary became the entry point. Zero-days in firewall firmware are a documented and recurring attack vector, not an edge case.
A hardware data diode has no configuration to compromise. The directionality is a physical constraint — optical components that transmit in one direction only. There is no firmware exploit that creates a return channel.
You can’t patch OT the way you patch IT
IT patch cycles run weekly to monthly. OT patching is constrained by operational continuity requirements, vendor support timelines, and validation processes. A PLC running firmware from 2012 may be on a production line that cannot be stopped for a controlled update. The vendor may no longer support it. The patch may not have been validated against the production configuration.
An unpatched OT asset sitting behind a software-enforced boundary is an open position at that speed. Network-level isolation is a more reliable control than patch management for legacy OT assets — because it doesn’t require the asset to be patched.
OT protocols weren’t built for hostile networks
Modbus, DNP3, Profibus, and IEC 61850 were designed for determinism and reliability in physically isolated networks. Authentication was not part of the brief. A device speaking Modbus responds to any poll from any host on the same segment — no credential required, no log entry generated. Behavioral anomaly detection can flag unusual traffic after the fact. Hardware segmentation removes the return channel before the query can be answered.
What a Secure IT/OT Architecture Actually Looks Like
The answer to convergence risk isn’t to stop converging. The answer is to architect the boundary so data flows in the direction the business needs, while attack paths cannot exist in the direction the business doesn’t need.
Unidirectional data flow as the baseline
In most IT/OT data flows, the direction the business needs is OT to IT: historian replication, SCADA alarm exports, security event forwarding to the SOC SIEM, production data for analytics. The business doesn’t generally need IT systems sending unsolicited commands to OT devices in real time. That asymmetry makes a unidirectional architecture both operationally viable and architecturally correct.
A hardware data diode enforces that asymmetry physically. Data flows from OT to IT. No inbound path exists at the hardware level. An attacker with full control of the enterprise network cannot reach the DCS, the SIS, or the historian — because there is no return channel for any protocol to establish a session across.
The Purdue Model, with hardware enforcement
The Purdue Enterprise Reference Architecture defines logical zones for OT: field devices at Level 0–1, control systems at Level 2, supervisory systems at Level 3, enterprise systems at Level 4–5. The model has been the reference architecture for thirty years. The problem is that its zone boundaries are logical, not physical. A firewall at Level 3.5 is a software policy. Software policies can be exploited.
Hardware data diodes deployed at Level 3.5 convert the logical zone boundary into a physical constraint. The DMZ becomes a one-way valve. The historian replicates outbound. The SOC receives security events. Nothing reaches inbound through the boundary that the hardware doesn’t permit by design.
When IT does need to send to OT
Some workflows require IT-to-OT flows: firmware updates, recipe synchronization, configuration pushes. A strict one-way architecture can’t accommodate these. A 1.5-way architecture using paired unidirectional gateways handles them through asynchronous, file-based, hardware-enforced transfers. Each transfer is discrete and logged. There is no persistent session an attacker can maintain across the boundary.
What the Standards Say
IEC 62443, the international standard for industrial control system security, defines zones and conduits as the model for OT network architecture. Its highest security levels recognize unidirectional security gateways as a compliant control for enforcing zone separation. NIS2, now transposed into national law across EU member states, mandates risk-appropriate technical controls for operators of essential services — energy, water, transport, manufacturing. NERC CIP, applicable to North American power sector operators, identifies unidirectional gateways as a compliant mechanism for crossing Electronic Security Perimeters.
The frameworks were developed independently. They converge on the same architecture.
FAQ - IT vs OT
What is the main difference between IT and OT security?
IT security prioritizes confidentiality — keeping data from unauthorized access. OT security prioritizes availability and physical safety — keeping industrial processes running without interruption. These different priorities lead to different patch cycles, different authentication models, different tolerance for downtime, and ultimately different security architectures. Controls designed for IT constraints create problems when applied unchanged to OT environments.
Why can't IT and OT teams just work together on security?
They can — and should. But organizational alignment doesn’t replace architectural enforcement. IT and OT teams have different priorities that create real tension: a security patch that requires a restart is acceptable to an IT team and unacceptable to an OT operator mid-production run. A hardware boundary that physically enforces data flow direction works regardless of whether the teams are aligned on any given day.
Why are OT systems harder to patch than IT systems?
OT devices run industrial processes that cannot be stopped for routine maintenance. A PLC controlling a chemical process cannot be taken offline for a firmware update without coordinating a full process shutdown. Many OT devices run firmware that vendors no longer support, and any modification requires validation against the production configuration. OT assets routinely run vulnerable software for years — making network-level isolation a more reliable control than patch management.
What is IT/OT convergence and why does it create security risk?
IT/OT convergence refers to the integration of enterprise IT systems — networks, cloud platforms, analytics — with operational technology — PLCs, SCADA, DCS. The integration enables real-time production visibility, predictive maintenance, and remote operations. The security risk is that every data path created for operational purposes is also a potential attack path. If the boundary isn’t enforced at the hardware level, a compromise of the IT network can become a path to the OT environment.
Can a firewall adequately protect an OT network?
A firewall enforces a policy. Policies can be misconfigured, exploited, or bypassed. Multiple major firewall vendors had critical vulnerabilities used for initial access in 2024. OT networks contain legacy devices running unauthenticated protocols on firmware that can’t be patched. A firewall reduces the attack surface. A hardware data diode removes the inbound attack path at the physical layer — with no software equivalent and no configuration to compromise.
What is a hardware data diode and how does it fit in IT/OT architecture?
A hardware data diode enforces one-way communication at the physical layer using optical components. Data flows in one direction — typically OT to IT — and the hardware architecture makes a return channel physically impossible. Deployed at the IT/OT boundary, it allows historian replication, alarm exports, and security event forwarding to reach enterprise systems, while no inbound path exists for an attacker who has compromised the IT network.
