Does post-quantum encryption add latency to OT real-time traffic?

Post-quantum encryption latency in OT real-time networks is the extra delay and timing variation that quantum-safe key exchange (such as ML-KEM, standardised in NIST FIPS 203) and periodic rekeying add to industrial control traffic. Examples are SCADA polling, PLC communication and protection signalling crossing an encrypted tunnel between sites, cloud environments and remote users.

This matters because the margin for delay in OT is narrow. Operators also face a migration that regulators expect to take years. CISA states plainly that “implementing post-quantum cryptography for OT systems will be a significant and enduring challenge for owners and operators of U.S. critical infrastructure.” The engineering question is not whether lattice cryptography is “heavy”. The question is where in the packet path its cost actually lands.

Does ML-KEM key exchange add noticeable latency to SCADA polling or PLC communication?

In steady state, no: ML-KEM runs only when a tunnel is set up or rekeyed, and individual SCADA or PLC packets are encrypted with a fast symmetric cipher. Noticeable latency comes from tunnel design (encapsulation, MTU, queueing and path) rather than from the post-quantum algorithm.

A key-encapsulation mechanism exists to agree on a shared secret. As FIPS 203 describes it, that secret can then be used with symmetric-key cryptographic algorithms to perform basic tasks in secure communications, such as encryption and authentication. A Modbus TCP read request, a DNP3 (IEEE 1815) integrity poll or an IEC 60870-5-104 I-frame never touches ML-KEM directly. It only passes through the symmetric data path.

For example, Quantum Network’s QPN gateway encrypts payload traffic with ChaCha20-Poly1305 and states a latency overhead of typically about 1 ms, varying with load and distance. Whatever the implementation, measure the overhead on your own paths rather than relying on a datasheet figure, because WAN queueing and link type often matter more than the cipher.

Which OT traffic actually crosses the tunnel?

Before you set a latency budget, identify which protocols really leave the site. Classic IEC 61850 GOOSE operates on a publisher-subscriber model directly at the Ethernet data link layer (EtherType 0x88B8), bypassing the network (IP) and transport (TCP) layers entirely. GOOSE inside a substation therefore never enters a Layer 3 tunnel. The inter-site traffic is MMS, routable GOOSE and Sampled Values (IEC 61850-90-5), DNP3, IEC 60870-5-104 and Modbus TCP.

Source: IEC 61850-5 transfer time classes as tabulated in arXiv 1810.08111 (2018).

How long does an ML-KEM handshake take on embedded industrial gateway hardware?

It depends on the processor class: tens of microseconds on x86, well under a millisecond per operation on modern single-board hardware, and roughly 28 to 57 ms on small microcontroller cores. Even the slowest case only matters at tunnel start, rekey and recovery, not per packet.

The microcontroller figures come from a full ML-KEM handshake comparison. They show 28.1 ms for ML-KEM-768 on the faster core and 56.6 ms on the slower one. On a single-board computer, the older model showed only a 14% execution time increase for ML-KEM-768 over the classical curve. For gateways built on industry-standard x86, CPU time for the post-quantum part is negligible.

Message size often matters more than computation. ML-KEM-768 requires 1,184 bytes for public key and 1,088 bytes for ciphertext while RSA-2048 uses 256 bytes for both. On narrowband radio, cellular or satellite backhaul to remote RTUs, these larger handshake messages can fragment. Retransmitted fragments add whole round trips, which dwarfs the arithmetic. In a hybrid design, where a classical and a post-quantum exchange are combined into one session key, both message sets travel during every rekey.

Does rekeying a post-quantum tunnel interrupt time-sensitive DNP3, Modbus TCP or IEC 61850 traffic?

A properly built tunnel rekeys “make before break”: it negotiates the new keys while traffic keeps flowing under the old ones, so control traffic sees no gap. Interruptions happen when an implementation tears down the old session first, when a weak CPU stalls the data path during the computation, or when packets in flight are dropped at the switchover.

Each protocol reacts differently to a short gap:

