Does MPLS need encryption for quantum safety?

When people ask whether MPLS needs encryption against quantum threats, they are asking two things. First, private carrier circuits (MPLS VPNs, Ethernet leased lines and other Layer 2 services) carry traffic in cleartext unless the customer encrypts it. Second, once that traffic is encrypted, the key exchange has to resist future quantum computers. For OT and critical infrastructure operators, the answer to both is usually yes.

This article explains what MPLS does and does not protect, how harvest-now-decrypt-later applies to carrier links, what NIS2 and IEC 62443-3-3 expect, and how to add hybrid ML-KEM key agreement without rebuilding the WAN.

Is MPLS traffic encrypted by default?

No. MPLS separates customers’ traffic through labels and routing tables. It does not encrypt that traffic, and it gives you no way to check whether packets were altered in transit.

The standard that defines BGP/MPLS IP VPNs says so directly. RFC 4364 states that its methods do not by themselves encrypt the data for privacy, nor do they provide a way to determine whether data has been tampered with en route. It adds that if this is desired, cryptographic measures must be applied in addition. The IETF’s security analysis of MPLS VPNs, RFC 4381, considers confidentiality an optional VPN requirement, since many existing VPN deployments do not encrypt transit traffic.

Older Layer 2 services work the same way. RFC 5920 notes that in today’s MPLS/GMPLS, ATM, or Frame Relay networks, encryption is not provided as a basic feature. So “private” in a carrier contract means logically separated. It does not mean cryptographically protected.

Can carrier or leased-line traffic between sites be intercepted and stored for later decryption?

Yes, that risk is real. Carrier traffic passes through equipment, fibre routes, exchange buildings and subcontractors the customer does not control. Anything recorded there can be kept and analysed later.

With cleartext circuits, the exposure is immediate. With classically encrypted circuits, it is deferred. NIST describes the “harvest now, decrypt later” threat in which adversaries collect encrypted data now with the goal of decrypting it once quantum technology matures. Session keys negotiated with RSA or (EC)DH are the weak point. NIST therefore says this threat needs to be considered when determining a migration timeline for the key-establishment scheme.

The question that matters for OT is how long the data stays sensitive. Engineering drawings, protection relay settings, network topologies and control logic often stay relevant for a decade or more. NIST advises that organizations might prioritize migrating to the PQC key establishment standard (FIPS 203) for data that is particularly sensitive or needs to be kept secure for a long time.

Should critical infrastructure encrypt private WAN links even if they never touch the internet?

In most cases, yes. A carrier circuit is a link outside your own control. For OT, an unauthenticated control message arriving at a substation or pumping station can matter more than a confidentiality breach.

Integrity matters as much as confidentiality in OT

Many industrial protocols carried between control centres and field sites were designed for closed serial links and have no authentication of their own. Because MPLS gives no tamper detection (see RFC 4364 above), the protection has to come from the overlay: authenticated encryption that rejects any modified packet. That is an integrity control, not just a privacy measure.

Long asset lifetimes change the calculation

OT equipment stays in service far longer than IT equipment. The Dutch NCSC advises that if you are procuring systems with a longer service life, such as ICS/SCADA systems, then you should assume that these systems will have to deal with the advent of powerful quantum computers within the course of their lifetime. The same reasoning applies to the WAN encryption that links those systems.

How IEC 62443-3-3 frames the carrier link

In IEC 62443 terms, a WAN between two OT zones is a conduit. Its required protection follows from the target security level, not from whether it touches the internet. IEC 62443-3-3 sets system requirements for communication integrity (SR 3.1), information confidentiality (SR 4.1) and the use of cryptography (SR 4.3). A carrier network that a third party operates is hard to treat as a trusted conduit without cryptographic protection. Europol’s guidance points the same way: high-risk stakeholders should prioritise the integration of post-quantum cryptography into critical infrastructure and communication systems, including hybrid deployments.

How do you add hybrid ML-KEM encryption over an MPLS or Layer 2 carrier service?

