Post-quantum readiness refers to an organization’s preparedness to protect its systems, data and communications against future attacks from quantum computers—machines powerful enough to break today’s widely used public-key cryptographic algorithms (such as Rivest–Shamir–Adleman [RSA] and elliptic curve cryptography [ECC]). It involves developing a roadmap to transition to post-quantum cryptography (PQC)—new algorithms designed to resist quantum-enabled decryption—before that threat becomes practical. For operational technology (OT) professionals, post-quantum readiness means starting now to identify which cryptographic algorithms and legacy devices are quantum-vulnerable, working with vendors on transition plans and layering in compensating controls when the hardware itself can’t yet support quantum-resistant encryption.
A controller purchased today may still be operating decades from now. In some industrial systems, changing cryptography requires a firmware update, vendor support, a maintenance window and evidence that the change will not disturb the process. Decisions made during procurement and commissioning shape what an operator can safely change later.
Post-quantum readiness belongs in ordinary asset governance, engineering, purchasing and maintenance decisions. While information technology (IT) and OT share cryptographic dependencies, OT migration must also account for physical processes, safety requirements, equipment lifecycles and limited maintenance opportunities, so each change must be supported by evidence that required operations will remain reliable.
The National Institute of Standards and Technology (NIST) finalized Federal Information Processing Standards (FIPS) 203, 204 and 205 in 2024, specifying ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures [1]. Executive Order 14412 directs federal agencies to transition high-value assets and high-impact systems, excluding national security systems from that provision, by 31 December 2030, for key establishment and 31 December 2031, for digital signatures [2]. Those dates do not impose the same deadlines on every private operator. However, they do prompt operators to raise questions regarding long-lived purchases and vendor support plans.
Two risks and one operating constraint
Harvest now, decrypt later is a confidentiality concern: an adversary could collect protected engineering data today and attempt to decrypt it in the future. Authenticity is a different future concern. If a cryptographically relevant quantum computer eventually undermines a signature scheme still trusted by an installed device, an attacker might be able to produce a signature the device accepts on malicious firmware. Certificates bind an identity to a public key through a chain of trust; certificate validation and firmware signature verification are related but distinct checks. Trust anchors, expiry, revocation, the signing policy and update paths all matter. Neither example establishes that such a break has happened today.
Start with the system’s required behavior. Establish a known, good baseline, identify failure indicators, plan a safe response and protect safety and operator awareness throughout the change. Some field equipment may use little or no cryptography, while engineering workstations, remote access, historians, update services and vendor platforms around it may depend on vulnerable mechanisms. The boundary of the inventory must follow those dependencies.
Nine decisions in three phases
The framework consists of three phases and nine governance decisions that guide organizations through a post-quantum migration program. The sequence begins with understanding and prioritizing cryptographic exposures (Phase 1: Understand and Prioritize), progresses through migration architecture and treatment planning (Phase 2: Design the Migration) and concludes with procurement enforcement, deployment qualification and continuous monitoring (Phase 3: Execution, Procurement and Qualification). Each decision produces a documented output that serves as an input to subsequent decisions, creating a traceable and auditable migration process.
Phase I: Understand and Prioritize
Step 1. Assign governance. Name an owner with authority to fund work, set acceptance criteria, resolve disagreements among engineering, cyber, procurement and safety, and approve documented risk decisions. Identify who can authorize a change at each site.
Step 2. Set provisional priorities. Choose a few high-consequence use cases based on the consequences, data lifetimes, exposures and expected service lives. These are starting hypotheses, not a final ranking. A remote engineering-access path and a firmware update service may warrant attention for different reasons even when they serve the same controller.
Step 3. Build and refine the inventory. Record cryptographic assets and relationships in a maintained inventory or cryptographic bill of materials (CBOM): function, algorithm, protocol, implementation, certificates, trust anchors, owner, vendor, supported versions, configuration, support life and confidence in the evidence. Include the supporting systems and external services on which the asset depends. Revisit the provisional priorities as the inventory reveals dependencies. Executive Order 14412 directs Cybersecurity & Infrastructure Security Agency (CISA) and NIST to issue public guidance on minimum CBOM elements; it does not supply a completed checklist [2].
Step 4. Map control of each dependency. Identify whether the operator, equipment maker, integrator, service provider or another party controls the firmware, certificate authority, protocol endpoint or update mechanism. Record what changes can be made locally and what changes require a vendor release or coordinated outage.
Phase II: Design the Migration
Step 5. Give each exposure a disposition. Decide whether to migrate or reconfigure, obtain a vendor change, replace the asset, use a compensating control, isolate a dependency, retire it or accept the residual risk for a defined period. Procurement of a replacement is an action under the replacement decision, not a separate outcome. Record the owner, deadline, dependency and reason for the choice.
Step 6. Design for the actual device and protocol. PQC keys, signatures and related exchanges can increase memory use, message size, processing or connection setup cost. On a constrained controller, test a firmware verification sequence or certificate and session establishment under a representative load. Measure boot time, update duration, handshake behavior, memory, bandwidth and recovery, then determine whether any added processing or traffic affects required operations. Do not assume a PQC signature belongs on a millisecond protection path unless the proposed design actually puts one there.
Step 7. Govern exceptions. Where a direct update is unavailable, engineering and cybersecurity should document a compensating control—such as segmentation or an approved gateway—its limits, monitoring and failure response. The accountable operational owner and safety authority, where applicable, approve the residual risk. Revisit it at a set date and whenever a vendor update, incident, configuration change or new asset purchase changes the facts.
Phase III: Execution, Procurement and Qualification
Step 8. Put evidence gates in procurement and commissioning. “Quantum safe” is not an acceptance criterion. Require a vendor evidence package for the specific shipped product, firmware, protocol stack and configuration. A standardized algorithm alone does not establish that the product interoperates, fits its resource budget or can be operated safely.
At vendor submission, require:
- The cryptographic functions, algorithms, protocol constructions, implementation and firmware versions, and configuration to be shipped.
- Validation and test reports with scope and conditions, including clear distinctions between algorithm, module, protocol and product claims.
- Interoperability evidence for intended peers and certificate and key lifecycle procedures, including issuance, rotation, expiry, revocation and trust-anchor changes.
- Resource and performance measurements for boot, update, handshake, storage, bandwidth and relevant operating conditions.
- Failure behavior, downgrade prevention, an authorized recovery path and support and patch commitments.
Qualification is the second gate. In a representative test environment, the operator and vendor verify the supplied version and configuration against the package, exercise protocol interoperability with actual peers, measure resource use at a realistic load, rotate and expire credentials, and test loss of connectivity, failed updates, interrupted power and recovery. Record the baseline, acceptance limits, deviations and final sign-off, including the approver, date and any conditions or exceptions.
A recovery image or rollback may restore service, but it must not silently re-enable a vulnerable cryptographic mode; any temporary exception needs explicit authorization and a removal date.
Site commissioning is the third gate. Verify the delivered build, trust anchors, certificates, key custody, configuration and peer settings at the actual site. Exercise authentication, update and recovery procedures within a controlled window; confirm alarms and operational performance; and record the installed state. Engineering and operations should approve the results under the site’s change and safety procedures before production use. The questions transfer across sectors; timing limits, acceptable proof, approvals and test methods vary by system.
Step 9. Maintain the record. Monitor failures and expiry, detect unexpected cryptographic changes or weak fallback, rehearse response, and update the inventory after deployment, renewal, replacement or an exception review. Crypto agility means retaining a supported route to change the mechanism again without redesigning the whole system.
What the process produces
Consider an operator buying a remote terminal unit for an uncrewed pump station. The provisional priority is remote engineering access because the unit is expected to remain in service for 20 years. Inventory work shows that its remote-access gateway terminates the session, while the terminal unit verifies signed firmware from the equipment maker. The operator records the gateway, workstation, vendor update service and certificate authority as dependencies, rather than labeling the field device alone “PQC ready.”
The purchase specification asks the vendor for the shipped firmware version, supported exchange and signature mechanisms, certificate lifecycle, resource measurements, update verification and recovery procedure. Qualification tests the gateway with the operator’s actual access client and tests firmware verification and interrupted updates on representative hardware. The results show that the new connection exchange fits the link, but an older recovery image permits a legacy-only mode. The operator makes removal of that mode a condition of acceptance or records a time-limited exception approved by the operational and safety authorities.
At commissioning, the site team checks the delivered versions and trust anchors, proves remote access and alerting, validates updates and recovery under the approved procedure, and captures the final configuration in the inventory. The outcome is more useful than a vendor attestation: a supported configuration, measured limits, a named exception (if needed) and a testable path for the next change.
Start with a manageable scope
Name the owner, choose three to five high-consequence use cases and ask the relevant vendors for product-specific evidence. Refine the inventory and priorities, select treatments and qualify one candidate in a representative environment before commissioning it at a site. Record what remains uncertain. The practical question is whether each purchase and change leaves the operator with a safe, authorized way to adapt as the cryptographic requirements evolve.
Resources
- National Institute of Standards and Technology, “Announcing Approval of Three Federal Information Processing Standards (FIPS) for Post-Quantum Cryptography,” August 13, 2024. [Online]. Available: https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved
- Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” Federal Register, vol. 91, no. 121, June 22, 2026, sections 4(b) and 5(d). [Online]. Available: https://www.whitehouse.gov/presidential-actions/2026/06/securing-the-nation-against-advanced-cryptographic-attacks/
