When a firewall sits at the boundary between your IT network and your OT environment, you’re trusting a policy. A set of rules, written by humans, maintained over time, running on software that has a CVE history like everything else.
That trust has a failure mode. Hardware doesn’t. To understand why, it helps to step back and look at how industrial cybersecurity has evolved and why the threat landscape has made architecture choices more consequential than ever.
This article compares data diodes and firewalls on the criteria that actually matter for OT security: how each technology enforces protection, where each one breaks down, and which architecture makes sense depending on what you’re protecting.
How a Firewall Actually Works
A firewall is a policy engine. It inspects network traffic and makes decisions based on configured rules, source address, destination port, protocol type, packet content. Traffic that matches an allow rule passes. Everything else is blocked.
Modern next-generation firewalls add layers on top: deep packet inspection, application-layer filtering, intrusion prevention, threat intelligence feeds. For OT environments, industrial firewalls extend this with protocol-aware filtering for Modbus, DNP3, OPC-UA, and other field-level communications.
The security guarantee a firewall provides is: « traffic that matches our rules for malicious behavior will be blocked. »
That guarantee has three structural weaknesses.
Rules can be wrong. A misconfigured rule leaves a gap. A rule that was correct last year may not be correct after a network change. Complex rule sets accumulate over years and become difficult to audit.
The return channel exists. A firewall permits bidirectional communication, controlled, filtered, but bidirectional. As long as a return channel exists at the network level, an attacker who finds a way through has a path back.
How a Data Diode (Unidirectional) Actually Works
A data diode enforces one-way communication at the physical layer using optical components. A fiber optic transmitter sends light from the OT network toward the IT network. On the receive side, there is no transmitter, physically, not by configuration.
Light travels in one direction. There is no return path because there is no hardware capable of creating one.
This is not a software rule. It’s not a policy that can be misconfigured. It’s not a firmware version that needs patching. The directionality is a consequence of the physical architecture and that architecture doesn’t have a CVE history.
The proxy software layers on each side handle protocol adaptation: the OT-side proxy receives data from PLCs, historians, and SCADA systems, and forwards it across the optical link. The IT-side proxy reconstructs it for enterprise consumption. The optical layer between them has no attack surface.
The Comparison
| Data Diode | Firewall | |
| Enforcement mechanism | Hardware / physical | Software / policy |
| Data flow | Strictly one-way | Bidirectional |
| Return channel | Physically impossible | Exists, filtered |
| Misconfiguration risk | None | High |
| Zero-day vulnerability surface | None | Firmware + software stack |
| Patch requirements | Minimal | Regular, ongoing |
| Protocol support | OT protocols via proxy software | Native, with OT-specific models |
| Remote access support | No | Yes |
| Compliance verifiability | Physical, deterministic | Policy-based, requires audit |
| Failure mode | No connection | Depends on failure type |
Where Firewalls Fail in OT Environments
The documented failure modes of firewalls in OT contexts are not theoretical.
Zero-days in the perimeter device. The 2024 ArcaneDoor campaign, attributed to a state-sponsored actor by Cisco Talos, exploited vulnerabilities in Cisco ASA and FTD devices to gain access to government and critical infrastructure networks. The firewall enforcing the boundary was the vulnerability. Fortinet FortiOS (CVE-2024-21762) and Ivanti Connect Secure were also exploited in documented 2024 campaigns all tracked in CISA’s Known Exploited Vulnerabilities catalog.
Misconfiguration at scale. Firewall rule sets in industrial environments accumulate over years. Rules are added for specific operational needs and rarely removed. The result is a policy that no single person fully understands, with gaps that only become visible after an incident.
The return channel problem. A firewall permits bidirectional traffic, filtered, but bidirectional. The deeper issue is that IT and OT networks operate on fundamentally different security assumptions. An attacker who compromises a system on the IT side of a firewall has a network path that exists toward the OT segment. The firewall decides whether to allow or block each connection attempt. Zero-days, misconfigured rules, or compromised credentials can each unlock that path.
OT protocols with no authentication. Modbus, DNP3, and Profibus respond to any valid-looking query on the segment. A firewall can filter by protocol type, but it cannot authenticate the intent of a query that looks legitimate. An attacker who has reached the IT side of the boundary can craft protocol-compliant queries that pass firewall inspection.
What Data Diodes Can’t Do
Honesty matters here.
True Data diodes don’t support bidirectional communication. Workflows that require IT-to-OT flows can’t use a strict one-way architecture without additional design. A paired unidirectional gateway architecture, using two hardware data diodes on separate asynchronous paths, addresses this for specific controlled workflows. But it adds complexity.
Data diodes don’t replace all firewall functions. Within IT network segments, between corporate zones, or anywhere bidirectional communication is genuinely required, firewalls remain the appropriate tool. The argument isn’t that firewalls are useless, it’s that, let alone, they become the wrong tool at the IT/OT boundary for critical infrastructures, where the consequence of failure is physical.
Initial deployment requires more design work. Protocol proxy configuration, integration with existing historian and SCADA architectures, and traffic flow planning require upfront investment. Once deployed, maintenance is minimal but the design phase matters.
The Architecture That Makes Sense
The question isn’t « data diode or firewall. » It’s « which tool at which boundary. »
Firewalls belong in IT networks, between corporate zones, and anywhere that bidirectional communication and remote access are genuine operational requirements. They’re flexible, widely understood, and appropriate for environments where the consequence of a breach is data loss rather than physical disruption.
At the IT/OT boundary, for critical infrastructures, the calculus changes.
The OT network contains systems that control physical processes. The consequence of a breach isn’t data loss only anymore, it’s an uncontrolled process, a safety system disabled, a production line halted. In this context, a policy-based defense with a known failure mode is the wrong architecture.
A hardware data diode deployed at the IT/OT boundary allows the data flows the business needs, the OT historian (process data historians such as AVEVA PI System, AspenTech IP.21, or Honeywell Uniformance) replicating outbound, SCADA alarms forwarding to the SOC SIEM, security events reaching enterprise analytics while making an inbound attack path physically impossible.
An attacker with full control of the enterprise network still cannot reach the DCS, the SIS, or the historian, because there is no return channel for any protocol to establish a session across. For more on how this boundary fits within the broader OT network architecture.
Compliance and Regulatory Alignment
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, SL3 and SL4 recognize unidirectional security gateways as a compliant control for enforcing zone separation. Firewalls satisfy lower security levels; hardware-enforced unidirectional gateways satisfy the highest.
NERC CIP, applicable to Bulk Electric System operators in North America, identifies unidirectional gateways as a compliant mechanism for crossing Electronic Security Perimeters. The standard explicitly recognizes the difference between software-based and hardware-enforced boundary protection.
NIS2, now transposed into national law across EU member states, mandates risk-appropriate technical controls for operators of essential services. For high-risk OT environments, risk-appropriate means deterministic, not policy-based.
The frameworks converge: hardware enforcement satisfies higher security levels than firewall-based approaches across all three.
Frequently Asked Questions
What is the main difference between a data diode and a firewall?
A firewall filters bidirectional traffic based on software rules. A data diode enforces one-way communication at the physical layer using optical hardware. A firewall’s security depends on correct configuration and up-to-date software. A data diode’s security depends on physics.
Can a data diode replace a firewall?
At the IT/OT boundary in high-security OT environments, yes a true unidirectionnal data diode provides stronger protection than a firewall for the specific purpose of preventing inbound access to OT systems. In IT networks and anywhere bidirectional communication is required, firewalls remain appropriate. The two tools serve different purposes at different boundaries.
Are data diodes vulnerable to zero-day exploits?
Yes, the hardware optical layer has no software attack surface and no CVE history. The proxy software layers on each side can theoretically have vulnerabilities, but an exploit in the proxy software cannot create a return channel through the optical hardware. The physical constraint holds regardless of software state.
What happens if a data diode fails?
The failure mode of a data diode is no connection; the link drops, data stops flowing, but no inbound path is created. A firewall failure mode can range from blocking all traffic to failing open, depending on configuration. For OT environments, a fail-closed behavior is the safer default.
Do data diodes support OT protocols like Modbus and OPC-UA?
Yes, through protocol proxy software on each side of the optical link. The proxy receives protocol-native traffic from OT systems, transmits it across the one-way hardware link, and reconstructs it on the IT side. The optical layer is protocol-agnostic, support depends on the proxy software layer, not the hardware.
Which compliance frameworks recognize data diodes?
IEC 62443 SL3/SL4, NERC CIP, and NIS2 all recognize hardware-enforced unidirectional gateways as compliant controls for high-security OT boundary protection. IEC 62443 explicitly distinguishes between security levels achievable with firewalls versus unidirectional gateways.
