Post-quantum cryptography for energy & utilities: where to start
Energy and utilities share one property that makes post-quantum planning harder than in most sectors: equipment lives a long time. Smart meters, RTUs, protection relays and substation gateways are deployed for 15 to 25 years and are rarely re-keyed in place. Cryptography chosen for a device shipped today has to stay trustworthy well past any reasonable CRQC planning scenario.
Why the sector is different
- Firmware and update signing are the trust anchor. If the signing algorithm can be broken while devices are still in the field, an attacker can forge updates. For signatures the risk is not harvest-now-decrypt-later but forgery later, and it lasts as long as the devices do.
- Device identities outlive their algorithms. Certificates provisioned at manufacture (often RSA-2048 or ECDSA P-256) authenticate meters and field gear for their whole service life.
- OT and SCADA channels carry long-lived data. Grid topology, operations and customer metering data keep their value for years, which puts TLS-protected telemetry squarely in the HNDL window.
- Regulatory pressure is layered. Many operators are essential entities under NIS2, their equipment suppliers fall under the Cyber Resilience Act, and the EU's coordinated PQC roadmap asks for a first inventory by the end of 2026.
What a cryptographic inventory can cover today
Start where the evidence is: the software you build and operate, and the PKI around it. CRYPTAGION inventories source code (Python, JavaScript/TypeScript, Java, Go, C/C++), X.509 certificate stores — device identity, code signing, internal CAs — and live TLS endpoints, with file, line or endpoint provenance for every finding.
Be clear about the limits. Compiled firmware images, HSM internals and OT protocols such as DNP3 or IEC 61850 are not analysed by a source-code and PKI inventory. Cover them through supplier questionnaires, equipment documentation and procurement requirements, and record the answers next to the inventory so the gaps stay visible.
Give each asset a sector-realistic lifetime
A flat "ten years" for everything hides the assets that matter. A sensitivity policy that reflects equipment and data lifetimes changes the priorities completely. This is the profile we use in energy demonstrations:
With that policy, CRYPTAGION scores every quantum-vulnerable asset against its own lifetime, so firmware signing and device identities rise to the top while short-lived web traffic drops.
What to move first
- Remediate what is already broken. MD5 and SHA-1 signatures, RSA-1024 device certificates and expired certificates need no quantum computer to be a problem.
- Firmware and update signing. Plan the move to post-quantum signatures — ML-DSA (FIPS 204), or stateful hash-based signatures (LMS / XMSS, NIST SP 800-208), which CNSA 2.0 recommends for software and firmware signing.
- Identities issued from now on. Any device certificate provisioned today that will still be in service after the planning scenario should be on a migration path, with crypto-agile provisioning.
- Key exchange on OT and SCADA links. Hybrid key establishment with ML-KEM (FIPS 203) protects long-lived telemetry against harvesting.
- Retain and monitor the rest. AES-256 and SHA-256+ stay; track them in the inventory.
Put it in procurement
Every new equipment contract signed without post-quantum requirements extends exposure by the device's lifetime. Ask suppliers for a cryptographic bill of materials (CBOM), a stated migration path to NIST post-quantum algorithms, and evidence that firmware signing keys can be rotated in the field.
A 90-day start
- Weeks 1–4: inventory one critical domain — a metering platform, a SCADA front end — across code, certificates and TLS.
- Weeks 5–8: apply a sector sensitivity policy, separate broken cryptography from PQC migration candidates, and list what the inventory cannot see.
- Weeks 9–12: agree the first migration wave, add PQC clauses to new contracts, and put a CI gate on the software you build.
See it on an energy-style estate
We run CRYPTAGION on a representative repository in the call, with the energy sensitivity profile — inside your perimeter, no payment until you have seen it work.
Book a free discovery call →Sources
- NIST FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA), August 2024.
- NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes, 2020.
- NSA, Commercial National Security Algorithm Suite 2.0 (CNSA 2.0).
- Commission Recommendation (EU) 2024/1101 on a coordinated implementation roadmap for the transition to post-quantum cryptography, and the coordinated roadmap published by the NIS Cooperation Group.
- Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2024/2847 (Cyber Resilience Act).
This article is general guidance, not legal advice. CRYPTAGION supports compliance activities; use of the product does not by itself establish regulatory compliance.