PQC Migration for Critical Infrastructure Operators

Why sequencing matters for critical infrastructure

For a critical-infrastructure operator, PQC migration is a program of controlled change across services, information technology, operational technology, facilities, suppliers, and physical assets. The objective is not simply to install a new algorithm. It is to reduce cryptographic risk while preserving safe, reliable, and continuous operation. Guidance for operators describes migration as an IT/OT modernization effort and places it within a wider cyber-resilience program. The work should therefore be organized around service impact, data lifetime, operational dependencies, and the ability to recover from an unsuccessful change. C112

The sequencing challenge is intensified by the “harvest now, decrypt later” threat: information collected today may be decrypted if quantum technology later becomes capable of breaking currently used public-key systems. Sensitive data can retain value for many years, so the confidentiality lifetime of information is a factor in deciding what to address early. At the same time, the transition is unusually broad because public-key cryptography is embedded in diverse applications, infrastructures, protocols, hardware, and services. [C3]3

Operators should not assume that every component can be upgraded at the same time. Older systems may have cryptographic services that evolved in an undocumented or inconsistent way. OT environments may have infrequent replacement cycles, specialized hardware, constrained maintenance windows, and dependencies on suppliers. These conditions favor an evidence-led, staged migration with explicit dependencies and operational decision points rather than a “big bang” replacement. C42

1. Define migration and resilience goals

Start by stating what the program must protect and what successful migration means for the operator. The primary goal is mitigation of the cybersecurity threat posed by quantum computing, but the goals should also cover a robust cryptographic infrastructure and broader cyber resilience. Sector- and business-specific risks, service criticality, data value, data lifetime, and operational consequences should shape the objectives. Future adaptability should be an explicit goal because a system that cannot change cryptographic mechanisms will accumulate legacy risk as standards and implementations evolve. [C1]2

• Identify the priority services whose disruption would create unacceptable operational, safety, security, or economic consequences.
• Identify data that must remain confidential for many years and the systems, links, and repositories that process or store it.
• Define acceptable outage, rollback, and degraded-operation conditions for each migration wave.
• Set an objective for cryptographic agility: the ability to replace or adapt algorithms in protocols, applications, software, hardware, firmware, and infrastructure while preserving security and ongoing operations.
• Record assumptions about standards-compliant implementations and supplier availability, and revisit them as the ecosystem matures.

These goals should guide investment and sequencing. They should not be reduced to a compliance checklist. The cited material identifies regulatory requirements as one possible driver, but this article focuses on implementation and resilience: protecting critical assets, reducing disruption, controlling legacy exposure, and creating a route to full migration. [C1]2

2. Discover and assess the current estate

Discovery is the foundation of a defensible migration plan. Build a record of key services and applications; the data they hold, including its expected lifetime and value to an adversary; and how that data is protected in transit and at rest. Map the systems through which the data is processed, and maintain effective processes for identifying and managing software and hardware assets. The inventory should extend beyond conventional IT to OT systems, devices, industrial control systems, custom-built components, commercial off-the-shelf products, cloud services, and physical infrastructure. C42

The inventory should identify where quantum-vulnerable cryptography protects critical processes. Include cryptographic algorithms and their uses, protocols, certificates, key-management functions, libraries, applications, firmware, hardware modules, and trust relationships. Capture ownership, supplier, version, replacement cycle, maintenance window, connectivity, data handled, service dependency, and recovery method. Where the evidence is incomplete, record the uncertainty rather than treating the component as safe or migration-ready. Older custom-built products are likely to require particularly significant effort to make quantum-resistant. C131

Assessment should connect cryptographic findings to operational risk. A vulnerable algorithm used in a low-impact test service does not necessarily have the same urgency as one embedded in an industrial-control system, a high-impact service, or a system protecting information with a long confidentiality lifetime. Feed the quantum-vulnerable inventory into the organization’s risk-assessment process so that priority decisions are traceable and can be revisited when implementation or supplier assumptions change. [C13]1

3. Prioritize work and create migration waves

Prioritization should begin with high-impact systems, industrial control systems, and systems with long-term confidentiality or secrecy needs. Add dependencies that could become schedule constraints: long-lived hardware roots of trust, physical infrastructure, supplier-delivered products, cloud-hosted services, PKI, and systems with risks from legacy cryptography. The result should be a ranked set of migration activities, not just a ranked list of assets. C612

For each system or service, plan the path from investigation to operation. Relevant steps can include researching technology options, procurement, commissioning, testing, data backup and migration, rollout, and post-change validation. Include dependencies between systems and identify which changes must precede others. In a critical environment, a migration wave should have an owner, entry criteria, test evidence, maintenance window, communications plan, fallback method, and explicit exit criteria. [C6]2

Business continuity is a design requirement. Determine how much outage each service can tolerate, how the service will operate during a staged change, and how the operator will roll back if testing or production behavior is unacceptable. For OT and extensive physical infrastructure, account for infrequent replacement cycles and the practical limits of field maintenance. Only the simplest systems may be suitable for a single uplift; most environments are more likely to require staged migration and a period in which old and new mechanisms coexist. C62

The NCSC material provides planning milestones of particular practical value: complete assessment and an initial migration plan, including highest-priority activities, supplier and physical-infrastructure dependencies, investment needs, and long-lived hardware roots of trust; complete highest-priority activities and prepare infrastructure for a PQC future by 2031; refine a route to full migration by 2035; and complete migration by 2035. These dates are presented in the cited guidance as target milestones. Operators should preserve their stated dates and use the underlying sequencing logic—early preparation, staged migration, and resilience improvements—when adapting the plan to their own context. [C6]2