• Modbus TCP: the master usually just sees one late or missing response. The risk is a response timeout set tighter than the worst-case switchover, which leads to retries and, on some HMIs, a “communication failed” alarm.
• IEEE 1815 (DNP3): lost application confirmations trigger retries. A dropped TCP session forces reconnection and often an integrity poll, which briefly raises load on the outstation and the WAN.
• IEC 60870-5-104: if acknowledgements stall beyond the t1 timer, the connection closes and the controlling station has to restart data transfer and usually send a general interrogation. A rekey stall is unlikely to reach t1, but a failed rekey with slow recovery can.
• IEC 61850 MMS and R-GOOSE: MMS associations behave like other TCP sessions. Routable GOOSE has its own retransmission scheme, so a single lost frame is tolerated, but repeated losses at every rekey are not.

Delay symmetry is a separate issue. In differential protection, typical legacy relays can tolerate delay discrepancies of up to 750us. A rekey computation that briefly delays one direction only can push a protection channel past that margin. Keep differential protection off general-purpose encrypted WAN tunnels unless you have measured it explicitly.

How should rekey intervals be set for continuous OT process traffic?

Base the interval on time, keep it short enough to limit how much traffic any one key protects, and choose it only after you have proven that switchovers are lossless. Because ML-KEM is cheap on gateway-class hardware, a short interval mainly costs a few kilobytes of handshake traffic.

Practical rules that follow from OT traffic patterns:

• Prefer time-based lifetimes to volume-based ones. Process traffic is steady and low-volume, so byte-count lifetimes give unpredictable rekey moments, and that makes it harder to correlate timing anomalies with rekey events.
• Do not align the interval with polling cycles. If rekeys always land on the same poll slot, one outstation takes every switchover. A small offset spreads the impact.
• Stagger rekeys at hub sites. A control centre that terminates many substation or pumping-station tunnels should not compute all their handshakes in the same second.
• Size for the link, not the CPU. On constrained backhaul, the larger post-quantum messages set a practical floor on how often you can rekey without visible jitter.

One design point: Quantum Network’s QPN gateway uses a hybrid key agreement with ML-KEM as the post-quantum part, renews both handshakes every two minutes, never falls back to unencrypted traffic and retries automatically after a line failure. At a two-minute interval, a tunnel goes through 720 rekeys a day. That is why lossless switchover matters more than handshake speed.

The timeline adds pressure. NIST IR 8547 proposes that quantum-vulnerable algorithms at 112-bit security strength - deprecated after 2030, disallowed after 2035. Many OT links commissioned today will still be in service then. The algorithm-level view is also reassuring, since NIST says that at present, ML-KEM is believed to be secure, even against adversaries who possess a quantum computer.

How do you test a quantum-safe tunnel’s effect on control-loop timing before production rollout?

Measure a baseline without encryption, then run the same real traffic through the tunnel long enough to capture hundreds of rekeys and several induced failures. Judge the results against your protocol timeouts and IEC 61850-5 classes, using worst-case values rather than averages.

1. Time-synchronised capture. Put passive taps on both sides of each gateway and synchronise the capture points with IEEE 1588 PTP, so one-way delay and asymmetry can be measured as well as round-trip time.
2. Realistic traffic. Use the real SCADA master, RTUs, PLCs or IEDs (or hardware-in-the-loop) with production poll rates, plus background historian and file-transfer load to expose queueing.
3. Rekey correlation. Log every rekey timestamp from the gateways and compare latency in a window around each rekey with the rest of the run. At short intervals, a 24-hour soak gives a statistically useful sample.
4. Failure injection. Disconnect the WAN link, degrade it with loss and delay, and restart a gateway. Record time to recovery and whether IEC 60870-5-104 sessions, DNP3 associations and Modbus TCP masters recover without operator action.
5. MTU and fragmentation. Confirm that the tunnel overhead does not fragment control frames and that handshake messages get through on the narrowest backhaul you run.

Planning should start well before the deadlines arrive. In the CISA, NSA and NIST quantum-readiness initiative, then CISA Director Jen Easterly said: “It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.” For OT teams, that preparation means a cryptographic inventory of inter-site links, a timing baseline per protocol and a test plan like the one above, finished before any production cutover.