Is IEC 62351 post quantum safe? Substation WAN guide

The IEC 62351 post-quantum question is whether the IEC 62351 security series for power system communications can withstand attacks from a cryptographically relevant quantum computer. The answer depends on the layer you look at. Symmetric message protection holds up well. Key establishment and authentication, which rely on RSA and elliptic curve cryptography, do not.

This article goes through the parts of IEC 62351 that matter for OT networks spanning substations, control centres, cloud environments and remote engineers. It covers what can be done today, while the standard itself catches up.

Is IEC 62351 vulnerable to quantum computers?

Partly. The symmetric algorithms that protect IEC 61850 and MMS messages are not seriously weakened. The public-key mechanisms used to authenticate devices and agree on keys (RSA, ECDSA, Diffie-Hellman and ECDH) are vulnerable to Shor’s algorithm.

IEC 62351 is a family of standards maintained by IEC Technical Committee 57. Each part handles a different job: IEC 62351-3 profiles TLS for TCP/IP-based protocols, IEC 62351-4 secures MMS, IEC 62351-6 secures GOOSE and Sampled Values, and IEC 62351-9 covers certificate and key management. The quantum exposure therefore varies by part.

NIST’s transition plan names the classical public-key algorithms that IEC 62351 depends on as quantum-vulnerable, and sets out a timetable for retiring them:

• NIST IR 8547 (2026): quantum-vulnerable public-key cryptography will be deprecated after 2030 and disallowed under NIST standards after 2035.
• OMB Memorandum M-26-15, as cited in NIST IR 8547 (2026): US federal high value assets and high impact systems must move to quantum-resistant key establishment by December 31, 2030.

Substation assets often run for decades. An IED commissioned this year with firmware supporting only classical TLS and GDOI could still be in service when those dates pass. Uncertainty about when a quantum computer will exist does not make this easier to plan for:

• Mosca and Piani (2024), as reported by the OECD: in a survey of 32 leading experts, about two-thirds estimated a 50% or greater likelihood of a cryptographically relevant quantum computer within the next 15 years.

Does IEC 62351-9 key management depend on RSA or elliptic curve cryptography?

Yes. IEC 62351-9 builds on X.509 certificates, which in practice use RSA or ECDSA signatures. Its group key distribution runs on GDOI, which authenticates group members and agrees keys with classical public-key methods.

IETF RFC 8052 documents how this works on the wire. IEC 62351-9 uses GDOI (RFC 6407) to distribute the security policy and session keys that protect IEC 61850 messages sent to groups of devices, while the protection of the messages themselves is defined in IEC 62351-6. Recent research describes the IEC 62351-9 model as a Key Distribution Center architecture: publishers and subscribers have to share a valid group key before HMAC- or GMAC-protected Sampled Values can flow.

The quantum risk does not sit in the GOOSE frame’s MAC. It sits in the registration phase, where each IED authenticates to the key server and receives keys over a channel set up with classical asymmetric cryptography. If someone records those exchanges and later breaks the asymmetric layer, they can recover the traffic keys for that period. A broken signature scheme also undermines device authentication itself.

How are routable GOOSE and Sampled Values protected between substations over a WAN?

IEC 61850-90-5 defines routable GOOSE (R-GOOSE) and routable Sampled Values (R-SV) over UDP/IP multicast. They are protected with symmetric MACs, and optionally encryption, using keys distributed through GDOI under IEC 62351-9.

Classic GOOSE and SV are Layer 2 publisher/subscriber protocols and stay inside the substation LAN. IEC 61850-90-5 adds a network and transport layer so that synchrophasor data, inter-substation interlocking and wide-area protection schemes can cross routed WANs. Group key management is how it keeps every subscriber in a multicast group able to verify each message.

For message integrity, IEC 62351-6:2020 recommends MAC-based algorithms with pre-shared keys because their computational overhead is much lower than per-message signatures. That matters for protection traffic, which works to millisecond budgets. Against a quantum computer the picture looks like this:

• The MAC and cipher layer (HMAC-SHA256, AES-GMAC, AES-GCM): stays strong. NIST IR 8547 confirms that approved symmetric primitives with at least 128 bits of classical security remain approved.
• The GDOI registration and rekey layer: exposed, because it runs on classical key agreement and certificate authentication.
• The WAN path itself: R-GOOSE and R-SV cross carrier networks, leased lines or sometimes the public internet, so recording traffic in bulk is realistic there in a way it is not inside a fenced substation.

The practical step is to treat the WAN segment as the place where the quantum risk is concentrated. The time-critical message authentication of IEC 62351-6 can then stay as it is.

