Quantum safe encryption data diode: can it work one-way?

Quantum-safe encryption for a data diode means protecting data that leaves an OT network over a hardware-enforced one-way link with cryptography that a future quantum computer can’t break, even though the receiver can never reply. In practice that means key establishment and key rotation designed for a link with no return channel, because no interactive handshake is possible.

The diode itself only enforces direction. NIST defines a data diode as a network appliance or device that allows data to travel only in one direction, and NIST SP 800-82r3 lists unidirectional gateways among the ways to restrict logical access to the OT network. Neither definition says anything about confidentiality. This article explains how to add quantum-safe confidentiality and integrity without weakening the one-way guarantee.

Is data sent through a data diode at risk from harvest now, decrypt later?

Yes, whenever the diode’s output crosses a network an adversary can record, such as a carrier link, a shared WAN or the internet on the way to a remote SOC or cloud historian. The diode stops inbound attacks. It does nothing to stop someone from copying outbound traffic.

Harvest now, decrypt later is a passive risk: traffic captured today is stored until a cryptanalytically relevant quantum computer exists. A common misconception is that forward secrecy solves this. As one 2026 analysis puts it, forward secrecy does not protect an ECDH exchange against an adversary that can later solve the underlying elliptic-curve discrete-logarithm problem.

Not every diode flow is equally exposed. Routine operational data that loses its value quickly may present a lower harvest-now, decrypt-later risk. Per-second sensor values from a pump station are a different case from what else often rides the same link: historian exports showing years of process behaviour, network topology, safety-system configurations and maintenance records. Classify the content of each flow by how long it stays sensitive, not by the link it uses.

The policy timeline is now concrete:

• NIST will deprecate quantum-vulnerable public-key cryptography after 2030 and disallow its use under NIST standards and guidelines after 2035 (NIST IR 8547, October 2026).
• Executive Order 14412 accelerated this timeline, requiring federal high-value assets and high-impact systems to migrate by 2030 for key establishment and 2031 for digital signatures.

Dustin Moody of NIST summarised the purpose of the report this way: “We lay out how certain encryption algorithms people are using today will get phased out.” OT assets often stay in service for decades, so a diode installed today will very likely still be running after 2035.

Can ML-KEM key exchange work over a one-way data diode link?

Yes. ML-KEM is a key encapsulation mechanism, not an interactive protocol, so it can run in one direction as long as the sender already holds the receiver’s encapsulation key. The receiver only has to decapsulate. It never needs to transmit.

FIPS 203 was published and effective on August 13, 2024. Key generation produces both a public key (known as an encapsulation key in FIPS 203) and a private key (known as a decapsulation key). On a diode link the pattern works like this:

1. The receiving side (DMZ or cloud) generates an ML-KEM key pair. The encapsulation key is moved to the OT sender through a controlled, authenticated provisioning step, for example during commissioning.
2. For each key epoch, the sender runs encapsulation. That produces a fresh shared secret and a ciphertext.
3. The sender transmits the ciphertext over the diode with an epoch identifier. The receiver decapsulates it and derives the same session keys.

Message size matters on links with fixed frame sizes. ML-KEM-768 requires 1,184 bytes for public key and 1,088 bytes for ciphertext while RSA-2048 uses 256 bytes for both. Only the ciphertext crosses the diode, so the overhead per epoch is small. Still, a 1,088-byte object may need fragmentation on serial-style or small-MTU diode transports.

How do you encrypt traffic leaving a unidirectional gateway without a return channel?

You replace the handshake with three things: pre-provisioned trust, a key derivation that combines several secrets, and authenticated encryption on every packet. The sender has to do all of this alone, because it never gets an acknowledgement.

Combine secrets with an approved KDF

Use a hybrid derivation: a classical ephemeral-static elliptic-curve exchange, the ML-KEM shared secret and, optionally, a pre-shared key, all fed into one key derivation function. NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-Establishment Schemes) is the reference for building that derivation. The aim is that a classical algorithm and a PQC algorithm combined this way stay secure as long as at least one component holds. Include the epoch identifier, sender identity and direction label in the KDF context, so that keys can’t be swapped between flows.

