PQC for Energy

What PQC for Energy means

Post-quantum cryptography (PQC) is cryptography based on mathematical problems that future large-scale, fault-tolerant quantum computers are not expected to solve efficiently. It is the primary mitigation identified for the threat that quantum computing poses to the public-key cryptography currently used to protect networks. The UK National Cyber Security Centre (NCSC) states that preparation for migration should begin or continue now, most effectively as systems are replaced and as part of a broader cybersecurity uplift. [c4]1

For an energy organization, the scope is broader than a data-center perimeter. It includes network protocols and security technologies, software cryptographic libraries, cryptographic hardware, PKI and related infrastructure, applications and services, code signing, user and machine authentication, email and document signing or encryption, and the IT/OT systems and devices that support generation, transmission, distribution, storage, field operations, and enterprise functions. The cited NIST transition draft explicitly identifies these technology areas and migration considerations. c52

Why the energy sector needs a tailored approach

Energy environments combine long-lived assets, safety- and reliability-sensitive operations, enterprise IT, industrial control networks, remote access, suppliers, cloud services, and increasingly connected sensors and field devices. In an ICS architecture, OT and IT zones are typically separated by a DMZ firewall, but remote logins over the internet and connections from wireless field devices create cryptographic and access-control dependencies that must be addressed as part of the migration. [c2]1

Confidentiality is not the only concern. The NCSC notes that fielded OT devices and sensors may not require strong cryptographic protection for confidentiality in every case, while the integrity of their data can be critical: faulty sensor readings or commands can contribute to ICS failures. Consequently, migration priorities should consider authenticity, signing, command authorization, firmware and software updates, and machine identity—not only encrypted communications. [c2]1

Industrial IoT devices add constraints that can make migration materially harder. They may be resource-constrained, not upgradeable, installed in difficult-to-service locations, embedded in larger products, designed without replacement in mind, or dependent on proprietary or not-yet-PQC-compatible communications protocols. Internet-connected devices can also provide an entry point into control networks and from there toward the ICS enterprise IT zone through the DMZ. [c7]1

The risk is therefore both cryptographic and operational. A theoretically stronger algorithm is not a complete solution if a device cannot implement it, a protocol cannot negotiate it, a certificate cannot be replaced, a firmware-signing process cannot validate it, or a change introduces unacceptable latency, resource use, outage risk, or interoperability failure. These constraints make asset lifecycle planning, supplier coordination, and controlled testing central parts of an energy PQC program. c21

A practical PQC workflow for energy organizations

A defensible program can be organized as a repeating sequence: establish governance, discover cryptography, assess and prioritize risk, map dependencies, select migration patterns, test in representative environments, deploy in stages, and measure results. This sequence should cover both custom-built and commercial off-the-shelf (COTS) technology, as well as reliance on cloud services. CISA, NSA, and NIST recommend establishing a quantum-readiness project management team and beginning proactive cryptographic discovery while standards and implementation details continue to mature. c33

1. Create a cross-functional project team spanning cybersecurity, enterprise architecture, OT engineering, safety and reliability, procurement, legal or compliance, asset owners, and supplier management.
2. Build a cryptographic inventory covering IT and OT systems, network protocols, applications, libraries, hardware, firmware, PKI, certificates, signing systems, remote access, cloud dependencies, and update mechanisms.
3. Associate each cryptographic dependency with the data, function, asset, owner, supplier, location, lifecycle, replacement path, and operational consequence of compromise or failure.
4. Prioritize high-impact systems, ICS, long-term confidentiality or secrecy needs, externally exposed services, systems that authenticate commands or updates, and assets whose replacement or servicing is difficult.
5. Define migration patterns and acceptance criteria, then test them in labs, staging environments, pilot sites, and controlled operational windows before wider deployment.
6. Maintain an exception and remediation register for assets that cannot yet migrate, including compensating controls, supplier commitments, review dates, and retirement or replacement plans.

The inventory is not merely a compliance artifact. The joint CISA, NSA, and NIST fact sheet says it enables risk assessment and prioritization, helps identify access to datasets, and supports analysis of data that could be collected now and decrypted when a cryptographically relevant quantum computer becomes available. Discovery should therefore include both algorithm identification and business context. [c8]3

Architecture and implementation considerations

Network protocols and applications must be updated to support PQC algorithms for encryption, digital signatures, and key exchange. NIST’s initial public draft warns that this can involve changes to cryptographic implementations, key sizes, algorithm performance, protocols, libraries, application code, testing, and sometimes user interfaces. Energy teams should treat these as engineering changes with operational acceptance criteria, not as a simple configuration toggle. [c6]2

PKI migration deserves its own workstream. An enterprise PKI migration generally requires a new PQC root of trust and new PQC certificates for network entities; some devices may require physical interaction. The NCSC describes a parallel-PKI model in which PQC and traditional PKI operate together for a period, while noting that some highly controlled environments may support a direct transition. More commonly, staged migration requires protocols such as TLS and IKE to negotiate which certificates are used in particular contexts. [c10]1

Hybrid key-establishment or signature approaches may help maintain compatibility during transition, but they introduce additional implementation and architectural complexity. NIST’s draft says hybrid solutions can increase security risks and costs and are typically expected to be temporary, leading to a later transition to tools that use only PQC algorithms. NIST also leaves the decision to the specific application, which must weigh implementation cost, performance reduction, engineering complexity, and the need for independent security reviews. c112