Can hybrid ML-KEM be used in IEC 62351 TLS profiles for MMS connections?

Technically, a TLS 1.3 stack can negotiate a hybrid group that combines ECDHE with ML-KEM. However, the published IEC 62351-3 profiles do not list such groups, so using one puts the connection outside the profile and can break interoperability and conformance testing.

ML-KEM is specified in FIPS 203, which NIST published on August 13, 2024. NIST says ML-KEM is believed to be secure even against adversaries that have a quantum computer. FIPS 203 defines three parameter sets: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. In a hybrid key exchange, the classical and post-quantum shared secrets are combined. An attacker would then have to break both to recover the session key.

For MMS between a SCADA front end and substation IEDs, three practical barriers remain:

1. Profile conformance: IEC 62351-3 constrains which TLS versions, cipher suites and key exchange groups are acceptable. A hybrid group that both ends support may still be treated as non-conformant in vendor test regimes and utility specifications.
2. Embedded TLS stacks: many IEDs, RTUs and gateways run TLS libraries that vendors update slowly. Larger ML-KEM key shares also increase handshake sizes, which matters on constrained serial-to-IP links.
3. Authentication stays classical: hybrid ML-KEM protects the key exchange against later decryption of recorded traffic, but certificates under IEC 62351-9 still carry RSA or ECDSA signatures. Post-quantum signatures (FIPS 204, ML-DSA) in substation PKIs are a separate migration.

A pilot of hybrid TLS on a control-centre-to-gateway MMS link, where both ends run general-purpose operating systems, is reasonable for engineering evaluation. Rolling it out across a fleet of field IEDs ahead of a standards update is a different decision with real support risk.

Should substation-to-control-centre links be wrapped in a quantum-safe tunnel until IEC 62351 is updated?

For links that cross networks you do not fully control, yes, in most cases. A Layer 3 tunnel with hybrid post-quantum key agreement protects everything above it now, including MMS, IEC 60870-5-104, R-GOOSE and engineering access, without touching IED firmware.

The reasoning is about layering, not replacement. IEC 62351 keeps providing end-to-end device authentication and message integrity, including inside the substation LAN where the tunnel does not reach. The tunnel adds a quantum-resistant confidentiality layer on the WAN segment, where traffic is easiest to record. Grilo put the stakes plainly: “If a malicious party breaks our current cryptography using a quantum computer, all our private information is suddenly vulnerable.”

Design points specific to OT links

• Latency budget: check the tunnel’s added delay against the transfer time class of any protection scheme that uses R-GOOSE or R-SV across the WAN. Monitoring and SCADA polling usually have plenty of headroom. Teleprotection may not.
• Firewall placement: if an OT firewall or deep packet inspection has to keep seeing IEC 104 or MMS in clear text, put the tunnel endpoint in front of it so traffic is decrypted before inspection.
• Fail behaviour: decide explicitly whether a tunnel fault may fall back to unencrypted transport. For OT links, a design that never falls back and retries automatically is easier to defend.
• Key renewal: short rekey intervals limit how much traffic any single compromised session key exposes.
• Remote engineering and cloud: vendor and engineer access, and historian replication to cloud, often carry configuration files and credentials that stay sensitive for longer than protection signals. They belong in the same scope.

As one example of this pattern, Quantum Network’s QPN gateway sits at each end of a site-to-site, edge-to-cloud or remote-access connection. It combines a classical and an ML-KEM key agreement into one session key, renewed every two minutes, and encrypts at Layer 3 without software on the equipment behind it. It does not replace firewalls or protect the devices themselves, which is consistent with keeping IEC 62351 enabled end to end.

What should utilities do now while IEC 62351 is updated?

Inventory where IEC 62351 uses public-key cryptography, protect the WAN segments first, and specify crypto agility in new procurement so that IEDs bought today can take post-quantum updates later.

NIST advises organisations to identify where vulnerable algorithms are used and plan to replace or update them. For a utility, that inventory should cover at least the following:

• every IEC 62351-3 TLS endpoint, with its TLS version and key exchange groups;
• the IEC 62351-9 PKI hierarchy and certificate signature algorithms;
• GDOI key servers and their group policies for R-GOOSE and R-SV;
• which links leave physically controlled infrastructure.

In procurement specifications, require that IED and gateway vendors document how they will support ML-KEM and ML-DSA, how firmware updates are delivered, and whether the cryptographic algorithms can be changed without replacing hardware. Curty’s point applies directly to substation assets with 20-year lifetimes: “We want to be sure that messages can continue to be sent securely.” Planning for that outcome starts with the links that carry traffic today.