Post-quantum SD-WAN encryption: what do OT sites need?

Post-quantum SD-WAN encryption means protecting the key exchanges in a software-defined WAN with quantum-resistant algorithms such as ML-KEM. The aim is to stop traffic between sites, cloud environments and remote users from being recorded now and decrypted later. For OT and critical infrastructure operators, this covers the data-plane tunnels as well as the control channels that distribute their keys.

Most SD-WAN deployments already encrypt traffic, so the question isn’t whether there’s a tunnel. The question is how the keys for that tunnel are agreed, and which channels carry them. This article walks through the exposure, the architecture and the questions to put to vendors.

Is SD-WAN traffic between sites vulnerable to harvest now, decrypt later?

Yes. SD-WAN tunnels that agree their keys through classical elliptic-curve or RSA key exchange can be recorded today and decrypted once a cryptographically relevant quantum computer exists. The symmetric payload cipher isn’t the weak point. The handshake is.

The EU’s own standardisation planning treats this as a present-day issue: the already existing threat of so-called “harvest now, decrypt later attacks”, in which malicious actors could store data now and decrypt them when a cryptographically relevant quantum computer is present, combined with long-lived devices, calls for starting the transition now. NIST researcher Andrew Regenscheid puts it this way: “data is being exposed to that future risk the moment it’s sent or stored today”.

On timing, one widely cited data point:

• In a survey of 37 leading experts, the majority estimated a 5% or lower likelihood of a cryptographically relevant quantum computer arriving within 10 years, but a 50% or greater likelihood within 15 years (OECD, 2024, citing Mosca and Piani, 2023).

For OT, the relevant comparison is how long the information stays sensitive. Many industrial protocols carried inside SD-WAN tunnels (Modbus/TCP, DNP3, IEC 60870-5-104) have no encryption of their own. Once the tunnel key is recovered, what was inside is readable: process topology, setpoints, historian exports, engineering-workstation sessions and sometimes credentials. Network layouts and control logic at a substation or water plant can stay relevant for well over a decade. That lines up with the 15-year horizon above.

How are keys distributed in an SD-WAN overlay, and where does post-quantum key exchange fit?

SD-WAN overlays generally use one of two models: the controller distributes or brokers tunnel keys, or the edges negotiate keys pairwise with IKEv2. Post-quantum key exchange has to sit wherever the secret is actually created and transported.

MEF 70.2 (SD-WAN Service Attributes and Service Framework) gives a shared vocabulary for describing these services. For example, the “SD-WAN client interface” is called the SD-WAN UNI, and Section 4 of MEF 70.2 defines a comprehensive set of attributes for it. IETF work on SD-WAN overlays describes how SD-WAN edges can retrieve parameters directly from the SD-WAN controller, including IPsec-related attributes for each edge. That second point is the one that matters for quantum safety.

RFC 9370 for IKEv2-based tunnels

RFC 9370 (Multiple Key Exchanges in IKEv2) describes how to extend IKEv2 to allow multiple key exchanges to take place while computing a shared secret during a Security Association setup. The additional key exchanges are performed using IKE_INTERMEDIATE messages that follow the IKE_SA_INIT exchange. One structural detail:

• To negotiate additional key exchanges, seven new Transform Types are defined (IETF, RFC 9370, 2023).

In practice, a classical ECDH exchange is followed by an ML-KEM exchange, and both feed the final key. The ML-KEM side is specified in FIPS 203, which was published August 13, 2024.

Handshake size on constrained links

Post-quantum keys are larger, which matters on cellular, satellite and licensed-radio backhaul at remote sites:

• ML-KEM-768 requires 1,184 bytes for its public key and 1,088 bytes for its ciphertext, while RSA-2048 uses 256 bytes for both (arXiv, 2026).

One protocol survey notes that IKEv2 was designed around the assumption of compact key exchange payloads, and its fragmentation mechanisms are less mature than those in TLS 1.3. Test handshakes on your real worst-case links, not only in the lab.

Do SD-WAN controller and orchestrator connections need hybrid ML-KEM as well as the data-plane tunnels?