4. Address the technology dependencies

PQC migration crosses several technical layers. Cryptographic libraries need standardized PQC algorithms, secure implementations, performance work, and protection against side-channel attacks. Updating libraries gives developers access to quantum-resistant functions without requiring them to implement complex algorithms themselves. Operators should therefore track library versions, application dependencies, performance effects, and the testing evidence for each supported implementation. [C2]3

Cryptographic hardware—including hardware security modules and trusted platform modules—may need firmware updates, redesign, or replacement because PQC algorithms can have larger key sizes and different computational requirements. The migration plan should test whether modules can perform the required operations efficiently while maintaining expected security properties. This dependency is especially important where hardware is embedded in servers, devices, field equipment, or long-lived roots of trust. C23

PKI is another central dependency. Certification authorities, registration authorities, key-management systems, directory services, certificate issuance, validation, and revocation processes must support the relevant PQC transition. Backward compatibility and interoperability are important during the transition. Protocols such as TLS and IKE may allow negotiation of specific certificates once both communicating parties are upgraded; another possible approach is a new PQC root of trust that cross-signs an old one. Each approach requires case-by-case security assessment. [C8]32

A system does not provide quantum-secure authentication merely because one PQC component has been deployed. The cited guidance states that, in general, quantum-secure authentication requires migration of the PKI and expiration or revocation of traditional certificates. Operators should therefore define authentication completion criteria at the trust-domain level, not infer completion from an isolated endpoint or application upgrade. [C8]2

5. Manage suppliers, cloud services, and legacy constraints

PQC migration is ecosystem-wide. Engage suppliers early and ask each commercial off-the-shelf and cloud provider for its quantum-readiness roadmap. The roadmap should explain when and how updates or upgrades will enable PQC, how the product will be tested and integrated, and what costs or configuration changes are expected. Existing and future contracts should address the changes needed to support migration. For cloud-hosted products, discussions should cover the provider’s roadmap as well as the operator’s method for enabling PQC through configuration or application updates. C91

Supplier engagement is also a way to expose schedule risk. A product may depend on a hardware refresh, a firmware release, a library update, a certificate change, or a protocol capability that is not controlled by the operator. Record those dependencies in the migration plan and communicate the operator’s needs to suppliers. Vendor roadmaps should be treated as inputs to planning, not as substitutes for independent testing and risk assessment. C921

For custom-built or older systems, the operator may need either to migrate the technology to PQC or to develop security upgrades that mitigate the risk of continued use while migration is not yet feasible. The latter is a risk-management decision, not evidence that the legacy system has become quantum-resistant. Record the residual risk, planned end state, compensating measures, owner, and review date. [C13]2

6. Execute, validate, and improve the migration

Use staged implementation to learn before expanding. Begin with representative systems and controlled environments, test interoperability and performance, validate certificate and key-management behavior, and rehearse backup and rollback. Then move through prioritized waves while monitoring service health, operational behavior, security events, certificate status, and supplier issues. The purpose is not only to prove that a cryptographic exchange succeeds; it is to confirm that the surrounding service remains dependable under realistic operating conditions. C64

Hybrid protocols may be used initially to combine quantum-resistant and quantum-vulnerable algorithms for key establishment or digital signatures. They are typically designed to remain secure if at least one component algorithm is secure and may provide a path where sector-specific requirements still require a legacy algorithm. However, hybrids add implementation complexity and should be evaluated as transitional mechanisms, not assumed to be a universal answer. [C7]4

Maintain the inventory and migration plan as operational records. Reassess priorities when a supplier changes its roadmap, a hardware root of trust reaches replacement, a new implementation becomes available, a protocol dependency is resolved, or a service’s data lifetime changes. Crypto agility should be measured by demonstrated ability to replace or adapt algorithms while preserving security and ongoing operations, rather than by the presence of a policy statement alone. C54

A practical operating model

A durable program needs governance that connects security, engineering, operations, procurement, suppliers, and service owners. Security teams can define risk and validation expectations; service and OT owners can define outage and safety constraints; engineering teams can manage implementation; procurement can make supplier dependencies visible; and resilience teams can test recovery and rollback. The specific organizational model may vary, but accountability for each migration wave should be unambiguous. C12

1. Establish a single, risk-ranked inventory of cryptographic dependencies and the services they protect.
2. Assign an accountable owner to each priority service, migration wave, supplier dependency, and accepted residual risk.
3. Approve technical patterns for libraries, hardware, PKI, protocols, hybrid operation, testing, rollback, and certificate lifecycle management.
4. Require evidence before production rollout: interoperability, performance, security, continuity, recovery, and operational acceptance.
5. Review progress against priority assets and target milestones, and update the plan as standards-compliant implementations and supplier capabilities mature.

Conclusion

Critical-infrastructure operators should begin PQC migration with knowledge of their estate and a clear view of service and data priorities. The most resilient path is staged: define goals, discover cryptographic dependencies, prioritize high-impact and long-lived risks, engage suppliers, address libraries, hardware, PKI, and applications, test with continuity and rollback controls, and retain the ability to change algorithms as the ecosystem evolves. This approach accommodates legacy OT and physical-infrastructure constraints while turning PQC migration into a broader improvement in cyber resilience and operational readiness. C1C612