PQC migration planning is the controlled replacement of public-key cryptography that may be vulnerable to a future cryptographically relevant quantum computer. It is an asset, dependency and operating-model problem before it is an algorithm deployment. Organizations need to find where cryptography protects long-lived information, identity, software, devices and inter-organization trust; learn which suppliers and protocols control those choices; then move in stages without weakening current security or service continuity.
NIST approved FIPS 203, 204 and 205 in August 2024 for key establishment and digital signatures, and its transition guidance continues to evolve. That combination means teams should act now but avoid inventing unsupported production cryptography. Begin with Edilec's post-quantum migration business guide and use the PQC implementation checklist to turn this FAQ into owned work.
Why should PQC migration planning start now?
A migration spans discovery, product roadmaps, protocol updates, procurement, testing, certificate and key lifecycles, hardware replacement and partner coordination. Some systems will take years to change. Long-confidentiality data also creates harvest-now-decrypt-later exposure: an adversary can retain encrypted traffic today and attempt decryption if future capability arrives. Prioritize by required confidentiality lifetime and replacement lead time, not by predicting a specific date for a quantum computer.
The joint CISA, NSA and NIST quantum-readiness guidance recommends a roadmap, cryptographic inventory, supply-chain engagement and vendor assessment. Establish an executive sponsor, cryptographic owner, risk owner and system representatives. Connect the program to architecture, asset management, data governance, procurement, identity, PKI, software supply chain and continuity rather than isolating it as a research exercise.
| Priority factor | Question | Higher-priority signal | Evidence |
|---|---|---|---|
| Confidentiality life | How long must captured data remain secret? | Years or decades | Retention and harm assessment |
| Trust life | How long must signatures remain verifiable? | Long-lived records or firmware | Validation and archival policy |
| Exposure | Can traffic or artifacts be collected externally? | Public networks or published packages | Data-flow and distribution map |
| Replacement lead | How difficult is the dependency to change? | Embedded, regulated or partner-controlled | Roadmap and contract dates |
| Blast radius | How much trust depends on this component? | Root CA, identity or update system | Dependency graph |
What belongs in a cryptographic inventory?
Inventory functions, not just algorithm strings. Record where cryptography provides key establishment, confidentiality, signatures, authentication, integrity, code signing, time stamping or key wrapping. Capture system and business owner, data classification, protocol, library, algorithm and parameters, certificate authority, key location, hardware dependency, external endpoint, supplier, update mechanism, environment and observed evidence. Link each use to the information or trust decision it protects.
Use complementary discovery methods: source and dependency analysis, configuration inspection, certificate and traffic observation, key-management records, cloud inventories, hardware and firmware documentation, interviews and supplier attestations. NIST NCCoE's migration project separates cryptographic discovery from interoperability testing, reflecting two distinct capabilities. Discovery tools produce leads; owners must validate purpose, dependencies and false positives.
Which NIST PQC standards apply?
NIST FIPS 203 specifies ML-KEM for establishing shared secrets. FIPS 204 specifies ML-DSA and FIPS 205 specifies SLH-DSA for digital signatures. A KEM is not a drop-in encryption function, and signatures serve a different purpose from key establishment. Choose algorithms and parameter sets through approved protocol profiles, platform support and risk requirements. Monitor NIST's PQC publications for updates, errata and transition material.
Do not replace well-reviewed implementations with custom cryptographic code. Confirm validated or approved module requirements for the deployment context, protocol negotiation, random-number generation, key storage, certificate formats, failure behavior and downgrade protection. Hybrid classical-PQC approaches may be appropriate where supported by the relevant standards and products, but they add interoperability, size and lifecycle complexity. Document what security property the hybrid design provides and how either component will later be removed.
| Use case | Current dependency to find | PQC planning focus | Test concern |
|---|---|---|---|
| TLS or VPN key establishment | RSA or elliptic-curve exchange | Supported protocol and ML-KEM profile | Handshake size, latency and fallback |
| Document or transaction signing | RSA or ECDSA certificates | ML-DSA or approved profile | Signature size and verifier support |
| Firmware and code signing | Boot and update trust roots | Long-lived verifier transition | Device memory and recovery |
| PKI | CA hierarchy and certificate tooling | Issuance, revocation and mixed estate | Chain and relying-party compatibility |
| Archived evidence | Timestamp and signature validation | Long-term verification policy | Algorithm and metadata preservation |
How does crypto agility reduce migration risk?
Crypto agility is the capability to replace algorithms and implementations while maintaining security and operations. NIST's updated crypto-agility paper covers mechanisms and tradeoffs across protocols, applications, hardware and infrastructure. In practice, centralize approved policy, expose algorithm and certificate inventory, separate business logic from cryptographic implementation, support negotiated versions, automate certificate and key rotation, and retain rollback that does not enable silent downgrade.
Agility is not unlimited configurability. A broad menu of legacy options can increase attack surface and inconsistent behavior. Define approved suites by use and date, enforce policy in reusable libraries or services, and instrument effective negotiation. Test the emergency replacement of a component before PQC deployment. Procurement should require algorithm inventory, standards roadmap, update method, support duration, interoperability evidence, vulnerability handling and export of configuration and keys where ownership permits.
How should a PQC pilot be designed?
Select a representative but containable path with real protocol, identity, network, observability and operational constraints. A lab-only benchmark can compare primitive performance but cannot prove certificate tooling, middleboxes, partner clients or recovery. State the baseline, supported combinations, success thresholds and rollback. Measure handshake and signing latency, CPU, memory, message and certificate size, bandwidth, error rate, compatibility, operational effort and the ability to detect actual algorithm use.
Use staged exposure: test environment, internal clients, controlled partner, limited production cohort and wider rollout. Include malformed messages, unavailable key service, incompatible client, expired certificate, failed rotation and downgrade attempt. Confirm logs avoid secret material while recording policy and negotiated algorithm. Rehearse rollback and reconciliation. For organizations evaluating adjacent quantum technologies, the QKD planning guide explains why QKD is a separate architecture decision, not a substitute for broad PQC migration.
How should the migration program be governed?
Maintain a risk-ranked register that joins cryptographic use, protected asset, owner, supplier, target state, dependency, evidence and date. Review standards and supplier changes on a defined cadence. Put PQC requirements into architecture reviews, new procurement and renewal decisions so the vulnerable estate stops growing. Track inventory coverage, validated uses, roadmap coverage, supplier readiness, pilot compatibility, policy exceptions and migration completion by risk tier rather than counting scanned hosts.
Every exception needs business owner, reason, compensating control, expiry and replacement event. Preserve records needed to interpret old signatures and encrypted archives. Plan mixed operation because not every endpoint will move together. Incident response must distinguish implementation vulnerability, compromised key, algorithm deprecation and negotiation failure. The QKD implementation checklist can help teams keep specialized quantum-network proposals outside the general migration baseline unless a justified use exists.
What should supplier and procurement reviews require?
Ask each strategic supplier which products, versions and services use quantum-vulnerable public-key cryptography and where the customer can configure it. Request standards and protocol roadmaps, target releases, prerequisites, tested combinations, performance evidence, validation status where relevant, update mechanisms, mixed-mode support, rollback behavior and end-of-support dates. Distinguish available from enabled and planned from contractually committed. Map every response to the organization's inventory and renewal calendar so a product statement becomes an owned migration dependency.
New acquisition should require a machine-readable or otherwise maintainable cryptographic inventory, supported algorithm policy, timely security updates, algorithm negotiation visibility, key and certificate ownership, data export and transition assistance. Include notice for deprecation, protocol change and vulnerable implementation. Avoid requirements that merely demand quantum safe without naming function, standard or evidence; that wording invites incompatible interpretations. For embedded or long-lived systems, confirm memory, processor, message-size and boot-chain constraints before contract award.
Track suppliers by protected business service and replacement lead time. A vendor that cannot yet provide PQC may still be manageable if the system is short-lived, replaceable and does not protect long-confidentiality data; a silent dependency inside a root of trust may be urgent. Escalate roadmap gaps through product, security, procurement and business owners together. Record contingency options such as gateway termination, software upgrade, hardware refresh, alternate supplier or service retirement, including their interoperability and continuity risks.
PQC migration planning FAQ
Is there one universal PQC migration deadline?
No. Regulatory and government timelines vary, and systems have different information lifetimes and dependencies. Follow requirements that apply to your organization, but prioritize internal work by exposure, consequence and replacement lead time rather than waiting for one date.
Must all symmetric cryptography be replaced?
The central migration concern is quantum-vulnerable public-key cryptography. Symmetric algorithms and hashes have different quantum considerations and may require stronger parameters or policy changes, not the same replacement. Use authoritative sector and standards guidance for each function.
Can a vendor attestation close the issue?
No. Supplier evidence is necessary for managed dependencies, but the organization still owns integration, configuration, data lifetime, relying parties and continuity. Ask what is supported, enabled, measured and recoverable in your actual path.
Key takeaways
- Start with protected information and trust functions, not a guessed quantum date.
- Build a validated cryptographic inventory that includes suppliers and dependencies.
- Use NIST standards through supported protocols and reviewed implementations.
- Develop crypto agility with controlled policy, observability, rotation and rollback.
- Pilot representative paths and govern a mixed estate through risk-ranked evidence.
Conclusion: make cryptographic change an operating capability
PQC migration planning should leave the organization better able to change cryptography again. Inventory the uses that matter, rank them by information lifetime and dependency, engage suppliers, pilot supported standards and retain evidence of effective negotiation and recovery. Maintain explicit, accountable mixed-estate ownership until every relying party and archive is accounted for. That disciplined program reduces future quantum exposure without trading it for avoidable implementation or continuity risk today.