Bump in the wire encryption legacy PLC: how does it work?

Bump-in-the-wire encryption for a legacy PLC means placing a separate inline device between the controller and the network. That device encrypts and authenticates the traffic on the controller’s behalf. The PLC or RTU keeps running unchanged, while everything that leaves the cabinet travels encrypted, which can include quantum-safe key exchange.

This matters because control equipment often stays in service for decades, while the cryptography that protects wide-area links is about to change. This article explains how the approach works, what it does to control traffic timing, where its weak spot is, and how it fits into IEC 62443 and NIST guidance.

How can you add quantum-safe encryption to legacy PLCs that do not support modern cryptography?

You move the cryptography off the controller and into a device placed in front of it, so the PLC never needs to understand encryption. The device handles key exchange and encryption, and the PLC simply sends and receives its usual protocol traffic.

For many installed controllers, there are only three realistic paths:

Timing is what makes the quantum-safe part urgent. NIST finalized FIPS 203, which specifies ML-KEM, in 2024, and the standards are the result of an eight-year effort managed by NIST. Its migration plan is concrete: under the initial public draft of NIST IR 8547, quantum-vulnerable algorithms at 112-bit security strength are deprecated after 2030 and disallowed after 2035. Traffic that someone records today on a public WAN link could be decrypted later. So for long-lived OT data, the risk already exists before a capable quantum computer does.

The NIST official leading the effort has been direct about this. “We encourage system administrators to start integrating them into their systems immediately, because full integration will take time,” said Dustin Moody, the NIST mathematician who heads the PQC standardization project.

Most inline designs use a hybrid key exchange: a classical algorithm and ML-KEM are combined into one session key. NIST’s transition draft describes combining a classical algorithm and a PQC algorithm into a composite mechanism, intended to be secure as long as at least one component is secure, and states that such hybrid approaches may be used in the initial transition.

What is bump-in-the-wire encryption in OT networks?

It is a transparent encryption device placed in the communication path, one at each end of a link, that encrypts traffic between the two without the endpoints knowing. To the PLC, the SCADA master and the historian, the network looks unchanged.

Layer 2 versus Layer 3 placement

Inline devices operate either at Layer 2 (encrypting Ethernet frames on a segment) or at Layer 3 (encrypting IP packets between networks). In OT, this choice decides which traffic you can protect:

• Layer 3 inline encryption fits routed traffic between sites. Examples are a control centre polling substations with DNP3 over IP or IEC 60870-5-104, Modbus TCP between a plant and a remote pumping station, or replication from an edge historian to a cloud environment. Everything above Layer 3, including TCP and the industrial protocol itself, travels encrypted.
• Layer 2 encryption is sometimes considered for non-routed protocols, but strictly deterministic fieldbus traffic such as PROFINET IRT or IEC 61850 GOOSE is usually kept inside a physically protected cell rather than encrypted inline.

One example of the Layer 3 model is Quantum Network’s Quantum Gateway. It sits at each end of a connection, encrypts at Layer 3, and requires no software on the equipment behind it. Its key agreement combines a classical handshake with ML-KEM from FIPS 203, and both are renewed every two minutes.

What it does not do

An inline encryptor protects data in transit. It does not harden the PLC, filter malicious commands sent by an authorized master, or stop denial-of-service traffic. It complements segmentation and firewalls, it does not replace them.

Does an inline encryption device affect PLC polling cycles or deterministic control traffic?

It adds some latency and packet overhead. For routed supervisory polling this is usually small compared with the timeout budgets. For hard real-time loops inside a cell it can matter, so inline encryption normally belongs on the WAN side.

NIST SP 800-82 Rev. 3 notes that OT supervisory-level loops and lower-level loops operate continuously over the duration of a process with cycle times ranging in the order of milliseconds to minutes. That range is the key design input. A SCADA master polling RTUs every few seconds over a carrier network has plenty of headroom. A motion controller exchanging I/O every millisecond does not.

What to measure before go-live

