How to add quantum safe IEC 104 DNP3 encryption

Quantum safe IEC 104 DNP3 encryption means protecting telecontrol traffic between substations, RTUs and control centres with key exchange that can withstand a cryptographically relevant quantum computer. In practice this usually means combining a classical algorithm with a post-quantum one such as ML-KEM, while the IEC 60870-5-104 or DNP3 application protocol stays unchanged.

The topic is more pressing in OT than in office IT because of asset lifetimes. An RTU commissioned today may still be polling the control centre in the late 2030s. Grid topology, switching sequences and protection settings travelling over that link stay sensitive for years. This article explains where the quantum exposure actually sits in telecontrol protocols, what the IEC 62351 series covers, and how to protect devices that will never receive a firmware update.

Are IEC 60870-5-104 and DNP3 Secure Authentication vulnerable to quantum computers?

Plain IEC 60870-5-104 is not “vulnerable to quantum” because it has no cryptography to break. DNP3 Secure Authentication’s HMAC mechanism holds up well, but its public-key key management and its lack of encryption do not.

IEC 60870-5-104: no built-in protection

IEC 60870-5-104 carries IEC 60870-5-101 application data over TCP/IP with no native encryption or authentication. Anyone on the path can read unprotected 104 traffic today. The quantum question only comes up once you add protection. Security for this protocol family is defined separately: IEC/TS 62351-5 specifies messages, procedures and algorithms for securing protocols based on or derived from IEC 60870-5, and applies at least to those listed in IEC 60870-5-101, 5-102, 5-103 and 5-104.

IEEE 1815 (DNP3) Secure Authentication

IEEE 1815 (DNP3) Secure Authentication, aligned with IEC 62351-5, uses a challenge-response scheme built on HMAC and symmetric session keys, which are themselves protected by longer-lived update keys. That symmetric core is not where the quantum risk lies. According to NIST, existing symmetric cryptography standards are less vulnerable to quantum attacks, and NIST does not expect to transition away from them as part of the PQC migration.

The weak points sit elsewhere:

• Asymmetric update key change. Later SA versions let update keys be changed remotely using public-key methods. NIST lists RSA, (EC) Diffie-Hellman, MQV, ECDSA and EdDSA as vulnerable.
• No confidentiality. SA authenticates messages but does not encrypt them, so measurements and commands stay readable unless they are carried inside TLS or a tunnel.
• Any TLS wrapper. Once DNP3 or 104 runs inside TLS, the security of the data recorded today depends on that TLS handshake.

How urgent is post-quantum migration for telecontrol links?

The main regulatory timelines point to 2030 for high-risk systems and 2035 for everything else. Given how long OT refresh cycles take, planning has to start now.

The US policy goal, quoted in NIST IR 8547 from National Security Memorandum 10, is to transition “with the goal of mitigating as much of the quantum risk as is feasible by 2035.” NIST researcher Andrew Regenscheid explains why long-lived data cannot wait for that date: “data is being exposed to that future risk the moment it’s sent or stored today.”

Does IEC 62351 TLS protection for telecontrol support post-quantum key exchange?

Not yet in any way you can rely on. IEC 62351-3 profiles TLS for telecontrol, and its published editions are built around classical key exchange and certificates. Whether a given RTU could negotiate a hybrid post-quantum group depends entirely on its vendor’s TLS stack.

IEC 62351-3 specifies how to provide confidentiality, integrity protection, and message level authentication for SCADA and telecontrol protocols that make use of TCP/IP. Its scope is explicitly end-to-end: to provide security between communicating entities at either end of a TCP/IP connection within the end communicating entities. The series is maintained by IEC TC 57, and recent analysis notes it wraps protocols like IEC 60870-5-104 within TLS 1.2 or higher (with TLS 1.3 support added in the 2022 revision).

TLS 1.3 is a prerequisite for hybrid post-quantum key exchange, but it does not provide it. Hybrid ML-KEM key exchange groups for TLS 1.3 are being standardised in the IETF, separately from IEC 62351-3. In practice, that leaves three gaps for operators:

