Data diodes and cross-domain transfer: one-way security architecture

Moving a file from a Secret network to an unclassified one sounds trivial until you consider what must not move with it. The text the analyst intends to release may be clean, but the file carrying it can smuggle classified content in metadata, embedded objects, revision history, or the unparsed tail of a binary format. A firewall cannot solve this, because a firewall trusts its own configuration and its own software stack – both of which can be subverted. The defensible answer is to make the unwanted direction of flow a physical impossibility, and then to inspect what is allowed to flow in the permitted direction. That is the domain of the data diode and the cross-domain solution.

Why direction must be enforced in hardware

A data diode enforces one-way data flow as a property of physics rather than of software. The classic implementation is an optical link with a transmitter on the source side and a receiver on the destination side, and deliberately no transmitter on the destination and no receiver on the source. Photons travel from high to low (or low to high, depending on the design); there is simply no optical path for anything to travel back. Because the unidirectionality is built into the wiring, it cannot be turned off by a configuration error, a firmware exploit, or a malicious insider with administrative access to either host.

This is the crucial distinction from a firewall. A firewall is a bidirectional device configured to behave as though it were unidirectional. Its enforcement depends on rule sets, on the integrity of its operating system, and on the assumption that no rule was added in error. A data diode removes those assumptions: even a fully compromised host on the destination side cannot exfiltrate data back across the boundary, because there is no channel for it to use. For protecting a high-classification enclave from any inbound connection, or for guaranteeing that a sensitive network can receive updates without ever being reachable, this physical guarantee is what makes accreditation possible.

What a diode does not solve

Direction is not the same as content. A one-way export link from a Secret network to an unclassified one will carry classified content just as faithfully as it carries releasable content – it has no idea which is which. If an analyst exports a presentation that contains a hidden slide, embedded source data, or speaker notes left in the file, the diode dutifully transmits all of it. The diode answers only the question "can data move back?" The separate and harder question – "should this specific object be allowed to move at all?" – belongs to the cross-domain solution layered on top.

From data diode to cross-domain solution

A cross-domain solution (CDS) is a complete, accredited system for controlled information transfer between security domains. Transfer-only CDS designs move data without giving either side interactive access to the other; access CDS designs let a single workstation reach multiple domains through a controlled boundary. This article concerns the transfer case, which is where data diodes are most commonly used as the enforcement core.

A transfer CDS has three layers. The first is the physical enforcement layer – usually one or more data diodes – that fixes the permitted direction. The second is the transport layer, the proxy software that makes reliable delivery possible across a link that has no return channel. The third is the inspection layer, the transfer guard that decides, object by object, what is permitted to cross. The combination of these three, plus an audit regime and a documented concept of operations, is what an accreditation authority evaluates. The relationship between direction control and content control is examined in more depth in our companion article on cross-domain solutions for defense.

Making reliable transport work without a return channel

Most useful protocols – TCP above all – assume a return channel for acknowledgements, retransmission, and flow control. A true data diode has none. The standard solution is a pair of proxies, one on each side of the diode. The send-side proxy terminates the application's TCP session locally, acknowledges receipt to the source as though it were the destination, and then serialises the payload into a unidirectional stream. That stream is carried across the diode using a protocol built for one-way delivery, with forward error correction (FEC) instead of retransmission: redundant data is added so the receiver can reconstruct lost packets without ever asking for them again.

The receive-side proxy reconstructs the payload, verifies its integrity, and opens a fresh TCP session to the real destination. From the application's point of view, an ordinary file transfer or message delivery has taken place. From the security architect's point of view, no acknowledgement, no handshake, and no timing-modulated signal has crossed the physical boundary. Throughput and reliability are tuned by adjusting FEC redundancy and segment size to the measured error rate of the link, trading bandwidth for resilience rather than relying on a back-channel that does not exist.

The transfer guard: inspection and release control

The transfer guard is the intelligence of a cross-domain solution. It sits in the data path and applies a release policy to every object before it is allowed to cross. The guiding principle is whitelisting, not blacklisting: rather than trying to enumerate everything dangerous, the guard permits only data that conforms exactly to a known-good specification and rejects everything else. Several techniques work together.

Structural validation. Each file is parsed against a strict schema for its declared type. A document that claims to be a simple text-bearing format but contains embedded macros, external references, or unexpected binary regions fails validation. The guard does not attempt to clean such a file; it rejects it, because attempting to repair adversarial input is itself an attack surface.

