What is an industrial data diode?
A practical explanation of one-way network communication, where it fits in OT architecture and what it can—and cannot—protect.
A physical one-way security boundary
An industrial data diode is a security device that allows information to move in only one direction between two networks. In a typical deployment, data leaves a trusted operational technology network and reaches an IT, analytics or monitoring environment, while network traffic cannot travel back into OT.
The defining property is not a firewall rule. A true data diode uses separate transmit and receive components—commonly an optical link with no return path—so the direction of communication is enforced by hardware. Even if software is misconfigured or compromised, the physical channel still cannot carry packets in the reverse direction.
- Hardware-enforced unidirectional communication
- Separate OT-side and IT-side systems
- No routable return path from IT to OT
How useful industrial data crosses the diode
Industrial applications normally expect two-way protocols, acknowledgements and sessions. Middleware on each side of the boundary therefore terminates the source protocol, transfers an approved representation of the data across the one-way link and reconstructs delivery to the destination.
This architecture can move OPC UA values, Modbus data, historian records, files, events or database updates without exposing the source system to an inbound session. Buffering, store-and-forward delivery, mapping and health monitoring are important because the receiver cannot acknowledge across the physical boundary.
- Collect data close to the source
- Normalize and buffer records
- Transmit an approved one-way stream
- Deliver to IT destinations using a new session
Where data diodes are used
Data diodes are used where the consequence of an inbound connection is unacceptable or where policy requires deterministic separation. Common environments include energy, water, manufacturing, transport, defence and critical infrastructure.
Typical use cases include exporting historian data, feeding a SOC or SIEM, moving production metrics to enterprise systems and publishing selected files or events to a higher network level.
- OT-to-IT historian replication
- Security monitoring and log export
- Production reporting and analytics
- Controlled transfer across segmented network levels
What a data diode does not replace
A diode is not a complete cybersecurity programme. It does not secure vulnerable devices inside OT, validate every value or replace identity, patching, monitoring and incident response. It also cannot support workflows that genuinely require commands or acknowledgements to return across the same boundary.
The correct question is whether a specific information flow can be made one-way. If it can, a hardware-enforced boundary removes an entire class of inbound network risk. If it cannot, a carefully controlled bidirectional architecture may be more appropriate.
Where a data diode sits in an industrial network
The diagram shows a common outbound-data pattern. Control equipment remains in Levels 0–3. Diodos is placed at the security boundary so approved operational data can move toward enterprise systems while no network path returns from IT to OT.
Diodos collects approved values from historians, OPC UA servers or other Level 3 sources without exposing them directly to IT.
The hardware link transmits toward IT and has no physical network receive path back into the operational environment.
A separate service creates new sessions to enterprise historians, databases, APIs, analytics platforms or the SOC.
Inside a typical industrial data diode architecture
A production implementation normally contains more than the optical one-way link. On the OT side, a collector connects to approved industrial sources and terminates protocols that expect a normal bidirectional session. It validates, maps and buffers the selected data before handing records to the unidirectional transport. The physical link carries only the outbound representation.
On the IT side, a separate service receives that representation and starts a new connection to the enterprise destination. The IT database, historian, broker or API never opens a session to the original OT source. This separation is what allows normal applications on both sides to work around a boundary that cannot return acknowledgements.
Each component has a distinct responsibility. The collector protects source systems from repeated queries, the buffer absorbs outages, the hardware enforces direction and the destination service adapts the data to the format expected by IT.
How bidirectional industrial protocols work across a one-way link
OPC UA, database connections, MQTT and most file-transfer protocols use acknowledgements or session state. They cannot simply pass through a data diode unchanged. A proxy or middleware layer must terminate the protocol on one side and create a different session on the other.
For OPC UA, the OT collector can subscribe to selected tags, preserve timestamps and quality values, then send normalized records across the diode. The IT service writes those records to SQL, a historian, MQTT or an API. For files, the OT side can detect a completed file, calculate integrity metadata, queue it and transmit it as controlled blocks for reconstruction in IT.
- OPC UA and Modbus: collect approved values inside OT and deliver normalized records to IT.
- Historians and SQL: preserve source timestamps, quality and deterministic record identifiers.
- MQTT and APIs: publish through a new IT-side client rather than extending an OT session.
- Files and events: validate completeness, integrity and permitted destinations before transfer.
Design constraints and operational trade-offs
One-way communication is a strong security property, but it changes application behaviour. The OT side cannot receive a delivery acknowledgement from IT through the diode. Operators therefore need local queue monitoring, storage alarms and independent destination checks. If the destination remains unavailable longer than the configured retention period, the buffer can eventually fill.
Interactive remote access, command-and-control workflows and applications that require an immediate response cannot use the same one-way channel. These requirements should be removed, separated into a different controlled path or handled through an operational process with explicit approval.
Data validation also remains essential. A diode prevents reverse network traffic; it does not guarantee that every outbound measurement, file or message is correct or authorised. Source allow-lists, schema validation, rate limits and destination controls remain part of the security design.
Questions to ask before selecting a data diode
- Can the required business outcome operate with a strictly outbound data flow?
- Which industrial protocols, historians, files and enterprise destinations must be supported?
- How much data must be buffered during a destination or network outage?
- How are queue depth, last delivery, storage capacity and rejected records monitored?
- Does the implementation preserve timestamps, quality and record identity during replay?
- How are configuration, certificates, upgrades and support handled on each side?
- Can the vendor demonstrate the physical one-way property and recovery behaviour in a POC?
Frequently asked questions
Is a data diode the same as an air gap?
No. An air gap has no automated data path. A data diode provides a controlled automated path, but only in one direction.
Can a data diode transfer OPC UA data?
Yes, when middleware terminates OPC UA on the OT side and recreates the approved data delivery on the IT side.
Can attackers send commands back through it?
A true hardware-enforced diode has no physical receive path in the reverse direction, so network commands cannot return through that channel.
Apply the architecture to a real industrial data flow.
Start with one source, one destination and a measurable security or operations objective.