The controller connection does whenever it carries, wraps or derives data-plane keys, because a classical control channel then undoes the post-quantum tunnels. Orchestrator connections are a lower priority for confidentiality, unless they push secrets such as pre-shared keys or private keys.

Edge-to-controller channels often run over TLS 1.3 or DTLS 1.3 (RFC 9147). Both negotiate key agreement in the handshake, which is where hybrid groups combining X25519 or an ECDH curve with ML-KEM belong. When you evaluate vendors, ask separately about each channel: edge to controller, controller to controller, edge to orchestrator, and operator to orchestrator.

Authentication is a separate question from key agreement. Certificates and signatures protect against impersonation in real time, so they aren’t exposed to recording in the same way. A European Commission briefing on the EU roadmap describes signatures and certificates as less urgent but more complex. A sensible order is hybrid ML-KEM on every key-carrying channel first, then a plan for post-quantum signatures in the controller PKI.

Can a separate quantum-safe gateway protect OT traffic carried over an existing SD-WAN?

Yes. A dedicated gateway pair at each end can encrypt OT traffic with hybrid post-quantum key exchange before it reaches the SD-WAN edge. The SD-WAN then carries the result as ordinary IP traffic. This works without waiting for the SD-WAN vendor’s roadmap.

This overlay-on-overlay pattern suits OT because the SD-WAN keeps doing what it’s good at (path selection, failover, transport aggregation) while confidentiality of the OT flows no longer depends on its key exchange. As one example, Quantum Network’s QPN gateway encrypts at Layer 3, combines a classical and an ML-KEM key agreement into one session key, renews both handshakes every two minutes, and never falls back to unencrypted traffic. It’s integrated by adding or adapting routes, and it can sit in front of a firewall that must keep inspecting traffic or behind one where inspection isn’t needed on that path.

The trade-offs are concrete and can be planned for:

Be clear about scope: an encryption gateway protects data in transit. It isn’t a firewall, web filter or denial-of-service defence, and it doesn’t harden the PLCs, RTUs or HMIs behind it.

What should I ask about post-quantum support when choosing an SD-WAN for critical infrastructure sites?

Ask which planes use hybrid ML-KEM today, what happens when a peer doesn’t support it, and how algorithms get replaced during the lifetime of hardware installed at remote sites. Answers that only describe “the tunnels” are incomplete.

The policy timeline helps frame the conversation:

• All Member States should start transitioning to PQC by the end of 2026. The protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030. (European Commission, EU NIS Cooperation Group PQC Roadmap, June 2025)
• A January 2026 Commission proposal points to achieving the migration to PQC by 2030 for critical use cases and by 2035 for medium and low level use cases (EUR-Lex, 2026).

The roadmap’s high-risk category explicitly names critical infrastructure (eg water, energy, health care, finance and transportation). Henna Virkkunen, Executive Vice-President of the European Commission, said: “As we enter the quantum era, post-quantum cryptography is essential to ensure a high level of cybersecurity”.

Questions that separate real support from roadmap slides

• Per plane: Is hybrid ML-KEM used on edge-to-edge tunnels, edge-to-controller channels and orchestrator sessions? Name the protocol for each (IKEv2 with RFC 9370, TLS 1.3, DTLS 1.3 per RFC 9147, or proprietary).
• Parameter set: Which FIPS 203 parameter set is used (ML-KEM-512, -768 or -1024), and is it configurable?
• Downgrade behaviour: If one side doesn’t support post-quantum, does the tunnel fail closed, or quietly fall back to classical-only? Can you enforce hybrid-only policy per site?
• Rekey interval: How often are session keys renewed, and does rekeying repeat the post-quantum exchange?
• Constrained links: Has the vendor tested post-quantum handshakes over cellular and satellite with small MTUs?
• Crypto agility: Can the post-quantum algorithm be swapped by software update on edges already in the field, and is that tied to a support contract?
• Isolated sites: Do controller and key functions keep working in air-gapped or intermittently connected environments, and does the edge send telemetry to a vendor cloud?
• Service definition: If you buy SD-WAN as a managed service described in MEF 70.2 terms, is the post-quantum requirement written into the contract for each SD-WAN UNI and virtual connection?