A post-quantum cryptography migration checklist must cover a multi-year change to protocols, products, certificates, keys, hardware and supplier contracts. It is not a direct search-and-replace operation. The immediate risk is uneven visibility: an organization may know its public certificates while missing cryptography embedded in firmware, identity federation, code signing, backups, partner links or managed services. A migration plan creates a decision system for finding those dependencies, prioritizing them and introducing new algorithms without breaking interoperability or recovery.
NIST finalized FIPS 203 for ML-KEM, FIPS 204 for ML-DSA and FIPS 205 for SLH-DSA in August 2024. These standards provide algorithms for key establishment and digital signatures, but they do not by themselves define how every application should migrate. CISA, NSA and NIST advise organizations to build a quantum-readiness roadmap, inventory cryptography, engage suppliers and prioritize sensitive long-lived data. The checklist below turns that direction into testable program work.
1. Establish migration governance and scope
Name an accountable executive, cryptographic architecture owner and service owners. Define which business services, data classes, jurisdictions, suppliers and lifecycle horizons the program covers. Connect the work to enterprise risk, procurement and technology lifecycle management rather than isolating it in a cryptography team. Record who can approve algorithms, hybrid modes, exceptions and retirement. Keep the plan versioned because standards, product support and threat assessments will change.
Set a risk statement that distinguishes confidentiality, authenticity and availability. Long-lived secrets may face harvest-now-decrypt-later exposure before a cryptographically relevant quantum computer exists. Signatures on firmware, records or long-lived trust anchors may have different consequences and timelines. Avoid declaring a universal quantum deadline. Prioritize using data life, system replacement cycle, exposure, safety or mission consequence and migration lead time. Document assumptions and review triggers.
| Inventory object | Fields to capture | Why it matters |
|---|---|---|
| Protocol or interface | Version, algorithm, key size, peer and owner | Shows interoperability constraints |
| Certificate or key | Purpose, issuer, storage, expiry and rotation | Reveals trust and lifecycle dependencies |
| Data set | Sensitivity, retention and exposure path | Supports harvest-now prioritization |
| Software or device | Library, firmware, hardware support and end date | Exposes implementation and replacement limits |
| Supplier service | Contract, roadmap, evidence and exit | Makes external dependency actionable |
| Recovery path | Backup, escrow, bootstrap and emergency access | Prevents migration from breaking restoration |
2. Build a service-linked cryptographic inventory
Combine discovery methods. Inspect configuration, certificate stores, source dependencies, software bills of materials, network observations, key-management systems, hardware inventories and supplier documentation. Passive scanning alone will miss dormant recovery paths and application-level signing. Code search alone will miss managed services and appliances. Reconcile findings to business services and data flows. Every item needs an owner, purpose, implementation, peer, replacement path and confidence level.
Treat inventory as a maintained capability. Add cryptographic metadata to architecture review, software acquisition, asset management and release pipelines. Record unknown and unsupported components rather than excluding them. Sample inventory accuracy through service walkthroughs: follow a customer transaction, software release or recovery event and identify every cryptographic control. A list of algorithms without the surrounding protocol and trust relationship cannot support a migration decision.
3. Prioritize data and systems by exposure and lead time
Create tiers. The highest priority may include externally exposed key establishment protecting data that must remain confidential for many years, long-lived code-signing roots, constrained devices with slow replacement and trust services used by many applications. Lower tiers may include short-lived data in frequently updated software where supplier support is clear. Add business calendar, certification and partner coordination. A technically simple library update can still require months of ecosystem testing.
Separate urgent risk reduction from algorithm migration. Improve certificate rotation, key ownership, protocol versions and asset visibility now. Retire obsolete algorithms and unsupported products under existing guidance. Reduce unnecessary data retention and exposure. These actions improve cryptographic agility and reduce the migration surface even before PQC is enabled. Do not deploy experimental algorithms to production merely to show progress; use approved standards and supported implementations for operational change.
4. Define target patterns and cryptographic agility
Create approved patterns by use case: transport key establishment, application encryption, digital signature, software signing, document signing, device identity and private connectivity. Map ML-KEM to key establishment and ML-DSA or SLH-DSA to signature needs; they are not interchangeable. Consider key and signature sizes, handshake behavior, storage, certificate profiles, hardware, latency and denial-of-service effects. Use standards profiles from the relevant protocol ecosystem rather than inventing a private wire format.
Hybrid designs combine classical and post-quantum components to manage transition risk, but the composition must be defined and supported by the protocol. Specify how secrets are combined, how peers negotiate, what downgrade evidence is recorded and how fallback is authorized. Cryptographic agility means the organization can change implementations and parameters through controlled, tested configuration. It does not mean accepting arbitrary algorithms at runtime. Keep algorithm policy explicit and deny unexpected negotiation.
5. Make supplier readiness verifiable
Ask suppliers where cryptography is used, which product versions will support NIST standards, whether support is production-ready, how hybrid operation works, what performance testing exists and how keys, certificates and evidence are handled. Request dates with dependencies and end-of-support implications. A marketing statement that a platform is quantum safe is not enough. Verify the exact service, region, API, device generation and client library included.
Update acquisition requirements to include cryptographic inventory, standards support, secure update, vulnerability handling, interoperability evidence, export and migration assistance. Avoid contract language that freezes one algorithm indefinitely. Require notification when implementations, libraries or trust chains change. Identify alternatives for suppliers whose roadmap is incompatible with the organization's data life or replacement schedule. Concentration matters: one unsupported identity, network or signing service can block many workloads.
6. Test performance, interoperability and recovery
Build test environments using production-like certificates, message sizes, connection rates, latency and constrained clients. Measure handshake size, CPU, memory, storage, battery, queue behavior and failure. Test old and new peer combinations, certificate chains, revocation, renewal, rotation and rollback. Include malformed and oversized inputs. Cryptographic code handles attacker-controlled data, so implementation hardening and negative testing are as important as successful negotiation.
Exercise recovery and bootstrap. Confirm that backups, key escrow where appropriate, disaster environments, firmware recovery and emergency administration still work. Test monitoring for unexpected algorithm, downgrade, validation failure and expiring classical-only dependencies. Preserve evidence linking a released configuration to implementation and policy. Performance acceptance should be end-to-end; a fast primitive can still create protocol fragmentation or infrastructure pressure.
| Migration gate | Evidence | Stop condition |
|---|---|---|
| Discovery | Service-linked inventory with confidence | Unknown critical trust dependency |
| Design | Approved protocol profile and rollback | Private unreviewed composition |
| Supplier | Supported versions and lifecycle dates | Marketing claim without product evidence |
| Lab | Interoperability and adverse-input tests | Unbounded failure or downgrade |
| Pilot | Representative cohort and telemetry | Recovery or support path fails |
| Expansion | Owner, objective and retirement plan | Classical path remains indefinitely by accident |
7. Roll out by dependency cohort and retire deliberately
Select a bounded cohort with representative peers and manageable consequence. Use controlled configuration, strong telemetry and predefined rollback. Coordinate client, server, certificate, network and monitoring changes as one release. Observe not only errors but negotiation and performance distribution. Expand by dependency group rather than business unit when shared protocols make that safer. Maintain compatibility windows with explicit owners and end dates.
Retirement is part of migration. Remove classical-only configurations when policy and ecosystem readiness allow; revoke obsolete credentials; decommission old libraries and hardware; update recovery media and documentation. Re-scan and reconcile the inventory after each wave. Track exceptions by business service, consequence, compensating controls and expiry. Report migrated risk and remaining blockers, not merely counts of installed PQC-capable products.
Key takeaways
- Govern confidentiality and signature risks separately.
- Link cryptographic components to services, peers, data and recovery paths.
- Use NIST standards through supported protocol profiles.
- Demand version-specific supplier evidence and lifecycle dates.
- Test adverse behavior and retire old paths through controlled cohorts.
Frequently asked questions
Should every organization deploy PQC immediately?
Every organization should begin readiness and inventory. Production deployment timing depends on data life, system lifecycle, standards profiles and supplier support. Prioritize long-lived and hard-to-replace dependencies.
Does PQC replace symmetric encryption?
The main migration focus is vulnerable public-key establishment and signatures. Well-parameterized symmetric cryptography is affected differently. Follow current authoritative guidance and review complete protocols.
Is QKD required for quantum safety?
No. NIST-standard post-quantum algorithms run on conventional systems and are the broad migration path. Quantum key distribution is specialized infrastructure and does not replace endpoint, authentication or application security.
Maintain a program scorecard that separates discovery coverage, target readiness, migrated services and retired exposure. Report inventory confidence and unresolved critical dependencies alongside counts. A service should not be marked complete merely because its front-end TLS endpoint supports a new option; verify internal calls, certificates, signing, recovery and partner paths. Schedule architecture and procurement reviews so newly acquired systems do not reintroduce classical-only dependencies during the transition. Train application, infrastructure, security and supplier-management teams on the approved patterns and exception process. Include independent implementation review for high-consequence trust services and preserve test vectors, configuration and release evidence so later audits can identify exactly what was deployed. This turns a one-time project into lasting cryptographic agility and makes future standards changes less disruptive.
Conclusion
A sound PQC migration plan makes cryptography visible, owned and changeable. Use the finalized NIST standards as technical anchors, but organize work around business services, protocols and lifecycle evidence. Inventory first, improve agility, verify suppliers, test complete recovery and expand through controlled cohorts. Maintain that evidence throughout the migration. That program reduces today's cryptographic debt while preparing for a transition whose exact timelines and ecosystem details will continue to evolve.