Post-Quantum Migration Plan for Critical Systems

A post-quantum migration does not begin with an algorithm choice. It begins by discovering where cryptography exists, how long information must remain protected, and which products can be changed without disrupting operations. The largest program risk is often not the absence of one PQC library. It is an unknown dependency, an appliance with no update path, or a protocol that hard-codes an algorithm into a long-lived format.

NIST approved FIPS 203, 204, and 205 on August 13, 2024. They specify ML-KEM for key establishment and ML-DSA and SLH-DSA for signatures. That is enough to begin inventory, supplier requirements, and controlled deployment. An organization does not need to predict the arrival date of a cryptographically relevant quantum computer before removing architectural barriers to migration.

Build a cryptographic inventory with operational context

A TLS certificate list captures only part of the estate. A cryptography bill of materials should cover libraries, protocols, certificates, keys, HSMs, firmware, software signing, archives, update mechanisms, VPN channels, service-to-service connections, and application-layer encryption. Each record needs an owner, purpose, algorithm, parameter set, key location, implementing component, and external dependency.

Use multiple discovery sources: code and configuration scanning, network telemetry, certificate repositories, service catalogs, and interviews with system owners. No single source is complete. Separate cryptography controlled by the organization from capabilities supplied by a cloud platform, SaaS provider, operating system, or device manufacturer.

The inventory must remain connected to change management. New services, certificates, libraries, and vendor integrations should add or update records automatically where possible. A one-time spreadsheet will decay before the migration reaches its hardest systems.

Prioritize by the lifetime of harm

Systems do not need the same migration order. For confidentiality, compare the required protection period with migration lead time and exposure to harvest-now-decrypt-later collection. An attacker may retain encrypted traffic and attempt decryption later. A short-lived internal message has a different profile from health records, intellectual property, or information about critical infrastructure.

Signatures require a different lens. Consider the validity period of the signed artifact, whether it can be re-signed, how root trust is updated, and the consequence of accepting forged firmware or software. The priority model should include data lifetime, external exposure, service criticality, supplier readiness, change difficulty, and rollback feasibility.

Do not force every item into a date selected for reporting convenience. Use explicit risk drivers and revisit the order when standards, vendor support, or system architecture changes.

Engineer crypto agility rather than one replacement

NIST CSWP 39 Update 1 describes crypto agility as the ability to adopt new algorithms and retire vulnerable ones while preserving security and operations. In an application, that means moving algorithm selection out of business logic, versioning formats, negotiating capabilities, rotating keys, and supporting controlled reads of legacy data during transition.

A cryptographic abstraction should hide implementation complexity without hiding evidence. Operators still need to know which algorithm and parameter set executed. Test a policy update without redeploying the entire product and define behavior when peers share no approved option. Agility does not mean accepting arbitrary algorithms; the permitted set remains a governed security policy.

Design observability at the same time. A migration cannot be verified if telemetry reports only that a connection was “encrypted” while omitting the mechanism actually negotiated.

Choose transition patterns protocol by protocol

A hybrid construction combining classical and post-quantum mechanisms can hedge implementation or interoperability risk, but it is not a universal requirement. It increases message size, negotiation complexity, library requirements, and possible failure states. Use it when a protocol profile, regulatory requirement, or documented threat model justifies the trade-off.

A pilot must measure more than successful encryption or signature verification. Test latency, throughput, certificate and message sizes, memory use, rotation behavior, intermediary compatibility, downgrade handling, and operational errors. Start with a service that can be reproduced in a controlled environment and has meaningful but bounded dependencies.

Define the fallback before the pilot. A silent downgrade to an unapproved classical mechanism is not a successful rollback. The approved fallback, duration, alert, and decision owner should be explicit.

Include PKI, backups, and constrained devices

Migration spans the trust lifecycle: generation, distribution, validation, rotation, revocation, and archival verification. A signature change may require new certificate profiles and updates to validators, HSMs, agents, and edge devices. Backups and long-term archives must remain readable after components and key-management processes change.

Operational technology, appliances, and products with long support periods can become the critical path. For each constrained component, choose an upgrade, gateway, isolation control, shortened service life, or accountable risk acceptance. A vendor's lack of a roadmap is not the end of the assessment; it is a documented gap that affects procurement and replacement planning.

Recovery exercises should include loss of new key material, restoration of legacy ciphertext, and mixed-version environments. Otherwise, the migration may improve the active path while making disaster recovery less reliable.

Put testable PQC requirements into procurement

Ask vendors which standards and parameter sets they support, how updates are delivered, whether hardware changes are required, how interoperability is tested, and how rollback works. A “quantum-ready” label does not establish that a product implements an approved standard or that its existing deployment can enable it safely.

The joint CISA, NSA, and NIST quantum-readiness guidance recommends a roadmap, cryptographic inventory, risk assessment, and early engagement with technology vendors. Contracts can turn those recommendations into evidence: supported upgrade paths, visibility into negotiated algorithms, migration assistance, legacy retirement terms, and customer testing before production change.

Apply the same requirements to managed services and embedded dependencies. A primary vendor's readiness may depend on its CDN, identity platform, HSM service, or firmware supplier.

Control migration waves, evidence, and rollback

Each wave needs entry and exit criteria. Before deployment, confirm inventory coverage, ownership, validated libraries, key-management changes, monitoring, and rollback. After deployment, demonstrate that traffic uses the intended mechanism, failures are visible, recovery works, and dependent systems have not silently reverted to a weaker configuration.

Program measures should include critical-system inventory coverage, the share of dependencies with a confirmed upgrade path, constrained components without a solution, time required to change cryptographic policy, and interoperability test outcomes. Track accepted exceptions with expiry dates and technical owners rather than reporting a broad percentage as “PQC complete.”

In March 2025 NIST selected HQC as a backup KEM based on different mathematics from ML-KEM. NIST also told organizations to continue migrating to the 2024 standards rather than wait for HQC. The architectural lesson is durability: today's selected algorithms must not become tomorrow's hard-coded dependency.

Sources

• NIST: Approval of Three FIPS for Post-Quantum Cryptography
• CISA, NSA and NIST: Quantum-Readiness — Migration to Post-Quantum Cryptography
• NIST CSWP 39 Update 1: Considerations for Achieving Crypto Agility
• NIST Selects HQC as a Fifth Algorithm for Post-Quantum Encryption