Executive Takeaway
The proposed Quantum-GUARD Act does not mean utilities should begin replacing every device that uses today’s public-key cryptography. It means leaders should stop treating post-quantum cryptography as a distant research problem.
The immediate decision is whether the organization can identify where cryptography supports critical communications, device identity, remote access, software updates, code signing, data protection, and recovery. In energy and other industrial environments, many of those dependencies are embedded in equipment expected to remain operational for decades. Waiting for certainty about the arrival of a cryptographically relevant quantum computer would leave too little time to discover, test, fund, and execute the migration.
The proportionate response is therefore not a purchasing program. It is an asset-lifecycle capability: discover cryptographic dependencies, prioritize them by business consequence and exposure, require credible vendor roadmaps, and incorporate crypto agility into planned engineering and procurement decisions.
What Changed and Who Is Affected
The Quantum Grid Utility Assurance and Resilient Defense Act of 2026, or Quantum-GUARD Act, was introduced in the U.S. Senate as S.5313. It would require the Federal Energy Regulatory Commission to consider cybersecurity risks from quantum computers within its electric-reliability responsibilities.
The sponsors’ summary of the proposed legislation also describes a Department of Energy testing environment for post-quantum adoption and a study of vulnerabilities affecting both information technology and operational technology in the bulk electric system. The bill has been referred to committee; it is not law, and its final provisions or prospects for enactment remain uncertain.
Its relevance nevertheless extends beyond regulated electric utilities. Power generators, renewable operators, equipment manufacturers, engineering contractors, cloud and telecommunications providers, and industrial customers all participate in the grid’s trust architecture. Petrochemical facilities also depend on cryptography in business systems, remote engineering paths, industrial gateways, safety-supporting infrastructure, firmware distribution, and connections to external operators.
The policy signal matters because NIST has finalized its first post-quantum standards and says organizations should begin migration planning. NIST’s current transition model anticipates deprecating and ultimately removing quantum-vulnerable algorithms from its standards by 2035, while expecting higher-risk systems to move earlier. That is a planning horizon, not a prediction of when a capable quantum computer will exist.
The Lifecycle Problem Behind the Cryptography
A cryptographic inventory is often described as the first step. That description is correct but incomplete.
NIST defines a cryptographic inventory as a record of the algorithms, protocols, keys, certificates, systems, applications, devices, data, and other components that provide or depend on cryptographic protection. In an industrial environment, however, a useful inventory must also answer management questions:
- Which operating function depends on the cryptography?
- Is the dependency used for confidentiality, authentication, command integrity, trusted updates, or recovery?
- Who owns the asset and who can authorize change?
- Can its cryptography be replaced through configuration or firmware, or only through hardware replacement?
- What operational testing and outage window would a change require?
- Is the vendor committed to supporting the asset through the required migration period?
A list of algorithms without this context may satisfy a discovery exercise while failing to support a decision.
This distinction is especially important in operational technology. The Department of Energy notes that grid environments contain legacy devices with limited computing capacity and communications bandwidth. Larger post-quantum keys, signatures, or messages may affect storage, processing, latency, network behavior, and interoperability. Those effects cannot be assumed to be unacceptable, but neither should compatibility be inferred from a vendor data sheet.
Crypto agility is the capability to replace or adapt cryptographic mechanisms while preserving security and operations. NIST’s crypto-agility guidance emphasizes that the capability must span protocols, applications, software, hardware, firmware, and infrastructure. For a long-lived industrial asset, that makes crypto agility part of configuration management, change management, procurement, and system engineering—not merely a responsibility assigned to the public-key infrastructure team.
Business and Architecture Implications
The quantum threat is frequently framed around attackers collecting encrypted data now and decrypting it later. That scenario matters for commercially sensitive designs, credentials, legal records, personal information, and other data whose value persists.
Grid and industrial operators must also consider integrity and authentication. Cryptography may establish whether a firmware package is trusted, whether a remote endpoint is authentic, whether a message has been altered, or whether a device is permitted to participate in a control environment. The NERC Critical Infrastructure Protection Roadmap identifies quantum computing as an emerging risk to the cryptography underlying modern communications.
That does not establish an imminent ability to manipulate grid operations with a quantum computer. It establishes a dependency that may become difficult to change if it remains invisible until vendors, regulators, or standards bodies impose deadlines.
The architecture decision should therefore follow consequence. A protection relay with a narrow, isolated communication path presents a different migration problem from an internet-facing customer platform, a certificate authority, a remote-access service, or a repository containing information that must remain confidential for decades. Treating them alike would waste scarce engineering capacity and could introduce avoidable operational risk.
This is consistent with a broader resilience principle: OT isolation must preserve essential operations, not simply create separation on a network diagram. Post-quantum changes must be evaluated against the same operating requirement. A cryptographic improvement that causes unsupported devices, timing failures, or unrecoverable interoperability problems is not a successful security outcome.
Prioritized Actions and Leadership Questions
Leaders can begin with capabilities they already own rather than creating a separate quantum program with its own disconnected inventory.
| Priority | Accountable owners | Required action | Operating evidence |
|---|---|---|---|
| 1 | CIO, CISO, OT engineering leader | Define scope, consequence criteria, and decision rights for cryptographic migration | Approved ownership model tied to critical services and asset lifecycles |
| 2 | Enterprise architecture, PKI, asset management, OT teams | Correlate cryptographic discovery with systems, data flows, firmware, vendors, and business functions | Sampled records that trace cryptography to an owner, dependency, consequence, and replacement path |
| 3 | Procurement and vendor management | Obtain supported-algorithm, upgrade, interoperability, and end-of-support roadmaps | Contractual commitments or documented risk decisions for unsupported products |
| 4 | Engineering and operations | Test candidate changes under realistic performance, failure, rollback, and recovery conditions | Test results showing latency, compatibility, fail-safe behavior, and restoration capability |
| 5 | Business and asset owners | Align migration with refresh plans and approve exceptions where early replacement is disproportionate | Funded roadmaps, dated exceptions, residual-risk owners, and review triggers |
Leadership questions should expose the decisions the inventory is meant to support:
- Which data or transactions must remain trustworthy or confidential beyond the expected life of current cryptography?
- Which critical assets cannot accept a cryptographic update without vendor intervention or replacement?
- Are upcoming capital projects purchasing equipment that could still be operating after 2035?
- Can suppliers provide testable migration paths, or only statements that their products are “quantum ready”?
- Who may accept the risk when migration threatens availability, safety, warranty support, or regulatory commitments?
The goal is not to make every asset post-quantum immediately. It is to prevent unmanaged cryptographic dependency from becoming an emergency replacement program later.
My Perspective
The most important part of the Quantum-GUARD Act is not its treatment of a future quantum computer. It is the proposed testing environment for real IT and OT systems.
Organizations have a habit of turning an emerging requirement into an inventory project, then treating the completed spreadsheet as evidence of readiness. That would repeat a familiar failure. A cryptographic inventory has value only when it changes procurement, engineering, maintenance, funding, and risk decisions.
I would also resist treating 2035 as a universal replacement deadline. Some systems should move earlier because they protect long-lived information, concentrated trust, or exposed services. Other embedded assets may reasonably remain in operation longer if compensating architecture, restricted connectivity, vendor limitations, and replacement consequences are understood and deliberately accepted.
The desired business attributes are available, because migration must not interrupt essential operations; integrity-assured, because trusted commands, identities, and software updates must remain verifiable; change-managed, because cryptographic replacement will cross technical and operational boundaries; and cost-effective, because premature asset replacement can consume capital without producing proportionate risk reduction.
Quantum readiness should not become another tool market. It should become evidence that the organization can change a foundational trust mechanism without losing control of the business process that depends on it.
Conclusion
S.5313 may change substantially or never become law. The dependency it exposes will remain.
Energy and industrial organizations use cryptography inside systems that were not designed for frequent algorithm changes and cannot be upgraded casually. Their strongest near-term move is to connect cryptographic discovery to asset ownership, operational consequence, vendor support, test evidence, and capital planning.
That work is useful even if quantum computing progresses more slowly than expected. It improves certificate management, response to cryptographic weaknesses, trusted software updates, supplier accountability, and architecture knowledge today. The measure of progress is not how many algorithms have been counted. It is whether leaders can identify a vulnerable dependency, choose a proportionate migration path, and change it without compromising safe and reliable operations.