Crypto agility is the enabling capability behind controlled change. NIST CSWP 39 Update 1 defines cryptographic agility as the capability to replace and adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations. For energy operators, that means making cryptographic dependencies visible and replaceable, separating algorithm choice from business logic where feasible, and ensuring that lifecycle, testing, deployment, rollback, and governance processes can accommodate future changes. c134

In OT and ICS, architecture must preserve segmentation and secure remote access while accommodating devices that cannot be changed quickly. A migration design should document the trust boundaries between enterprise IT, OT zones, DMZs, field networks, suppliers, and cloud services; identify where authentication, key establishment, signing, and integrity protection occur; and specify what happens when a device or peer cannot negotiate the intended mechanism. These design decisions should be validated against operational and safety requirements before production use. c21

Standards, suppliers, and evidence management

The source set includes NIST IR 8547 IPD, an initial public draft published in November 2024, and a joint CISA, NSA, and NIST fact sheet published on August 17, 2023. The NCSC migration-timelines material is current and dated March 20, 2025. These status and date distinctions matter: organizations should use the applicable finalized standards and sector or technology guidance when making deployment decisions, while using draft material as explicitly identified planning evidence. c3[c15]231

Vendor engagement is essential because COTS products, cloud-hosted products, embedded devices, and proprietary protocols may determine when and how migration is possible. CISA, NSA, and NIST recommend asking vendors for their quantum-readiness roadmaps, including when and how updates or upgrades will support PQC and the expected migration cost. For cloud-hosted products, organizations should ask cloud service providers how their roadmaps will enable PQC through configuration changes or application updates once standards are available. [c16]3

Procurement should capture more than a general statement that a product is “quantum safe.” Useful questions include which algorithms and protocol modes are supported, whether support is available in hardware, firmware, libraries, and management planes, how certificates and keys are rotated, what performance and size constraints apply, how legacy fallback is controlled, which components require physical access, and when support becomes available. The evidence supports vendor roadmap engagement and modernization planning; it does not establish that any particular supplier or product already satisfies these requirements. c1631

Testing, assurance, and useful measures

Migration testing should verify actual cryptographic behavior, not merely successful service availability. The NCSC gives the example of checking that standardized PQC cipher suites, when available for TLS, are actually being used rather than silently falling back to traditional cryptography. A rigorous assurance process should test the implementation and the wider cybersecurity uplift against the organization’s goals. [c17]1

• Percentage of identified cryptographic dependencies with a confirmed algorithm, protocol, owner, criticality, and migration disposition.
• Percentage of high-impact systems, ICS, remote-access paths, and long-term confidentiality datasets with an approved migration plan.
• Number and percentage of software clients, services, devices, and certificates using the intended PQC or approved transition mode.
• Number of assets still dependent on quantum-vulnerable cryptography, with age, risk, supplier commitment, and remediation status.
• Results of negative testing, including prohibited fallback, unsupported-peer behavior, certificate failure, rollback, recovery, and performance thresholds.
• Coverage of vendor and cloud-provider roadmaps, including committed delivery dates, upgrade paths, costs, and dependencies.

The purpose of measurement is decision support. The NCSC says metrics can show how far migration has progressed, identify systems that are not using PQC, indicate whether remedial action is needed, and help determine when support for traditional algorithms can be turned off. Metrics should therefore be tied to risk decisions and operational readiness rather than treated as a single percentage of migrated assets. [c17]1

Limitations and immediate next steps

PQC does not remove all cyber risk, guarantee that a future algorithm will be suitable for every device, or eliminate the need for secure implementation, key management, identity governance, patching, segmentation, monitoring, resilience, and independent review. The cited evidence also indicates that algorithm standards are a building block for protocols, products, and services, and that technical guidance for common technologies evolves as those technologies become ready for use. Energy organizations should avoid presenting a draft algorithm choice or a vendor promise as proof of complete quantum readiness. c73

1. Name an executive sponsor and an IT/OT project team with authority over asset owners, procurement, architecture, and risk acceptance.
2. Launch cryptographic discovery across enterprise, OT, ICS, industrial IoT, PKI, remote access, code signing, firmware signing, cloud, and supplier connections.
3. Classify data and functions by confidentiality lifetime, integrity impact, safety or reliability consequence, exposure, and replacement difficulty.
4. Request dated PQC roadmaps and migration constraints from COTS, cloud, device, network, and control-system suppliers.
5. Select representative pilots, including a constrained or difficult-to-service device, an enterprise PKI path, an OT remote-access path, and a critical application or protocol.
6. Define assurance metrics, fallback controls, rollback procedures, exception expiry dates, and criteria for retiring traditional cryptography.

Conclusion

For the energy sector, PQC is a coordinated transition across IT, OT, ICS, PKI, applications, protocols, suppliers, and field devices. The most practical starting point is not a universal algorithm mandate; it is a governed inventory and risk assessment that identifies where confidentiality, integrity, authentication, signing, and long asset lifecycles matter most. From there, organizations can use crypto-agile designs, staged PKI and protocol migration, supplier roadmaps, controlled testing, and meaningful measures. This approach reduces quantum exposure while respecting the availability, safety, interoperability, and operational constraints that define energy infrastructure. c3c13341