What is an OPC UA Data Diode? One-way networks explained

OPC UA is a bidirectional protocol. A client connects to a server, browses the address space, reads values, writes commands, subscribes to changes, and calls methods. This request/response model is what makes OPC UA so powerful for industrial automation.

But some environments don't allow bidirectional communication at all. Not because of policy — because of physics.

The problem: when two-way is a threat

In defense installations, nuclear power plants, classified networks, and critical infrastructure, a fundamental security principle applies: data may flow out of a secure zone, but nothing may flow back in.

The reasoning is simple. If an attacker can send a single packet into a secure network — even a malformed response to a legitimate request — they have a foothold. Firewalls help, but firewalls have bugs. Software has vulnerabilities. The only way to guarantee that no data flows back is to make it physically impossible.

This is the domain of the data diode: a hardware device that enforces strictly one-way communication at the physical layer. Typically, it's a fiber optic link with the receive fiber on the secure side physically cut or absent. No signal can travel in the reverse direction. No exploit can bypass a missing wire.

The challenge with OPC UA

Standard OPC UA Client/Server communication is inherently bidirectional:

1. The client sends a request ("read the value of temperature")
2. The server sends a response ("42.7°C, Good quality, timestamp 08:15:32")

Even subscriptions — where the server pushes data to the client — require an initial handshake, session establishment, and periodic keep-alive messages from the client. All of these require a return channel.

Put a data diode between an OPC UA client and server, and nothing works. The client sends a request, but the response can never come back.

The answer is in the last two rows.

The solution: OPC UA PubSub + Data Diode

OPC UA PubSub, defined in Part 14 of the specification, introduces a fundamentally different communication pattern. Instead of request/response, a publisher sends data to a transport (UDP multicast, MQTT, AMQP) without expecting any response. Subscribers receive the data — or they don't. The publisher doesn't know and doesn't care.

This "fire and forget" model is inherently one-way. And that makes it compatible with data diodes.

The architecture

Secure zone (high-security side):

An OPC UA server collects data from PLCs, sensors, and control systems. It also runs an OPC UA PubSub publisher that encodes selected data as PubSub messages — including full OPC UA semantics (types, units, timestamps, quality codes) — and sends them as UDP multicast packets.

Data diode (hardware):

The UDP packets cross the data diode in one direction only. The diode hardware handles the physical layer. Some advanced diodes include a protocol proxy that reconstructs UDP streams, handles packet loss, and provides forward error correction.

Monitoring zone (low-security side):

An OPC UA PubSub subscriber receives the UDP packets and reconstructs the OPC UA data. It can populate a local OPC UA server, feed a historian, drive a dashboard, or forward the data to cloud analytics. This side has no way to send anything back to the secure zone.

What crosses the diode

The PubSub messages carry the full OPC UA data model:

• DataSetMessages with field values, timestamps, and quality codes
• DataSetMetaData describing the structure (variable names, types, units)
• Publisher and Writer Group IDs for routing and filtering

The subscriber knows exactly what each value means — without ever connecting to the original OPC UA server. The metadata travels with the data.

Use cases

Defense and classified networks

Military installations and intelligence agencies operate networks at different classification levels (e.g., UNCLASSIFIED, SECRET, TOP SECRET). Data often needs to flow from a lower classification to a higher one (or from a control system to a monitoring network), but never in the reverse direction.

OPC UA PubSub over a data diode enables real-time monitoring of operational systems from a higher-classification network without creating a return path that could be exploited.

Nuclear and energy

Nuclear power plants operate under strict regulatory frameworks (e.g., NRC in the US, ASN in France) that mandate physical isolation of safety-critical control systems. However, plant operators still need to monitor these systems from the control room and from off-site engineering centers.

A data diode with OPC UA PubSub allows real-time telemetry from the safety system to the monitoring network — no return channel, no risk of remote manipulation.

Water, gas, and critical infrastructure

The EU's NIS2 directive and the Cyber Resilience Act impose strict cybersecurity requirements on operators of essential services. Data diodes are an accepted — and in some cases required — measure for isolating critical OT networks while still enabling monitoring and compliance reporting.

