Post-quantum cryptography uses algorithms designed to resist attacks by both classical and sufficiently capable quantum computers while running on conventional systems. The migration matters because widely used public-key algorithms support key establishment and digital signatures across protocols, certificates, software updates, documents, devices and identities. NIST approved FIPS 203, 204 and 205 in 2024. That milestone makes standards-based engineering possible, but it does not turn migration into a universal software switch.
Organizations should prepare without predicting the date of a cryptanalytically relevant quantum computer. Risk depends on how long information must remain confidential, how long systems take to replace and whether adversaries can collect encrypted data now for later decryption. Signatures create a different concern: systems, firmware and records may need verifiable authenticity for years. Joint CISA, NSA and NIST guidance urges a roadmap, inventory, risk assessment and supplier engagement. The first business deliverable is visibility and ownership, not an untested algorithm rollout.
Key takeaways
- Inventory cryptographic uses and dependencies, not merely certificates or algorithm names.
- Prioritize by data secrecy life, signature validity, migration lead time, exposure and criticality.
- Use NIST-standardized algorithms through supported, validated implementations and protocols.
- Engage software, hardware, cloud, network and certificate suppliers with evidence-based questions.
- Test interoperability, performance, message size, recovery and downgrade behavior in realistic paths.
- Build cryptographic agility so future algorithm and parameter changes are controlled rather than exceptional.
Understand what the standards cover
FIPS 203 specifies ML-KEM, a key-encapsulation mechanism used to establish shared secret material. FIPS 204 specifies ML-DSA, a module-lattice digital signature scheme. FIPS 205 specifies SLH-DSA, a stateless hash-based signature scheme. Key establishment and signatures solve different problems and are not interchangeable. Products and protocols must integrate algorithm identifiers, key formats, certificates, negotiation, error handling and implementation protections. Selection should follow applicable sector and government guidance, not a generic preference for the largest parameter.
NIST continues related standardization and transition work, so maintain an authoritative watch function. A product claiming quantum safe may refer to a proprietary algorithm, a hybrid experiment, a standardized algorithm, or only part of a connection. Ask exactly which standard, parameter set, protocol version, implementation, validation status and operational mode is used. NSA also distinguishes PQC from quantum key distribution and does not treat specialized quantum communication as a drop-in substitute for standardized post-quantum algorithms on conventional platforms.
| Cryptographic function | Typical uses | Migration concern | Evidence |
|---|---|---|---|
| Key establishment | TLS, VPN, messaging and service connections | Negotiation, key and ciphertext sizes, compatibility | Protocol capture and implementation inventory |
| Digital signature | Code, firmware, documents, certificates and identity | Key and signature sizes, verifier support, longevity | Signing and verification path tests |
| Symmetric encryption | Stored and transmitted data after keys exist | Key size, mode and key management | Configuration and key lifecycle |
| Hashing | Integrity, signatures and identifiers | Purpose and security strength | Algorithm and dependent protocol |
| Certificates and PKI | Bind names to public keys | Profiles, issuance, revocation and relying parties | Certificate chain and policy |
| Random generation | Keys, nonces and protocol safety | Entropy and implementation assurance | Module and platform evidence |
Create a migration program with business ownership
Assign an executive sponsor, program lead, cryptography architect, security, enterprise architecture, application, infrastructure, procurement, legal, privacy, records and business continuity roles. Name owners for each critical service. Define authoritative standards sources and a decision process. The program should coordinate with certificate management, zero trust, software supply chain, hardware lifecycle and cloud modernization work. Do not create a separate inventory that immediately diverges from configuration and asset systems; add cryptographic relationships to governed records and reconcile them.
Set policy now for new procurement and design. Require suppliers to disclose quantum-vulnerable dependencies, roadmap, supported standards, update mechanism, hardware constraints and customer action. New custom systems should avoid hard-coded algorithms and undocumented cryptographic libraries. Exceptions need owner and expiry. Governance should prevent two opposite failures: deploying immature or unsupported implementations prematurely, and acquiring long-lived systems that cannot transition when approved support is available.
Discover cryptography as a dependency graph
Inventory assets, but record usage: business service, data or assertion protected, function, algorithm, parameter, library or module, protocol, certificate, key location, endpoint, supplier, environment, owner and replacement path. Scan network handshakes, code and binaries, configuration, certificate stores, hardware security modules, key managers, package manifests and device firmware. Automated tools improve reach but produce blind spots and uncertain attribution. Validate discoveries with system owners and representative transaction traces.
Include cryptography embedded in operating systems, databases, load balancers, APIs, service meshes, VPNs, email, file transfer, backups, archives, mobile apps, payment devices, industrial systems, identity tokens, document signatures and update chains. Map producer and consumer: changing a signing service is useless if relying devices cannot verify. Record confidence and last observation. Unknown cryptography on a critical path is itself a risk item. Reconcile inventory with change and procurement events so it remains current.
Prioritize with exposure, longevity and lead time
For confidentiality, compare the required secrecy life with a conservative threat horizon and migration duration. Data valuable for decades may need earlier treatment than short-lived operational messages. For authenticity, consider how long signed software, firmware, documents or credentials must remain trusted and whether they can be re-signed. Add internet exposure, business criticality, safety, regulatory duties, supplier readiness, replacement windows and concentration. Avoid a single invented quantum date or score that hides these distinct drivers.
Create cohorts: immediate discovery and procurement controls; laboratory interoperability for high-priority paths; vendor-led upgrades; custom application remediation; constrained legacy and operational technology; archival and long-term signature strategy. Identify quick improvements such as upgrading unsupported libraries, removing obsolete protocols and centralizing certificate ownership, but do not label ordinary crypto hygiene as completed PQC migration. Maintain separate current-risk and future-transition backlogs so known classical weaknesses are not deferred.
| Priority factor | Question | Planning implication |
|---|---|---|
| Secrecy life | How long would disclosure still cause harm? | Long-lived data moves earlier |
| Signature life | How long must authenticity remain verifiable? | Plan verifier and archival transition |
| Migration lead time | When can hardware, software and partners change? | Start constrained ecosystems sooner |
| Exposure | Can traffic or artifacts be collected externally? | Prioritize reachable valuable paths |
| Dependency breadth | How many producers and consumers must interoperate? | Fund coordinated testing |
| Replaceability | Can the component be updated or isolated? | Create compensating or retirement plan |
Turn supplier claims into roadmap evidence
Ask suppliers for affected products and versions, cryptographic bill of materials where available, supported NIST standards and parameters, protocol or certificate dependencies, hybrid mode, performance evidence, validation plans, release dates, licensing, upgrade path, rollback, support lifetime and telemetry. Ask what the customer must configure and whether data or keys move. Contract for notice when cryptographic dependencies or roadmaps change. Assess subcontractors and shared libraries because a primary vendor may not control every layer.
Procurement should avoid promises detached from shipping versions. Demonstrations need representative clients, servers, intermediaries, accelerators, inspection devices and certificate services. Confirm failure with legacy peers and resistance to downgrade. Preserve test artifacts and product identifiers. For managed cloud services, document shared responsibility: the provider may update transport or key management, while customer applications, private certificates, client libraries and connected products remain customer work.
Run interoperability and performance pilots
Choose a nonproduction path that represents high-priority constraints. Establish classical baseline, then test the approved post-quantum or supported hybrid configuration. Measure handshake and signing latency, CPU, memory, network bytes, certificate and artifact size, throughput, timeouts, storage and constrained-device behavior. Include proxies, gateways, monitoring and security tools. Larger messages can expose fragmentation, buffer or protocol assumptions. Performance must be evaluated at service load and failure, not a single successful connection.
Test key generation, distribution, rotation, revocation, backup, restore, compromise response and algorithm rollback. Verify negotiation does not silently fall back below policy. Capture observability that distinguishes algorithms and failures without leaking key material. Run mixed-version deployment, expired certificates, malformed inputs and disaster recovery. Independent implementation review and applicable validation matter for high-assurance use. A laboratory success becomes a migration pattern only after owners understand operational and support implications.
Build a staged roadmap and cryptographic agility
Use phases: govern, discover, prioritize, prepare, pilot, migrate, verify and retire. Each wave should name services, dependencies, owner, standards profile, supplier commitments, test plan, budget, deployment window, rollback and acceptance evidence. Progressive rollout reduces correlated failure. Reconcile inventory after deployment and remove obsolete keys, algorithms, certificates and configuration where policy allows. Preserve records needed to validate historical signatures or decrypt retained data, with controlled access and documented transition.
Cryptographic agility means algorithms, parameters, keys and providers can change through governed interfaces without rewriting unrelated business logic. Centralize policy and inventory, but avoid one universal library becoming an uncontained failure domain. Use standard protocol negotiation carefully, version data formats, expose capability metadata, automate certificate and key lifecycle, and test alternate configurations. Agility is demonstrated by an exercised change and recovery process, not by an abstraction layer on a diagram.
Frequently asked questions
Should organizations deploy PQC now?
They should plan now and deploy standards-based capabilities when supported for the use case, following applicable guidance and validation requirements. Begin inventory, prioritization, procurement and pilots immediately. Avoid proprietary algorithms or unsupported production changes made only to claim readiness.
Does a quantum computer break all encryption?
The principal migration focus is current public-key cryptography. Quantum algorithms affect symmetric security differently, and appropriate key sizes and standards guidance matter. Do not replace sound symmetric encryption blindly; inventory the complete protocol and follow authoritative profiles.
How is migration completion proven?
Define completion per service: inventoried dependencies, approved profile, interoperable supported implementations, tested performance and recovery, deployed configuration, monitored behavior, retired vulnerable paths and updated records. An organization-wide badge without service evidence is not meaningful.
Conclusion
PQC migration is a long dependency-management and engineering program, not a race to install one algorithm. Use current NIST standards and official guidance, build a cryptographic usage graph, and prioritize from secrecy, authenticity, exposure and lead time. Make supplier commitments testable, pilot complete protocol paths and preserve rollback and recovery. By turning cryptographic agility into an exercised operating capability, the organization can address quantum risk while also becoming better prepared for ordinary algorithm, library and certificate changes.