• Round-trip budget: compare the measured RTT with and without the device against the master’s response timeout and retry settings, at peak load rather than at idle.
• Jitter during rekeying: check that renewing session keys does not cause bursts of delay that exceed the polling timeouts. Run a capture over several rekey intervals.
• MTU and fragmentation: encryption headers reduce the usable payload. Clamp the TCP MSS or lower the MTU so that large historian or file transfers do not fragment.
• Failure behaviour: decide in advance whether the link should fail closed. A device that never falls back to cleartext is safer, but operations must know that a line fault means lost communication until the tunnel recovers, not unprotected traffic.

How do you protect the unencrypted cable segment between a legacy RTU and its encryption device?

You make the segment as short as possible and keep it inside the same physical and logical security boundary as the RTU. You then document it as part of that zone rather than as part of the network.

The cleartext segment is the known weak spot of every bump-in-the-wire design. Practical measures that hold up in an assessment include:

• Co-location: mount the encryption device in the same locked cabinet or enclosure as the PLC or RTU. Connect it with a short patch cable that never leaves the enclosure.
• Tamper evidence: add cabinet door switches wired to an alarm input, tamper seals on the enclosure and on cable connectors, and inspection records for unmanned sites.
• Port hygiene: disable unused switch and device ports. Where a switch is present, bind the segment to the expected MAC addresses so that an inserted device is noticed.
• Link monitoring: alarm on link-down and link-up events on the inner interface. An unexpected interruption can indicate that someone has tapped the cable.
• Logical scoping: under the zones and conduits model of IEC 62443-3-3, place the PLC, the cable and the device inner interface in one zone. The encrypted link then becomes the conduit.

This combination of technical and physical controls is not new to industrial security. ISA’s own description of the framework behind IEC 62443 notes that in some applications “compensating countermeasures external to the control system (such as additional physical security measures and/or enhanced personnel background checks) will be needed.”

Is bump-in-the-wire encryption accepted under IEC 62443 as a compensating countermeasure?

IEC 62443 accepts compensating countermeasures in principle when a component cannot meet a requirement natively. Whether a specific inline encryption design qualifies is decided in your own risk assessment and zone and conduit design, not by the device.

IEC 62443-3-3 provides detailed technical control system requirements (SRs) associated with the seven foundational requirements (FRs) described in IEC 62443-1-1. The requirements that inline encryption usually addresses are SR 3.1 (communication integrity), SR 4.1 (information confidentiality) and SR 4.3 (use of cryptography). At component level, IEC 62443-4-2 sets matching component requirements, which a legacy PLC typically cannot meet on its own. That is exactly the situation where a compensating countermeasure comes into play.

What makes the case defensible

• A written mapping stating which SRs the controller cannot meet, and which ones the inline device and physical measures cover instead.
• An explicit treatment of the cleartext segment as residual risk inside the zone.
• Evidence that the cryptography follows accepted practice, such as ML-KEM from FIPS 203 in a hybrid construction, and that algorithms can be changed later as NIST guidance evolves.
• Verification that the countermeasure does not degrade essential functions, which brings back the timing tests described above.

How does NIST SP 800-82 Rev. 3 frame encryption for OT?

NIST treats encryption as one layer in a defence-in-depth programme. It must be balanced against the performance, reliability and safety needs of OT.

The guide provides guidance on how to secure operational technology (OT) while addressing their unique performance, reliability, and safety requirements. It is widely used: SP 800-82 has been downloaded more than 3 million times since its initial release in 2006. Teams writing a design basis today should also follow the next revision. NIST points to the initial public draft of Revision 4, with public comments due by November 30, 2026.

For organizations with mixed estates, a pragmatic order is:

1. Inventory which links cross untrusted networks (public internet, carrier circuits, cloud).
2. Add hybrid post-quantum encryption on those links first.
3. Adopt IEC 62351 protocol security as field devices are replaced.
4. Keep inline encryption as the layer for the controllers that will never get native support.

In that model, a gateway such as QPN covers the site-to-site, edge-to-cloud and remote-access paths. The controllers behind it stay untouched until their normal replacement cycle.