Guide

The Read-Only Data Pipeline

Configuring a Unidirectional Data Architecture

How to use hardware-enforced unidirectional data flow to protect safety-critical OT systems while feeding enterprise analytics — without relying on firewall rules that can be misconfigured or compromised.

Before you start — what you need

A defined protected zone (OT or safety network) and consuming zone (enterprise network or cloud)
A unidirectional security gateway: Waterfall Security Solutions or Owl Cyber Defense (see architectural differences below)
A data source in the protected zone: OT historian, OPC server, or Modbus device
A receiving system in the consuming zone: replica historian, analytics platform, or MQTT broker
Network documentation for both zones: IP addressing, VLAN topology, firewall rules
A hardware-based GPS/GNSS time source for the protected zone (see Step 5)

Two architectures, not one

The two primary vendors in this space use different approaches at the hardware level, which affects how agents and replication are configured:

Owl Cyber Defense — Layer 1 diode

Pure physical layer separation using photodiode or fiber transceiver modification. Creates a hardware-enforced one-way path at the optical level. The data stream crosses as raw packets; vendor agents on each side handle protocol translation.

Waterfall Security — Application gateway

Operates at the application layer. A specialized hardware appliance natively replicates historians or databases, presenting a pre-replicated copy to the consuming network rather than passing raw packet streams. Integration is at the data model level, not the network packet level.

The problem this solves

The standard IIoT architecture connects the OT network to the enterprise network through a firewall. The firewall enforces rules about what traffic is allowed in each direction. The problem is that a firewall is software — software has vulnerabilities, rules get misconfigured, and credentials get compromised. In the 2021 Oldsmar water treatment facility attack, the attacker accessed a SCADA system through a remote access tool that was legitimately installed. The firewall allowed the connection because the traffic looked authorized.

A unidirectional security gateway solves this with physics rather than software. The OT network can push data to the enterprise network. Nothing in the enterprise network can reach back — not because a rule says so, but because there is no physical path for the signal to travel.

Why native protocols cannot cross a data diode

Critical architecture point

Protocols like OPC-UA, OPC-DA, Modbus TCP, and MQTT run over TCP/IP. TCP is inherently bidirectional: for every packet sent, the receiver must send an acknowledgment (ACK) packet back to verify delivery and manage flow control. Because a data diode physically eliminates the return fiber path, no ACK can ever return. A native OPC-UA or MQTT connection will fail instantly at the TCP handshake — the session cannot establish.

Data diodes therefore use a split-proxy architecture. The protected-side agent terminates the native TCP connection from the OT historian inside the protected zone, extracts the payload, and wraps it into a unidirectional transport — typically UDP or a proprietary protocol with forward error correction — for blind transmission across the diode. The consuming-side agent receives this stream, reconstructs the data, and creates a new standard TCP connection on the consuming network. The diode never passes a native industrial protocol. It passes a unidirectional stream that the vendor's agents reconstruct on the other side.

The split-proxy architecture

Unidirectional data pipeline — split-proxy architecture

Protected zone

OT Historian / OPC Server

PI Server, Ignition, OPC-UA server

TCP connection stays inside zone

↓

Protected-Side Proxy

Terminates TCP, extracts payload, wraps in UDP/FEC

UDP/FEC
stream out

No ACK
return

Hardware diode

Data Diode

Fiber TX only
No physical RX on protected side

FEC enabled to recover lost packets without retransmission

Reconstructed
stream out

Consuming zone

Consuming-Side Proxy

Receives UDP stream, reconstructs data, creates new TCP connection

↓

Enterprise Analytics

Replica historian, MQTT broker, cloud platform

Standard TCP — entirely new connection

Implementation steps

Step 1 Define the data scope

List every tag, historian point, and OPC node that needs to cross the boundary before configuring any hardware. Data not on this list stays in the protected zone. This list becomes the agent replication configuration and the basis for your change management process going forward.

Step 2 Install and configure the protected-side proxy agent

