A firewall can be misconfigured, exploited or administered from the wrong side; a data diode physically cannot send a packet backwards. That property is why nuclear plants, defence networks and some electricity and water operators use hardware-enforced one-way links to get data out of critical networks without opening a path in. It also brings real costs: no remote write access, broken protocols that expect acknowledgements and a new way to move patches and files inwards. This guide explains how data diodes and unidirectional gateways work, where regulators require or prefer them, how to decide between a diode and a firewall, design patterns, operational pitfalls and how to measure that the design is holding. It is for OT architects, security engineers in regulated sectors and anyone writing requirements for an IT to OT boundary. For the wider OT context, see the OT Security Guide.
Key takeaways
- The guarantee is physical. NIST SP 800-53 control AC-4(7) calls for one-way flows enforced by hardware-based mechanisms, also known as data diodes or unidirectional gateways.
- Gateways make diodes usable. A bare diode carries only one-way signals; proxy software on each side replicates historians, files, logs and alarms across it.
- Use a diode when data only needs to leave and the consequence is severe. Choose a firewall with protocol inspection when the business genuinely needs two-way traffic.
- A diode is not a complete defence. NRC Regulatory Guide 5.71 Rev. 1 states that a data diode alone is not adequate protection; removable media, vendor access and supply chain still need controls.
- Plan the inward path first. Patches, antivirus signatures, recipe changes and time synchronisation still need to reach the protected network through a controlled, separate route.
What data diodes and unidirectional gateways are
- Data diode: a hardware device that can transmit in only one direction, typically by using an optical transmitter on one side and only a receiver on the other, so there is no physical return path. The direction does not depend on software configuration.
- Unidirectional gateway: a data diode plus proxy servers on each side. The sending proxy reads data on the protected (high) side, for example from a historian or OPC server, and the receiving proxy recreates it on the other (low) side as a replica server, file share, syslog stream or message queue. Users and applications on the low side query the replica, never the original.
- Why proxies are needed: protocols such as TCP need acknowledgements, which cannot cross a diode. The proxies terminate those protocols locally and send data across the diode with their own sequence numbering and error correction, so that losses can be detected.
- Cross domain solutions: in government and defence, a diode is often one component of a wider cross domain solution that also inspects and transforms content. The UK NCSC describes a cross domain solution as a combination of components within an architecture, not a single appliance.
- Variants: some products offer controlled reverse paths (a second diode in the opposite direction, or a reversible link switched on a schedule). These are not one-way systems any more and need to be assessed like any two-way connection.
Diode or firewall: making the choice
| Factor | Data diode or unidirectional gateway | Firewall with protocol inspection |
|---|---|---|
| Enforcement | Physics: no return path | Software rule set and firmware |
| Failure mode if misconfigured or exploited | Still cannot send inbound | Can allow inbound traffic |
| Supported flows | Outbound replication (historian, logs, alarms, files) or inbound import, not both on one link | Any protocol, both directions |
| Remote control and write access | Not possible through the link | Possible with rules and secure remote access |
| Protocol fit | Needs proxy support for each protocol; request and response protocols need replicas | Native |
| Administration | Low rule complexity; proxies still need patching and configuration | Ongoing rule reviews and change control |
| Assurance evidence | Simple to demonstrate; often certified | Depends on rule audits and configuration review |
| Cost | Higher per link, plus proxy servers | Lower; usually already present |
Choose a diode when: data only needs to leave the protected network; a successful inbound attack could cause safety, environmental or national-level consequences; a regulator requires or prefers hardware one-way flow; or you cannot staff rigorous firewall rule management at many remote sites. Choose a firewall when: operations need remote engineering, two-way integration (for example production orders down to MES), or protocols that the gateway cannot replicate, and the consequence profile allows it. Many sites use both: a diode for monitoring data and a separate, tightly controlled firewall path for the few two-way needs, each documented as a conduit. See the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide.
Where regulators and frameworks expect one-way flow
| Sector or framework | What it says | Practical effect |
|---|---|---|
| Nuclear power (US NRC RG 5.71 Rev. 1, February 2023) | Five concentric defensive levels; safety, important-to-safety and security critical digital assets sit in Level 4; only one-way data flow is allowed from Level 4 to Level 3 and from Level 3 to Level 2; hardware-enforced unidirectional communication is the preferred implementation | Diodes at the upper boundaries are the norm; lower to higher traffic is deny-all, permit by justified exception |
| Electricity (NERC CIP-005-7) | All External Routable Connectivity to an Electronic Security Perimeter must go through an identified Electronic Access Point with inbound and outbound permissions and deny by default; some requirements apply only to systems with External Routable Connectivity | Entities use unidirectional designs as part of how they scope connectivity; confirm the treatment of a specific design with your Regional Entity. See the NERC CIP Guide |
| Federal systems (NIST SP 800-53 Rev. 5) | AC-4(7) One-way Flow Mechanisms: enforce one-way flows through hardware-based mechanisms, for example preventing export from a higher impact domain while allowing import from a lower one | Selectable enhancement in tailored baselines and overlays |
| Government and defence (UK NCSC cross domain principles) | Thirteen principles including network protocol attack protection, content based attack protection, protection against unauthorised export and component integrity | A diode covers the protocol side; content checks and export controls are still needed |
| Industrial automation (IEC 62443-3-3) | System requirements for network segmentation and zone boundary protection | A diode is one way to meet a conduit's requirements for a high security level zone. See the IEC 62443 Guide |
For nuclear sites specifically, see the Nuclear Facility Cybersecurity Guide.
Design patterns
Export only (most OT deployments)
- Historian replication: the plant historian sends tag data to a replica historian in the OT DMZ or IT network. Business users, analytics and cloud connectors use the replica.
- Security monitoring export: syslog, Windows event forwarding, network sensor alerts and asset inventory data flow out to the SOC, which can see the plant but cannot touch it. See the OT Network Security Monitoring Guide.
- Alarms and notifications: SNMP traps, email or messaging alerts generated on the low side from replicated alarm data.
- File transfer out: production reports, quality data and backups copied to a low side share.
Import only (classified and high side networks)
- Low to high: in defence and government, diodes move data from a less trusted network into a more trusted one while preventing leakage back out, as the AC-4(7) guidance describes.
- Content controls are essential: the import path must check, sanitise or transform files, because a one-way link carries malware inwards as easily as clean data (NCSC principle 2, content based attack protection).
Separate inward maintenance path
An export diode means patches, antivirus signatures, firmware and configuration changes need another route. Typical options are a second, import-direction diode feeding a staging server with scanning and approval, or a controlled removable media kiosk process. Design this path at the same time as the diode, or staff will create informal workarounds such as USB sticks, which the NCSC explicitly warns about.
Operational realities
| Issue | Why it happens | How to handle it |
|---|---|---|
| Time synchronisation | NTP needs replies; the high side cannot receive time from IT | Local time source (for example GPS or PTP grandmaster) inside the protected network |
| Silent data loss | No acknowledgements back across the link | Gateway sequence numbers, error correction and gap reports on the low side; alert on gaps |
| Applications that query the source | Request and response protocols cannot cross | Replica servers on the low side; redesign integrations to read replicas |
| Vendor remote support | Suppliers expect remote access | Separate, brokered and approved remote access path, or on-site support. See the OT Remote Access Guide |
| Proxy server maintenance | Gateway proxies are servers that need patching | Patch the high side proxy through the inward path; harden both proxies |
| Throughput growth | More tags, logs and video over time | Monitor link utilisation; size for growth |
| Link health | A failed diode looks like a quiet plant | Heartbeat messages and alerts when expected data stops |
Where identity fits
A well-designed export gateway keeps credentials on the side they belong to. The high side proxy reads the historian or OPC server with a service account that exists only on the protected network; low side users authenticate only to the replica. That means no OT credential needs to be stored on the IT side and no IT account can log in to OT through the link. Keep it that way: give the high side proxy a read-only account scoped to the data being exported, manage proxy administrator accounts separately on each side, and do not join both proxies to the same directory. See the Identity for OT Environments Guide.
Implementing a one-way boundary
- Map the flows: list every connection crossing the boundary today, its direction, protocol, owner and business need. Many will turn out to be unnecessary.
- Classify: outbound only, inbound only, genuinely two-way. Challenge each two-way flow: can it be replaced by a replica, a scheduled file or an on-site process?
- Choose the technology per flow: diode or gateway for one-way flows, firewall with protocol inspection and secure remote access for the remaining two-way flows.
- Design the inward path: patch and signature import, configuration changes and emergency vendor access, with scanning and approvals.
- Test in parallel: run the gateway alongside the existing connection, compare replicated data with the source and check gap detection, then cut over one flow at a time.
- Remove the old paths: physically disconnect and decommission replaced firewall paths, and verify with a scan and cable audit that nothing else crosses the boundary.
- Keep a rollback for data, not for connectivity: if the gateway fails, operations should continue locally while data is buffered; avoid reinstating a two-way link as the emergency fallback.
Small and large operators: a single water or manufacturing site may only need one export gateway for historian and log data and a documented removable media process. Large utilities and nuclear operators typically run diodes at several levels, formal cross domain assurance and a dedicated import path.
Detection and measurement
- Monitor: gateway health and heartbeat, replication gaps, proxy server logs, any traffic seen on the high side network destined for the low side outside the gateway, and any new connection across the boundary found by network monitoring or cable audit.
- Review: inward path transfers, with who approved what and the scanning results.
- Number of boundary flows that are two-way, and the trend (target: falling).
- Percentage of outbound data flows carried over hardware one-way links.
- Replication gaps detected per month and median time to restore.
- Undocumented connections found crossing the boundary in audits (target zero).
- Inward transfers made outside the approved import process (target zero).
- Patch latency for gateway proxy servers on each side.
Lessons from incidents
When an operator cannot be sure how far IT and OT are connected, a ransomware attack on IT can stop operations even if controls are never touched. In the Colonial Pipeline ransomware attack, attackers entered through an unused VPN account, and the company proactively shut down its pipeline to limit the spread although operational technology was not reported as directly compromised. A documented boundary where the only path out of OT is a one-way link, and no path in exists, gives operators evidence to make that containment decision with more confidence. It does not remove the need to plan for IT outages that OT depends on, such as billing or scheduling.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | AC-4, AC-4(7), AC-4(21), SC-7(22), SC-46 | Information flow enforcement, one-way flow mechanisms, separation of flows, separate subnets for security domains, cross domain policy enforcement |
| NIST CSF 2.0 | PR.IR-01, PR.DS-02 | Protect networks from unauthorised access, protect data in transit |
| US NRC RG 5.71 Rev. 1 | Defensive architecture | One-way flow from Level 4 to 3 and 3 to 2, hardware enforcement preferred |
| NERC CIP-005-7 | R1 Parts 1.1 to 1.3 | Electronic Security Perimeter, Electronic Access Points, deny by default |
| IEC 62443-3-3 | SR 5.1, SR 5.2 | Network segmentation, zone boundary protection |
| MITRE ATT&CK for ICS | T0822, T0886, T0867 | External Remote Services, Remote Services, Lateral Tool Transfer: techniques an inbound path enables |
| MITRE D3FEND | D3-NI | Network Isolation |
Common failure patterns
- The diode next to a firewall: a one-way gateway is installed, but the old two-way firewall path stays for "just in case", so the guarantee is gone.
- No inward path designed: patches and signatures stop, or arrive on uncontrolled USB sticks.
- Treating the diode as the whole defence: removable media, vendor laptops and supply chain remain uncontrolled, contrary to the defence in depth expectation in RG 5.71.
- Unscanned import: a low to high diode carries malicious files inwards because no content checks were added.
- Reversible links left switched on: scheduled reverse windows become permanent.
- Nobody watching the link: replication stops for weeks and the SOC reads the silence as a quiet plant.
Practitioner checklist
- Inventory every flow across the OT boundary with direction, protocol and owner.
- Use hardware one-way links for outbound monitoring and historian data where consequences are severe.
- Keep two-way flows to a documented minimum through inspected firewall conduits.
- Design and control the inward path for patches, signatures and changes before go-live.
- Add content checks to any import-direction link.
- Provide a local time source on the protected side.
- Monitor gateway heartbeats and replication gaps, and alert when data stops.
- Remove superseded two-way connections and verify by scan and cable audit.
- Scope high side proxy accounts read-only and keep identities separate on each side.
- Confirm regulatory treatment (NERC CIP, NRC, cross domain assurance) with the relevant authority.
Standards and references
- NIST: SP 800-53 Rev. 5, AC-4(7) One-way Flow Mechanisms
- US NRC: Regulatory Guide 5.71 Rev. 1, Cybersecurity Programs for Nuclear Power Reactors
- NERC: CIP-005-7 Cyber Security, Electronic Security Perimeter(s)
- NCSC: Cross domain solutions principles
- ISA: ISA/IEC 62443 Series of Standards
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: OT Security Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · NERC CIP Guide · Nuclear Facility Cybersecurity Guide · OT Remote Access Guide