Authenticate the sender, not just the data

A KEM on its own proves nothing about who encapsulated. Without a return path you can’t run challenge-response. Either sign each key-update message with a post-quantum signature key whose public half was provisioned on the receiver, or authenticate it with a MAC keyed from a pre-shared secret. Reject key-update messages with stale or repeated epoch identifiers, so that recorded updates can’t be replayed.

Design for loss you can’t see

The sender can’t learn that a packet was dropped. Repeat each key-update message several times, protect it with forward error correction where the diode transport supports it, and have the receiver keep the current, previous and next epoch keys during an overlap window. Nonces must never repeat under the same key. Persist the counter or derive a new key after every reboot of the sending side.

Should pre-shared symmetric keys be used to protect unidirectional OT links against quantum attacks?

Yes, as one layer, but not as the only mechanism. A high-entropy pre-shared key resists known quantum attacks and fits one-way links naturally. On its own, though, it concentrates all risk in one long-lived secret.

NIST IR 8547 notes that symmetric primitives that provide at least 128 bits of classical security are believed to meet the requirements of at least Category 1 security. The IETF applied this idea to VPNs in RFC 8784, an extension of IKEv2 to allow it to be resistant to a quantum computer by using preshared keys. Its guidance on key quality carries over directly to diode links: any post-quantum preshared key should contain at least 256 bits of entropy; this will provide 128 bits of post-quantum security.

The hybrid row is the defensible default for critical infrastructure. The PSK hedges against a future weakness in ML-KEM, and ML-KEM limits the damage if the PSK leaks through a maintenance laptop or a badly handled commissioning file.

How often should keys be rotated on a data diode link with no handshake?

Rotate on two timescales: short-lived session keys that the sender rotates by time and data volume, and long-term keys (the receiver’s ML-KEM key pair and the PSK) that you rotate on a planned operational cycle. No standard sets one number. Base the interval on how much traffic one key exposes and on how quickly you can detect a compromise.

Practical rules for links without a handshake:

• Session keys: start a new encapsulation epoch at a fixed interval and also after a data-volume threshold, whichever comes first. Between encapsulations, ratchet the key forward with a one-way KDF and erase the previous key, so that capturing the device’s memory doesn’t expose earlier segments.
• Long-term keys: tie rotation of the decapsulation key and PSK to events you already plan, such as scheduled outages, firmware updates or personnel changes. Provision the next key before retiring the current one, so the sender can switch without coordination.
• Clock independence: drive epochs from a sender counter rather than wall-clock time. OT clocks drift, and the receiver can’t ask for a resynchronisation.

For comparison: on bidirectional site links, handshake-based designs can renew keys much more often. The QPN gateway from Quantum Network renews both its classical and its ML-KEM handshake every two minutes. A one-way link can’t negotiate like that, which is why the sender-driven epoch model above is needed.

How do data diodes fit IEC 62443 zones and conduits when quantum-safe encryption is required?

In IEC 62443 terms the diode is a conduit with a direction constraint, and encryption is a property you assign per conduit based on what it crosses. The key decision is where encryption starts and ends relative to the diode.

IEC 62443-3-3 separates network segmentation and zone boundary protection (the SR 5 family) from confidentiality (SR 4.1) and communication integrity (SR 3.1). A diode strongly addresses the first group. The other two have to be designed separately. Three common placements:

The second placement is often the simplest to operate, because the downstream conduit is bidirectional and can use an interactive hybrid key exchange. A Layer 3 gateway at each end of that conduit, which Quantum Network’s QPN offers for site-to-site and edge-to-cloud paths, keeps OT equipment unchanged while the diode keeps enforcing direction upstream.

That inventory step matches what US agencies recommend. In their joint factsheet, CISA, NSA, and NIST urge organizations to begin preparing now by creating quantum-readiness roadmaps, conducting inventories, and they explicitly involve Information Technology (IT) and Operational Technology (OT) procurement experts. CISA is taking steps to help critical infrastructure owners and operators to facilitate the eventual transition to PQC for operational technology. For diode architectures, the most useful first step is mapping which conduits carry long-lived data across networks you don’t control.