Install the vendor-supplied proxy agent on a host inside the protected zone. Configure it to connect to your OT historian or OPC server as a local TCP client — this bidirectional TCP connection stays entirely within the protected zone and does not cross the diode. The agent extracts tag data, wraps it into the vendor's unidirectional transport format, and transmits it to the diode's input port. Configure the polling rate, buffer size, and forward error correction settings per the vendor's capacity specifications for your tag count and polling frequency.

Step 3 Configure the diode hardware

Physical installation varies by vendor. Critical parameters: transmission rate matched to your data volume, buffer size set to handle your longest expected consuming-side outage, and forward error correction enabled. FEC sends redundant parity blocks alongside the data stream so the consuming agent can reconstruct corrupted packets without a retransmission request — which is not possible across a one-way link. Without FEC, corrupted packets are permanently lost with no upstream notification.

Step 4 Install and configure the consuming-side proxy agent

The consuming-side agent receives the unidirectional stream from the diode's output port, reconstructs the data, and writes it to the destination system using a new standard TCP connection on the consuming network. This connection is entirely separate from the protected-zone historian — the diode never bridged them at the protocol level. Configure the destination connection and verify data is arriving correctly before considering the pipeline operational.

Step 5 Configure time synchronization for the protected zone

Do not connect the protected zone to a network-based NTP server shared with the consuming zone. A shared NTP connection creates a bidirectional network path that circumvents the physical isolation the diode provides — and undermines the compliance argument the diode is intended to support.

The protected OT network requires an isolated time source. The standard approach is a GPS or GNSS-based hardware clock: a receiver antenna mounted externally, connected to a dedicated NTP server appliance inside the protected zone that serves time to OT devices without any external network dependency. Some diode vendors offer a specialized one-way NTP replication module that passes time packets outbound only — verify whether your vendor supports this before assuming it is available.

Step 6 Verify unidirectionality

After the system is operational, attempt to initiate a connection from the consuming zone to the protected zone through the diode. The attempt must fail at the hardware level. Document the test and its result. In regulated environments — NERC CIP, NIS2 — this verification is required for compliance evidence. Auditors will ask for it.

Where this breaks

Attempting to pass native TCP protocols directly across the diode

Configuring the agent to pass native OPC-UA or MQTT directly — rather than using the split-proxy architecture — results in immediate connection failures. The TCP handshake cannot complete without a return path. Use the vendor's proxy agents on both sides. Do not substitute generic protocol connectors.

Packet loss without notification

Because there is no return path, the protected side has no awareness of whether the consuming side is alive, crashed, or dropping packets. If the consuming agent crashes or the destination network drops packets, data is permanently lost at the gap without triggering any upstream error. Ensure FEC is enabled and correctly sized for your transmission rate. Monitor the consuming-side agent's receive statistics — not the protected-side transmit statistics — to detect loss.

NTP misconfiguration creating a back-channel

Connecting both zones to the same network-based NTP server creates a bidirectional network path that circumvents the diode. Use a dedicated GPS/GNSS hardware clock for the protected zone. Document the time source architecture in your compliance evidence — it will be reviewed.

Buffer overflow during consuming-side outages

When the consuming side is unavailable and the buffer fills, real-time data continues arriving while historical data replays on reconnect. Depending on the historian's handling of out-of-order timestamps, this produces gaps or duplicates in the replica dataset. Configure buffer size for your longest expected outage and verify the historian's back-fill behavior before go-live.

Tag list scope creep exceeding diode capacity

Every addition to the replication configuration increases transmission load. Establish a change management process. Review additions against diode capacity before committing. Uncontrolled growth is the most common cause of capacity ceiling problems in production unidirectional pipelines.

Related: the vendor index enforcement section covers Waterfall Security Solutions and Owl Cyber Defense. The pilot structure guide covers how to incorporate the InfoSec and network architecture constraints of a unidirectional deployment into a scalable pilot plan.