Industrial DMZ (Purdue Level 3.5)

Even in less extreme environments, the ISA/IEC 62443 model recommends a demilitarized zone (DMZ) between the OT and IT networks. A data diode at this boundary ensures that production data flows to the enterprise network for analytics, ERP, and MES — without exposing the OT network to threats from the IT side.

What you lose

One-way communication has trade-offs. Through a data diode, you cannot:

• Write to the OPC UA server. No remote setpoint changes, no commands.
• Browse the address space. The subscriber must rely on pre-configured metadata or the metadata embedded in PubSub messages.
• Call methods. No remote procedure calls across the diode.
• Get acknowledgments. The publisher doesn't know if the subscriber received the data. Forward error correction and redundant transmission mitigate this.
• Use Subscriptions. The Client/Server subscription model requires a return channel for keep-alive and republish. PubSub replaces this.

These limitations are by design. In environments that require data diodes, the inability to write back is not a bug — it's the entire point.

Implementation considerations

Protocol choice. UDP multicast is the cleanest fit for data diodes — pure one-way, no handshake. MQTT can work if the broker is on the sending side, but the subscriber still needs a TCP connection to the broker, which complicates the diode setup.

Packet loss. UDP over a data diode may experience packet loss, especially at high data rates. Mitigations include forward error correction (FEC), redundant publishers, and application-level retransmission on the publisher side (sending each message multiple times).

Metadata distribution. The subscriber needs to know the structure of the DataSet. OPC UA PubSub can embed metadata in the stream (MetaDataMessage), or you can pre-provision it out of band. The former is more robust for diode scenarios.

Security. Even though the diode prevents return traffic, you should still sign PubSub messages using OPC UA security. This prevents tampering on the low-security side and provides data integrity guarantees.

Key takeaways

1. Standard OPC UA Client/Server does not work through a data diode — it requires bidirectional communication.
2. OPC UA PubSub (Part 14) uses a fire-and-forget model that is inherently one-way and compatible with data diodes.
3. PubSub messages carry full OPC UA semantics — the subscriber gets typed, contextualized data without needing a return channel.
4. Data diodes are used in defense, nuclear, energy, and critical infrastructure to enforce physical one-way data flow.
5. The trade-off is clear: you get monitoring without control — which is exactly what these environments require.

Sterfive's Data Diode solution

This isn't theoretical. Sterfive has developed and deployed a working OPC UA Data Diode solution.

Our approach uses a dedicated Emitter component on the secure side. It connects to your existing OPC UA servers, selects the data to replicate, encodes it as compact encrypted datagrams with full OPC UA metadata, and transmits over UDP or TCP — ready to cross any hardware data diode.

On the monitoring side, a dedicated Receiver reconstructs the OPC UA address space as a fully browsable, local OPC UA server. Clients on the low-security side see a standard OPC UA server — they don't need to know that a data diode sits in between.

The solution handles:

• Automatic metadata replication — variable names, types, units, and structure cross the diode with the data.
• Configurable data selection — choose exactly which parts of the address space to replicate.
• Redundant transmission — each message is sent multiple times to mitigate UDP packet loss.
• AES-256-GCM encryption — data integrity and confidentiality across the diode.
• Hardware independence — works with any data diode hardware on the market (Advenica, Fox-IT, Waterfall Security, Owl Cyber Defense, OPSWAT, or simple fiber-optic enforcers).

If you're exploring data diode architectures for your OPC UA infrastructure, get in touch — we'd be happy to discuss your use case.

Download the whitepaper

This article covers the concepts. For the full technical deep-dive — architecture diagrams, configuration examples, hardware diode compatibility matrix, and deployment checklist — download our whitepaper.

References

1. OPC Foundation — OPC UA Part 14: PubSub. opcfoundation.org
2. IEC 62443 — Industrial communication networks – Network and system security. iec.ch
3. European Commission — NIS2 Directive. digital-strategy.ec.europa.eu
4. ANSSI (France) — Recommandations pour les architectures de systèmes industriels. cyber.gouv.fr
5. NIST — SP 800-82: Guide to ICS Security. nist.gov