Metadata stripping and canonicalisation. Complex formats are transformed into the simplest faithful representation – for example, rendering a rich document to a flat, regenerated format that cannot carry the hidden objects of the original. Author names, edit history, geolocation tags, and other metadata are removed. Canonicalisation collapses the many ways a format can encode the same visible content down to one, eliminating the variation that steganography and covert channels exploit.

Content matching and human review. Dirty-word lists, regular-expression patterns, and classification-marking detectors flag text that should never appear on the destination side. For high-to-low export – the dangerous direction – flagged objects are routed to a human reviewer who makes the final release decision. Automated inspection narrows the volume a reviewer must handle; it does not replace the reviewer for the highest-risk transfers.

Import versus export: asymmetric risk

The two directions of cross-domain transfer carry very different risk. Import – moving data from a lower network up to a higher one – is primarily a malware-injection and integrity problem. The destination is the more sensitive side, so the concern is that the incoming data could carry an exploit or corrupt the high enclave. The transfer guard on an import path focuses on format validation, malware scanning, and rejecting anything executable or actively interpreted.

Export – moving data from a higher network down to a lower one – is the direction that can leak classified information, and it is therefore the harder problem. Here the guard's job is confidentiality: ensure nothing classified rides along in metadata, hidden objects, or covert channels, and that classification markings are present and consistent. Because the consequence of an export failure is disclosure rather than infection, export paths typically demand stricter format whitelists, mandatory human review of flagged content, and the most conservative canonicalisation. A common architecture uses two physically separate diodes – one for each direction – so that the import and export policies, and their failure modes, never share a path.

Where diodes fit in a layered architecture

Data diodes rarely stand alone. They are one control in a defence-in-depth design that also includes network segmentation, strong authentication, and continuous monitoring. A diode protecting a sensitive enclave complements rather than replaces the zero-trust controls inside that enclave; the diode governs the boundary, while identity-based verification governs every request within it – the subject of our article on zero-trust architecture for military networks. Diodes also pair naturally with isolated deployments: an air-gapped system that must still receive software updates or threat intelligence can use an import diode to take in data without ever exposing a return path, a pattern discussed in air-gapped deployments for defense software.

Operational realities

A cross-domain solution is an operational commitment, not a one-time install. Reject rates must be monitored, because a guard that rejects too much trains users to find unsanctioned workarounds – the most dangerous failure mode of all. Queue depth and latency must be tracked so that legitimate, time-sensitive transfers are not starved. Every format the guard accepts is an attack surface that must be re-validated whenever the parser, the rule set, or the underlying software changes. And every transfer decision must be logged to immutable storage so that, after the fact, an auditor can reconstruct exactly what crossed the boundary and why it was permitted.

Format governance is the part most often underestimated. The temptation in any operational deployment is to keep adding accepted formats – a new image type here, a richer document format there – until the whitelist quietly becomes a blacklist by attrition. Each addition expands the parsing surface the guard must trust, and a complex parser handling adversarial input is exactly where cross-domain solutions historically fail. The disciplined practice is to keep the accepted-format set as small as the mission tolerates, prefer simple structured formats over rich ones, and treat any request to add a format as a change that triggers re-evaluation rather than a configuration tweak. Where a rich format is genuinely required, the safer route is to render it to a flat, regenerated representation on the trusted side and transfer only that, rather than allowing the original structure across the boundary at all.

The human dimension matters just as much as the technical one. The reviewers who adjudicate flagged export objects need training, clear release criteria, and tooling that presents the object in a way that surfaces hidden content rather than concealing it. A review process that shows a reviewer only the rendered surface of a document, while the guard quietly passes the metadata beneath it, gives a false sense of assurance. The strongest deployments instrument the review step itself – measuring how long reviews take, how often reviewers override automated flags, and whether override patterns drift over time – so that the controlled-release decision remains a deliberate human judgement rather than a rubber stamp.

Accreditation and authorisation

No cross-domain solution connects classified networks without formal accreditation. In US national-security environments the National Cross Domain Strategy and Management Office (NCDSMO) maintains a baseline of evaluated products and the Raise-the-Bar design requirements, and a new or modified CDS undergoes a lab-based security assessment followed by a formal authorisation-to-operate decision. NATO and national programmes apply analogous regimes that reference Common Criteria evaluation and national security-accreditation authorities. Crucially, accreditation covers the whole concept of operations – the data formats allowed, the inspection rules, the audit design, and the human-review process – not merely the device. A diode is a component; an accredited CDS is a system with documented behaviour, and it is the system, not the box, that an authority signs off.