Run an encrypted overlay between your own endpoints at each site. Its key agreement should combine a classical algorithm with ML-KEM from FIPS 203, so the session key holds as long as either part does. The carrier service stays as it is: the overlay simply rides on top.

Hybrid is the approach most European agencies recommend. Commission Recommendation (EU) 2024/1101 calls for deploying PQC in critical infrastructures via hybrid schemes that may combine Post-Quantum Cryptography with existing cryptographic approaches. The reasoning is simple: ML-KEM is newer than (EC)DH, so combining them protects against an unexpected weakness in either one.

Option 1: IPsec with RFC 9370 multiple key exchanges

If you already run IPsec over the carrier, RFC 9370 extends IKEv2 to combine key exchanges. The specification says its method allows integration of PQC in IKEv2, while maintaining backward compatibility, to derive a set of IKE keys that is resistant to quantum-computer attacks. RFC 9370 is only a framework, though. While RFC 9370 provides a general framework that enables hybrid KEMs, it does not define specific instantiations for concrete combinations of multiple KEMs, so check that both ends support the same ML-KEM parameter set.

Option 2: a dedicated Layer 3 encryption gateway

The other route is a dedicated gateway at each end of the circuit that encrypts at Layer 3, independent of existing routers. One example is the Quantum Gateway from Quantum Network. It sits at each end of a connection, combines a classical and an ML-KEM handshake into one session key, renews both every two minutes, and encrypts payloads with ChaCha20-Poly1305 authenticated per packet. It integrates by adding or adapting routes, never falls back to unencrypted traffic, and needs no software on the OT equipment behind it.

Design checks that matter on carrier links

On the first row: across the FIPS 203 parameter sets, ML-KEM ciphertext and encapsulation-key sizes from 768 to 1,568 bytes mean that ML-KEM-768 and ML-KEM-1024 messages can exceed restricted path MTUs after protocol and encapsulation overhead are added. Test this on the actual carrier service before the cutover window.

Does NIS2 require encryption on private carrier circuits between sites?

Not by name. The NIS2 Directive (EU) 2022/2555 does not specifically require encryption on every private circuit. Article 21(2)(h) does require policies on cryptography and, where appropriate, encryption, based on risk. A carrier link carrying OT or sensitive data is hard to leave out of that assessment.

The EU summary of NIS2 lists policies and procedures regarding the use of cryptography (and encryption, where appropriate) among the required measures. Commission Implementing Regulation (EU) 2024/2690 spells this out for digital infrastructure and ICT service providers. Their cryptography policy must set the type, strength and quality of the cryptographic measures required to protect the relevant entities’ assets, including data at rest and data in transit, following, where appropriate, a cryptographic agility approach.

Energy, water and transport operators get their detailed obligations through national transposition, not that regulation. Even so, ENISA’s technical guidance on the regulation may provide indications on the technical and the methodological requirements of the cybersecurity risk-management measures of NIS 2 Directive for other actors. ENISA’s Executive Director Juhan Lepassaar has said that “The implementation of NIS2 is a top priority for ENISA.”

One detail is worth noting. The regulation’s network security section allows trusted channels isolated using logical, cryptographic or physical separation. MPLS separation is logical, but the same clause also requires protection of the channel data from modification or disclosure. An unencrypted carrier circuit struggles to show that.

What timelines apply to quantum-safe WAN encryption?

EU and US guidance points to 2030 for high-risk systems and 2035 for everything else. Critical infrastructure falls in the first group.

The EU roadmap says all Member States should start transitioning to PQC by the end of 2026. At the same time, the protection of high-risk use cases should be transitioned to PQC as soon as possible, no later than by the end of 2030. A European Commission briefing hosted by ENISA names the high-risk group as critical infrastructure (eg water, energy, health care, finance and transportation). In the US, 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.

European Commission Executive Vice-President Henna Virkkunen summed up the policy position: “As we enter the quantum era, post-quantum cryptography is essential to ensure a high level of cybersecurity”. For a WAN that is unencrypted today, the order of work is the same either way: encrypt the carrier links, make the key exchange hybrid with ML-KEM, and keep the design agile enough to change algorithms later without replacing the network.