• Many installed RTUs and gateways only support TLS 1.2, and some only support it with renegotiation-based session key refresh as defined in earlier editions.
• Even where firmware supports TLS 1.3, embedded crypto libraries in field devices rarely ship ML-KEM, and ML-KEM’s larger key shares put more strain on constrained CPUs and narrowband links.
• Conformance testing under IEC 62351-100-3 checks the profile as published. It does not check post-quantum readiness.

What does IEC 62351-9 say about key management for power system equipment?

IEC 62351-9 defines how power system devices obtain, renew and revoke certificates and how group symmetric keys are distributed. Its trust anchors and enrolment steps rely on classical public-key cryptography, which makes it the most long-lived piece of the quantum migration.

The standard is described as a standard for key management of power systems and describing how digital certificates and group symmetrical session keys shall be managed, and it specifies how intelligent electronic devices shall perform their certificate enrollment with a registration/certification authority before becoming operational. For multicast IEC 61850 traffic, IEC 62351-9 introduces a Key Distribution Center based architecture using GDOI, where a long-term authentication key is used to securely distribute the operational group key.

The quantum issue lies in the bootstrap. The initial authentication and authorization phase can rely on classical asymmetric mechanisms through ISAKMP/TLS-oriented trust-establishment infrastructure, commonly using RSA or elliptic-curve public-key algorithms. Symmetric group keys can stay as they are. The CA hierarchy, the device certificates and the enrolment protocols cannot. In practice, the inventory work under IEC 62351-9 should record each CA’s algorithm and validity period, device certificate lifetimes, and whether each device can accept a new trust anchor in the field at all.

Should you secure substation-to-control-centre links with a quantum-safe tunnel or protocol-level TLS?

For most operators the answer is both, phased in. A hybrid post-quantum tunnel protects the WAN segment now, without depending on device firmware. Protocol-level TLS and Secure Authentication then provide end-to-end assurance as devices gain support.

Inspection is a real design factor. The IEC 62351 series includes IEC/TR 62351-90-2 Deep Packet Inspection guidance precisely because encrypted telecontrol traffic conflicts with protocol-aware monitoring. Where an OT firewall enforces function-code or ASDU-type allow-lists, put the tunnel endpoint on the WAN side of that firewall so inspection still sees clear traffic.

How do you add quantum-safe encryption to legacy RTUs that can’t be upgraded?

Put a hybrid post-quantum encryption gateway at the substation edge and another at the control centre. Then route the RTU’s IEC 104 or DNP3 traffic through it, so the RTU itself is left untouched.

Because the gateway works at the network layer, the RTU keeps talking plain 104 or DNP3 on its local segment while everything on the WAN is encrypted. Quantum Network’s Quantum Gateway follows this pattern: it encrypts at Layer 3, needs no software on the equipment behind it, and combines a classical handshake and an ML-KEM (FIPS 203) handshake into one session key, with both handshakes renewed every two minutes. Points to check in any such design:

• The clear segment. The cable between the RTU and the gateway carries unencrypted traffic, so treat it as part of the physical security perimeter. Keep it short and inside the locked cabinet or control building.
• Serial RTUs. IEC 60870-5-101 or serial DNP3 devices first need conversion to IP at the site. The serial leg remains local and unencrypted.
• Timers and MTU. IEC 104 t1 and t3 timeouts are measured in seconds, so millisecond-level encryption overhead is rarely the problem. Encapsulation overhead and the larger post-quantum handshakes on cellular or narrowband links are what you need to test.
• Failure behaviour. Confirm the tunnel never falls back to clear traffic after a link drop, and that it recovers without an operator on site.
• Scope. A tunnel protects data in transit. It does not harden the RTU, replace the OT firewall or mitigate denial of service.

A practical sequence for telecontrol estates

Start with an inventory per link: protocol (104, DNP3 over IP, serial), current security mode (none, SA, TLS 1.2, TLS 1.3), key exchange and certificate algorithms, how long the data needs to stay confidential, and the device’s firmware roadmap. Links that cross public or shared carrier networks and carry long-lived sensitive data go first. Next, deploy network-layer hybrid protection on those links. In parallel, add post-quantum requirements to RTU and SCADA procurement and plan the IEC 62351-9 PKI migration, which has the longest lead time of all.

As NCSC-NL notes, mitigation can mean migrating cryptography, additional (physical) segmentation, or isolating systems. For telecontrol, a mix of all three is usually the realistic path.