Quantum Security for Energy and Utilities: Protecting Operational Technology

A substation commissioned in 2025 will typically remain in service until 2045 or later. The protection relays, Remote Terminal Units, and Intelligent Electronic Devices installed this year will use ECDSA-based authentication throughout that operational lifetime. By the time the Global Risk Institute's 2024 median estimate for a cryptographically relevant quantum computer arrives in the 2033-2035 window, those devices will be approximately a decade into their lifecycle. This is not a planning problem that arrives in the future.

Energy and utilities OT presents the hardest post-quantum cryptography migration problem of any critical national infrastructure sector. The combination of 20-to-40-year device lifetimes, constrained compute on fielded devices, low-bandwidth serial protocols, and the operational risk of firmware updates in live grid environments makes PQC migration qualitatively different from the equivalent work on enterprise IT infrastructure. The standard IT migration playbook, updating TLS libraries and rotating certificates, addresses only the perimeter. It does not reach the field devices where the most durable vulnerabilities sit.

The honest assessment is that full PQC migration of fielded OT devices at electricity distribution operators is a decade-long programme. That is not an argument for deferral. It is an argument for starting the procurement-driven and perimeter-layer work now, with clear sequencing for the parts that can be done within standard change management constraints, and for ensuring that no algorithm-fixed device enters the estate in a 2025 or 2026 procurement without a documented algorithm-agility requirement.

Why OT is a distinct problem

Device lifetime mismatch

Electricity substation equipment, including protection relays, RTUs, and IEDs, has an operational lifetime of 20 to 40 years. This figure is not an industry estimate; it is reflected in IEC TC57 Working Group publications and in the asset management practices of electricity system operators including National Grid ESO. IEC 62351-8, the security standard for role-based access control in power systems communications, acknowledges this device lifetime in its informative text when discussing the cryptographic lifecycle challenge.

The implication for CRQC risk is straightforward. A protection relay installed at a 132kV substation in 2025 with ECDSA-based authentication will still be operational in 2045, and potentially in 2055. Every plausible CRQC feasibility window falls within that service life. If the device cannot receive a cryptographic algorithm update via software, and most fielded OT devices cannot, then the algorithm embedded in the firmware at installation is the algorithm that will be running when CRQC capability matures.

Unlike enterprise IT, OT devices in most existing deployments cannot receive cryptographic algorithm updates through a standard patch cycle. Algorithm changes require either hardware replacement or firmware re-flashing, which in a protection relay context requires a planned outage, protection system de-energisation, and in many cases regulator or control room notification. The migration risk must be managed as an OT change management programme, not an IT patch cycle.

The operational risk of migration itself

Firmware update failures on protection relays have caused grid events. A mis-operation, whether a failure to trip under fault conditions or an unintended trip under normal conditions, has consequences that extend well beyond the device. This is why OT security practitioners treat the risk of a botched cryptographic update as operationally equivalent in severity to a cyberattack. The consequence is the same: a protection relay that does not function as designed during a fault event.

IEC 62443-2-3 (Patch Management in the IACS Environment) and NERC CIP-010 (Configuration Change Management) both provide frameworks for managing firmware and software changes in OT environments. Under CIP-010, cryptographic library updates on Bulk Electric System Cyber Systems require documented baseline verification before and after the change, with change approval processes that typically add months to any update cycle for high-impact assets. This is the institutional context within which any PQC migration in energy OT must operate.

OT cryptographic protocols: where the quantum vulnerability sits

DNP3 Secure Authentication Version 5

DNP3 SAv5, defined in IEEE 1815-2012, is the primary authentication layer for SCADA communications between master stations and outstations in North American and many international electricity networks. It uses AES-128 or AES-256 for message authentication via HMAC, and RSA or ECDSA for update key exchange. The HMAC component, using AES-256, is quantum-resistant: Grover's algorithm reduces its effective security to approximately 128 bits, which remains impractical to attack. The RSA and ECDSA key exchange in SAv5 is directly vulnerable to Shor's algorithm on a CRQC.

DNP3 SAv5 has no published PQC extension. The IEEE P1815 working group is the relevant standards body, and no draft quantum-resistant authentication extension for SAv6 had been published as of mid-2025. The absence of a standards-defined migration path for DNP3 SAv5 key exchange is the single largest protocol-level gap in energy sector PQC migration planning.

To assess which OT protocols in your estate carry quantum-vulnerable authentication, see the OT protocol quantum vulnerability scanner.

IEC 62351: the security standard for power systems communications

IEC 62351 (parts 1 through 14) provides cryptographic security for IEC 61850, IEC 60870-5, ICCP, and related power systems protocols. The parts relevant to PQC migration are IEC 62351-3 (TLS profiles for SCADA and power system communications) and IEC 62351-8 (role-based access control with certificate-based authentication using RSA and ECDSA).

