Migration at a Glance
Post-quantum migration is the process of replacing cryptographic algorithms vulnerable to quantum computer attacks with NIST-standardized post-quantum alternatives. The primary targets are public-key algorithms: RSA, Diffie-Hellman, ECDH, and ECDSA. These algorithms underpin most of today's secure communications, code signing, certificate infrastructure, and authentication.
Migration is a multi-phase program, not a patch cycle. Public-key cryptography is embedded throughout modern systems: in TLS stacks, PKI hierarchies, firmware update mechanisms, HSMs, VPNs, API authentication libraries, cloud SDKs, and supply-chain dependencies. Replacing it requires discovery, risk assessment, architecture planning, vendor coordination, and staged rollout.
Why Migration Is Complex
The challenge is not the algorithms themselves. NIST's finalized standards (ML-KEM, ML-DSA, SLH-DSA) are well-studied, and library support is already available. The challenge is locating where quantum-vulnerable cryptography is used, coordinating across a diverse ecosystem of vendors and counterparties, and sequencing changes without disrupting operations.
Most cryptographic dependencies are inherited from third-party libraries, cloud services, hardware devices, and supply-chain software. An organization does not directly control the cryptographic implementation in every system it operates. Migration requires vendor roadmap alignment, procurement criteria updates, and in some cases replacement of hardware that cannot be upgraded.
The harvest-now-decrypt-later (HNDL) threat adds urgency. Adversaries can collect encrypted traffic today and decrypt it once quantum hardware is available. Data with a long confidentiality lifetime is exposed to this risk now, not in the future. This means migration timelines must be informed by data lifetime as well as system criticality.
Phase One: Cryptographic Discovery
The first phase is building a comprehensive cryptographic inventory. Before any migration decision can be made, the organization must know where quantum-vulnerable cryptography is used: which systems, which protocols, which library versions, which certificates, and which supply-chain components.
Discovery methods include automated network scanning (examining TLS handshakes and certificate details), static code analysis (scanning codebases for cryptographic library calls), certificate inventory (cataloguing all certificates and their signature algorithms), and firmware extraction where possible. Manual review fills gaps that automated tools cannot reach.
The output of discovery is a Cryptographic Bill of Materials (CBOM): a structured inventory of every cryptographic algorithm, key size, certificate, and library in use across the organization. The CBOM is the foundation of all subsequent prioritization and planning.
Phase Two: Risk Assessment and Planning
With the CBOM in hand, the organization can assess risk and sequence the migration. Not all systems are equally urgent. Risk is shaped by the sensitivity of the data protected, the data's confidentiality lifetime, the system's criticality, and whether the system is already subject to specific regulatory requirements.
Systems protecting long-lived sensitive data, such as financial records, health information, or communications that must remain confidential for years, face the highest HNDL exposure. These are the highest-priority migration targets. Systems protecting ephemeral data or data that becomes public after a short time can be scheduled later.
Architecture decisions are made in this phase. Most organizations adopt a hybrid deployment model as the transition approach: running classical and post-quantum algorithms in parallel in the same protocol. Hybrid TLS (X25519 + ML-KEM) and hybrid certificates protect against both classical and quantum attacks during the migration window.
Phase Three: Migration Execution
Execution begins with the highest-priority systems and proceeds through the inventory in risk order. Typical activities include enabling hybrid TLS on internet-facing servers, replacing certificates with ML-DSA or hybrid certificates, migrating code signing to ML-DSA or SLH-DSA, and updating API authentication to use post-quantum algorithms.
Vendor and supply-chain dependencies require parallel coordination. Hardware security modules, TLS termination appliances, certificate authorities, and cloud provider services must all support the target algorithms before migration in those systems can be completed. Procurement criteria should be updated to require post-quantum readiness from new vendors.
Testing is critical at each step. Interoperability testing confirms that updated systems communicate correctly with both updated and not-yet-updated peers. Performance testing ensures that the larger key sizes and new algorithms do not introduce unacceptable latency.
Ongoing Governance
Post-quantum migration is not complete when the first systems are updated. The CBOM must be maintained as the organization's cryptographic posture evolves. New systems, new vendors, and new software dependencies introduce new cryptographic components that must be inventoried and assessed.
Crypto-agility, the architectural property of being able to swap cryptographic algorithms without re-engineering applications, is the long-term goal. Systems designed with crypto-agility can respond to new NIST guidance, discovered algorithm weaknesses, or changing regulatory requirements by updating configurations rather than rewriting code.