IEC 62351-3 is based on TLS 1.2 and TLS 1.3 profiles. TLS 1.3 does support hybrid key exchange mechanisms, combining classical and post-quantum algorithms within a single handshake, but implementation requires client and server library support that most fielded IEC 62351 devices do not yet provide. The barrier is not the standard itself but the compute and memory constraints of the devices implementing it. An RTU running on a 32-bit microcontroller with 256KB of RAM does not have the resources to run ML-KEM-768 key exchange at the protocol level, even if the standard were updated tomorrow.

NERC CIP requirements and quantum risk

NERC CIP framework

NERC Critical Infrastructure Protection standards govern cybersecurity for bulk electric system assets in North America and provide the most detailed published OT cybersecurity framework for electricity operators globally. The three standards most relevant to PQC migration are CIP-005 (Electronic Security Perimeter), which covers encrypted communications at the perimeter; CIP-010 (Configuration Change Management), which governs firmware and cryptographic library updates; and CIP-013 (Supply Chain Risk Management), which provides the regulatory hook for requiring PQC algorithm agility in new OT procurement.

NERC does not yet mandate PQC algorithms specifically. NERC's Critical Infrastructure Protection Committee has published preliminary guidance on quantum risk as an emerging consideration. European and UK operators should note that NERC CIP is a North American regulatory instrument; NIS 2 and the UK NIS Regulations 2018 are the applicable frameworks for EU and UK operators respectively. NERC CIP remains the reference standard for OT cybersecurity practice precisely because no equivalent level of OT-specific published guidance exists in European regulatory instruments.

What CIP-010 means for OT firmware updates

Under CIP-010, any firmware or software modification to a Bulk Electric System Cyber System requires documentation of the pre-change baseline, formal change authorisation, and post-change verification. For high-impact assets, which include generation and transmission control systems above defined voltage thresholds, the typical change management cycle from submission to implementation adds three to six months. This timeline is not a bureaucratic obstacle; it exists because uncontrolled changes to protection and control systems are a demonstrated grid risk.

Planning PQC migration for DNP3 SAv5 devices within a NERC CIP compliance programme means treating each firmware update as a formal change management project, with associated resource and timeline implications that are substantially longer than the equivalent IT patch deployment.

EU NIS 2 and IEC 62443 for European operators

NIS 2 Annex I: energy as essential entity

NIS 2 Directive (EU 2022/2555) Annex I designates energy operators, including electricity, gas, oil, and district heating, as essential entities subject to the highest tier of NIS 2 security requirements. Article 21(2)(h) requires essential entities to implement "the use of cryptography and, where appropriate, encryption" as part of their cybersecurity risk management. Critically, this requirement applies to OT systems in scope, not only to corporate IT. An electricity distribution operator's substation communications infrastructure, including the SCADA master-to-outstation links, falls within the Article 21 scope.

UK operators are not subject to NIS 2 directly. The UK NIS Regulations 2018 (SI 2018/506) apply to UK Operators of Essential Services, with NCSC as the relevant competent authority for energy. UK-based operators with EU infrastructure or EU-regulated subsidiaries may be in NIS 2 scope in that capacity; this requires specific legal assessment. For the detailed NIS 2 and quantum risk gap analysis, see NIS 2 quantum risk and compliance gap analysis. For the EU-level policy context shaping these regulatory obligations, the EU quantum security policy 2026 overview covers the broader legislative direction.

IEC 62443 SL ratings and cryptographic requirements

IEC 62443 Security Level (SL) ratings define capability requirements for industrial automation and control system security. SL 3 and SL 4 targets, which cover protection against sophisticated targeted attacks, require strong asymmetric cryptography for authentication. This means RSA and ECDSA: precisely the algorithms that Shor's algorithm will break on a CRQC. Energy operators targeting SL 3 compliance for their SCADA communications infrastructure are therefore using quantum-vulnerable authentication as part of their compliance demonstration.

IEC 62443 does not yet mandate PQC. Compliance with current SL 3 requirements does not mean quantum resilience, and security teams should not conflate the two. The HNDL exposure for SL 3 and SL 4 OT authentication traffic is a live concern for operators at these levels, particularly for session establishment traffic on engineering workstation connections and SCADA master communications that may be interceptable at network boundaries.

PQC challenges specific to low-bandwidth OT links

Algorithm size constraints

The size difference between classical and post-quantum key material is significant at low-bandwidth serial links. X25519, the elliptic curve Diffie-Hellman function used in modern TLS, uses a 32-byte public key and produces a 32-byte shared secret. ML-KEM-768, the recommended security level from NIST FIPS 203, uses a 1,184-byte public key and produces a 1,088-byte ciphertext. ML-KEM-512 reduces those to 800 bytes and 768 bytes respectively at lower security margins.

DNP3 serial links in older RTU deployments may operate at 9,600 bits per second or 19,200 bits per second. An ML-KEM-768 key exchange adds approximately 2,272 bytes of overhead. At 9,600 bps, that is roughly two seconds of transmission time for a single key exchange, before accounting for protocol framing and fragmentation. For systems that perform frequent re-authentication or where communications latency is safety-relevant, this overhead is not trivial. ML-KEM-512 halves the bandwidth penalty at the cost of a lower security margin; for the most constrained links, it may be the appropriate choice once a standards-defined protocol extension for DNP3 exists.

Compute constraints

Many fielded RTUs and IEDs run on ARM Cortex-M3 or Cortex-M4 class 32-bit microcontrollers with 128 to 512KB of RAM. Benchmark data from the pqm4 project (Kannwischer et al., IACR ePrint 2019/844) shows that ML-KEM-768 key generation requires approximately 100,000 clock cycles on ARM Cortex-M4 at 120MHz and approximately 1.5KB of stack space. This is within the capability of higher-end fielded controllers but outside the practical range of older or lower-specification devices.

SLH-DSA (FIPS 205), the hash-based signature scheme standardised in August 2024, is worth noting for constrained device contexts. Signature verification under SLH-DSA does not require key storage and has a lower computational cost than signing. XMSS (RFC 8391) and LMS (NIST SP 800-208) provide stateful hash-based alternatives with practical performance on constrained hardware and are suitable for firmware authentication use cases where the state management overhead can be handled at the device lifecycle level. For a detailed comparison of XMSS and LMS deployment options in constrained environments, see the hash-based signatures XMSS and LMS deployment guide.

Practical migration sequencing for energy operators

Three-tier prioritisation

Migration at energy operators should proceed in three tiers ordered by feasibility and exposure, not by perceived importance.

The first tier is the network perimeter: firewalls, jump servers, and data historians at the IT-OT boundary. TLS on these systems is the highest-exposure surface for external adversaries and the least operationally constrained migration target. Hybrid TLS combining X25519 with ML-KEM-768 is available in OpenSSL 3.5 and later, deployable on standard server hardware without replacing any OT device. This can be done now, within standard IT change management processes, and provides immediate protection for the boundary that adversaries are most likely to be able to reach. The NIST FIPS post-quantum standards guide covers the algorithm selection criteria for each layer of this migration.

The second tier covers engineering workstation and historian connections. OPC UA Security Mode connections between engineering workstations and SCADA historians use X.509 certificates with RSA or ECDSA. The OPC Foundation is developing PQC integration for OPC UA security profiles; the interim migration uses hybrid certificates or upgraded certificate profiles. This is deployable within 12 to 18 months for most configurations and requires OPC UA SDK updates rather than hardware replacement. For a structured sequencing approach, see the OT/SCADA quantum security practitioner framework.

The third tier is field device authentication: RTU, IED, and protection relay key exchange under DNP3 SAv5 or IEC 62351-8. This is the hardest migration and the one with the longest timeline. The sequencing guidance here is to procure only algorithm-agile devices from 2026 onwards, with documented ML-KEM support in the firmware roadmap as a mandatory tender requirement. Field migration for existing devices should be planned within the 2031 to 2035 lifecycle window, aligned with scheduled protection relay and RTU replacement programmes. The OT cryptographic asset prioritisation matrix supports the asset-level decisions in this tier.

Procurement-driven migration

The fastest available path to long-term OT quantum resilience is at procurement time. Requiring PQC algorithm agility as a mandatory criterion in RTU, IED, and protection relay tenders from 2026 ensures that the devices entering the estate now can be updated when protocol extensions for DNP3 SAv5 and IEC 62351 mature. Algorithm-agile devices can receive cryptographic algorithm updates via signed firmware; algorithm-fixed devices cannot. The difference in procurement cost is marginal; the difference in migration cost over a 20-year asset lifecycle is substantial.

IEC 62443-2-4 (Patch Management Process Requirements) provides the framework for documenting OT firmware update processes, including cryptographic algorithm updates, in supplier contracts and internal security procedures.

The honest assessment

Two things are true simultaneously at every electricity distribution operator. Full PQC migration of fielded OT devices is a decade-long programme that will not be complete before CRQC timelines mature for some subset of assets. This is the honest engineering reality, and no security team should present a timeline that suggests otherwise to their board.

At the same time, deferring all PQC work because the hardest part takes the longest is the wrong response. The IT-OT boundary, engineering workstation connections, and historian infrastructure can be migrated within 12 to 24 months for most operators. Those layers are the primary exposure surface for HNDL collection by external adversaries. Addressing them reduces the material risk substantially, even while the field device programme runs across the full decade. Prioritising the right layers makes the migration tractable within realistic operational constraints.

QSECDEF's CNI quantum security sector protection roadmap provides a cross-sector reference for energy operators building their PQC migration programme against regulatory and CRQC timeline constraints.