Why You Need a PQC Migration Roadmap Now
The last time the industry faced a large-scale cryptographic migration replacing RSA with Elliptic Curve Cryptography (ECC) the transition took more than a decade. Many organizations never finished it.
The migration to post-quantum cryptography will be an order of magnitude harder. PQC algorithms introduce larger key sizes, new security requirements, multiple algorithm families, and potentially several migration stages including interim periods where hybrid classical and post-quantum algorithms run in parallel. Unlike the ECC transition, this migration may need to happen in compressed timelines, driven by the growing threat of quantum-capable adversaries and regulatory deadlines like CNSA 2.0.
Without a structured roadmap, organizations risk a reactive scramble once quantum threats materialize. With one, the transition becomes a controlled, phased process that protects critical data at every stage.
This guide walks through six steps to build a PQC migration roadmap that moves your organization from assessment to action.
Step 1: Discover and Inventory Your Cryptographic Assets
You cannot migrate what you cannot see. The first step is building a comprehensive inventory of every cryptographic asset across your enterprise.
What to discover
Your inventory should include:
- Certificates and keys every X.509 certificate, TLS key, code-signing key, and SSH key in use
- Algorithms and protocols which cryptographic algorithms each system relies on (RSA, ECDSA, AES, etc.) and the protocols that use them (TLS, IPsec, S/MIME)
- Cryptographic libraries the software libraries implementing cryptography across your applications
- Hardware security modules (HSMs) devices storing and managing keys, which may need firmware or hardware upgrades for PQC support
- Network endpoints, cloud workloads, and CI/CD pipelines anywhere certificates are issued, rotated, or validated
- IoT and remote devices embedded systems and field-deployed hardware with long lifecycles and limited update capabilities
Why manual approaches fail
Even discovering all the cryptographic artifacts in a large organization is a difficult task. Certificates are issued and revoked constantly, cloud workloads spin up and down, and development teams embed cryptographic dependencies without centralized tracking. Manual audits are impractical at enterprise scale.
Automated discovery tools are essential. They provide the baseline map of cryptographic usage that feeds every subsequent step in the roadmap and they enable continuous monitoring so your inventory stays current as your environment changes.
Key takeaway:
If you don’t know where your cryptography lives, you can’t assess your quantum risk, prioritize your migration, or measure your progress. Start here.
Step 2: Classify and Prioritize Based on Risk
Not all systems face the same quantum risk. Once you have visibility, classify your cryptographic assets based on four factors:
Risk classification framework
Data sensitivity
What is the confidentiality requirement? Health records, trade secrets, government intelligence, and financial data demand the strongest protection.
Confidentiality lifespan
How long must this data remain confidential? Data that requires protection for a decade or more faces the most urgent quantum risk.
System longevity
How long will this system remain in service? Automotive ECUs, satellites, and medical implants cannot be easily updated once deployed.
Difficulty of replacement
Can you update this system with a software patch, or does it require expensive hardware upgrades? Systems requiring changes need earlier planning.
HNDL: The primary driver for encryption-first prioritization
The most pressing quantum risk is not a future attack it is happening now. In a Harvest Now, Decrypt Later (HNDL) attack, adversaries intercept and store encrypted data today, planning to decrypt it once a cryptographically relevant quantum computer (CRQC) becomes available.
Any data requiring long-term confidentiality is vulnerable to HNDL right now. This makes key establishment protocols the highest-priority migration target: if the key exchange is compromised, the encryption key and all data it protects are exposed.
Digital signature algorithms face a different risk profile. A signature can only be forged after a CRQC exists, not retroactively. This means signature migration is urgent for systems with long hardware lifecycles (where the design and deployment stages may extend beyond the CRQC timeline) but less time-sensitive than encryption migration for data-at-rest scenarios.
Regulatory deadlines
Any systems subject to compliance requirements should be mapped against regulatory timelines. The NSA’s CNSA 2.0 mandates a staggered migration to PQC algorithms by use case, with initial deadlines . Organizations in regulated industries should align their prioritization with these external deadlines.
Key takeaway:
Prioritize encryption migration for long-lived confidential data (HNDL risk), hen address signature migration for long-lifecycle hardware. Map everything against regulatory timelines.
Step 3: Choose Your Migration Strategy
There is no single right migration path. The best strategy depends on your risk profile, compliance requirements, and technical constraints. Most organizations will use a combination of approaches across different systems.
Staged migration: Protect confidentiality first
The staged approach migrates key establishment protocols to PQC first, addressing HNDL risk, then migrates digital signatures in a second phase.
The logic behind:
Key establishment migration is less disruptive than signature migration. PQC signatures are significantly larger than their classical counterparts, and certificate chains require multiple signatures meaning signature migration may demand larger architectural changes. By securing key establishment first, you protect confidentiality with relatively less effort while deferring the more complex PKI changes.
Certain protocols are already being standardized with this two-step migration in mind, ensuring post-quantum security for confidentiality properties while maintaining classical-computer-only security for authentication during the interim.
Best for:
Organizations with significant HNDL exposure that need to protect confidentiality quickly without disrupting their full PKI infrastructure.
Hybrid cryptography: Belt and suspenders
Hybrid algorithms combine a classical algorithm and a PQC algorithm so that the system remains secure as long as at least one algorithm is unbroken.
The logic behind:
PQC algorithms are newer, and their security risks are not yet fully understood. The SIKE algorithm which advanced to the final round of NIST’s standardization process before being completely broken by a classical computer attack demonstrates that even vetted can fail. Hybrid cryptography hedges against this uncertainty.
Trade-offs:
Hybrid approaches add complexity, produce larger cryptographic artifacts, introduce slower performance, require more code and testing, and create an additional migration step the eventual transition from hybrid to pure PQC. Hybrid is a transitional measure, not a destination.
Hybrid KEMs (key encapsulation mechanisms) are less costly than hybrid signatures because KEMs are ephemeral and do not require long-term identity infrastructure. Hybrid signatures, by contrast, involve persistent keys, certificates, and the full trust infrastructure, including a dual migration of PKI.
Best for:
Risk-averse organizations or those operating in environments where the consequences of a PQC algorithm failure would be severe.
CNSA 1.0 and CNSA 2.0: Following the government path
For organizations aligned with U.S. government requirements, the NSA’s two-suite approach provides a defined migration path:
CNSA 1.0 uses traditional algorithms with larger parameters that will resist quantum attacks longer than standard configurations. It buys time, but it is explicitly not a long-term strategy. It may only delay the problem by a couple of years.
CNSA 2.0 specifies PQC algorithms standardized by NIST, intended for long-term use. The migration to CNSA 2.0 will happen in a staggered manner, with the NSA providing use-case-specific timelines.
Best for:
Government contractors, defense organizations, and any entity required to comply with NSA cryptographic guidance. Organizations requiring high level security may consider this option as best practice.
Cryptographic Agility
Cryptographic agility is the ability of an organization to systematically manage algorithms, protocols, keys or any cryptographic asset without causing operational disruption. Regardless of which strategy you choose, cryptographic agility is the common enabler. A crypto-agile architecture lets you switch strategies or combine approaches without redesigning your systems from scratch.
Step 4: Prepare Your PKI Infrastructure
PKI is the backbone of digital identity and trust, and it is often the most complex and time-consuming piece of any PQC migration. Migrating PKI is not a simple certificate reissue. It requires updating certificate authorities, validation paths, and every system that depends on the certificate chain.
Why PKI is a gating factor
Every digital certificate, every authenticated connection, and every signed artifact in your organization flows through PKI. Until your PKI infrastructure supports PQC algorithms, broader PQC adoption is blocked regardless of how ready your applications or protocols are.
The PQC signature size challenge
The PQC signature algorithms standardized by NIST so far produce significantly larger signatures than their classical counterparts. Certificate chains typically require multiple certificates and therefore multiple signatures meaning the size increase compounds across the chain. This can break assumptions baked into existing protocols, network buffers, and storage systems.
Larger signatures also create downstream performance impacts: increased bandwidth usage, more round trips in handshake protocols, and potential denial-of-service vulnerabilities where oversized messages degrade HSM performance.
Preparing for the transition
Test PQC and hybrid certificates in non-production environments first.
Validate that your certificate authorities can issue PQC certificates and that your validation paths handle the larger artifacts correctly.
Plan for coexistence.
During the transition period, your infrastructure will need to support both classical and PQC certificates simultaneously. Systems that validate certificates must handle both types without breaking.
Update trust anchors systematically.
Root certificates and intermediate CAs need to be migrated on a coordinated schedule updating leaf certificates without updating the trust chain above them .
Coordinate with partners and vendors.
Any system that exchanges certificates with external parties requires alignment on PQC certificate support timelines.
Key takeaway:
PKI readiness is a prerequisite for broader PQC migration. Start preparing your certificate infrastructure early will be critical .
Step 5: Test, Validate, and Deploy in Phases
Never go straight to production. PQC algorithms have fundamentally different performance characteristics than classical algorithms, and assumptions that held for decades may not survive the transition.
What to test
Bandwidth and latency:
PQC artifacts are much larger, resulting in increased bandwidth usage and more round trips in handshake protocols. Measure the impact on your specific network conditions and application requirements.
HSM throughput:
PQC signature algorithms typically process the entire message internally, which can degrade performance for large messages particularly on HSMs. Pre-hashing can mitigate this but adds implementation complexity.
Interoperability:
Test PQC and hybrid configurations against every partner, vendor, and dependent system that exchanges cryptographic artifacts with your infrastructure. The variety of hybrid combinations can create interoperability challenges.
Certificate chain validation:
Verify that the full chain from root CA to leaf certificate works correctly with PQC signatures across all consuming applications.
Phased rollout with rollback
Plan your deployment in phases with explicit rollback capabilities at each stage. When you are changing foundational security infrastructure, the ability to revert is not optional it is essential.
A crypto-agile architecture makes both rollout and rollback significantly easier. With crypto agility in place, algorithms can be swapped through policy changes rather than code changes, reducing the risk and effort of each deployment phase.
Validation checklist
Isolated environment testing
Validate all PQC algorithms and hybrid configurations in a dedicated test environment before any production exposure.
Performance baseline comparison
Benchmark PQC performance against your current classical implementation across all critical metrics (latency, throughput, resource utilization).
Partner readiness verification
Confirm that external systems consuming your certificates or encrypted data can handle PQC artifacts.
Rollback procedure testing
Verify that you can revert to classical algorithms cleanly if issues arise during deployment.
Monitoring and alerting
Establish continuous monitoring for performance degradation, certificate validation failures, and interoperability issues post-deployment.
Key takeaway:
Test thoroughly, deploy incrementally, and always maintain the ability to roll back. Crypto agility reduces the testing burden but does not eliminate it.
Step 6: Plan for Continuous Algorithm Evolution
PQC migration does not end when you deploy your first quantum-resistant algorithms. The cryptographic landscape will continue to evolve, and your roadmap must account for ongoing change.
The standards landscape is still shifting
NIST has standardized five PQC algorithms so far, additional algorithms are in the pipeline particularly signing algorithms optimized for different use cases. Each new algorithm will offer different trade-offs in key sizes, signature sizes, efficiency, and security properties.
Beyond NIST, other standards bodies are running their own processes. Germany’s BSI has recommended its own suite of PQC algorithms, including some not chosen by NIST. Korea, China, and Russia are holding independent standardization projects with the aim of standardizing algorithms for use within their jurisdictions. Organizations operating globally may need to support multiple algorithm families simultaneously.
No one-size-fits-all algorithm
The “best” PQC algorithm for a given use case depends heavily on the hardware and operational context. In constrained devices IoT sensors, embedded controllers, smart cards the trade-offs between key size, signature size, and computational efficiency can dramatically affect throughput and viability. The optimal algorithm for a cloud TLS endpoint is not the same as the optimal algorithm for a satellite communications link.
This means algorithm selection is not a one-time decision. As new algorithms are standardized and existing ones are better understood, organizations will need to update their selections.
Crypto agility as a permanent capability
The best way to prepare for ongoing algorithm evolution is to build cryptographic agility as a permanent operational capability, not just a tool for the initial PQC migration. With a crypto-agile architecture and a policy-driven management platform, cryptographic artifacts can be replaced according to updated policies without redesigning systems or rewriting code.
As NIST notes, “crypto agility is a key practice that should be adopted at all levels, from algorithms to enterprise architectures.”
Key takeaway:
Design your systems to accommodate future algorithm changes. The PQC migration is not a one-time project it is the beginning of an ongoing cryptographic management discipline.
How Keyfactor Can Help
Each step of the PQC migration roadmap maps directly to capabilities within Keyfactor’s platform:
Discovery and inventory (Step 1):
Keyfactor Agilesec provides automated discovery that builds a complete cryptographic asset inventory across applications, devices, cloud workloads, and infrastructure, giving you the visibility foundation the entire roadmap depends on.
PKI readiness (Step 4):
EJBCA delivers built-in support for quantum-resistant and hybrid certificates, enabling your certificate authorities to issue PQC certificates today. SignServer enables code signing with NIST PQC algorithms, extending quantum-resistant signing to your software supply chain.
Phased deployment (Step 5):
Keyfactor Command automates certificate lifecycle management – renewal, provisioning, and revocation at scale – enabling organizations to swap cryptographic algorithms without disruptioning and rolling back if needed.
Ongoing evolution (Step 6):
Bouncy Castle APIs in Java and C# let product teams integrate PQC algorithms into their applications today, with the flexibility to adopt new algorithms as they are standardized. Policy-driven management supports future algorithm changes without architecture redesign.
The Bottom Line
The organizations that start building their PQC migration roadmap today will transition to quantum-resistant cryptography on their own terms. Those that wait will face compressed timelines, limited options, and elevated risk.
The six steps in this guide are not a one-and-done checklist. They are the foundation of an ongoing cryptographic management discipline: start with visibility, prioritize by risk, choose the right migration strategy for each system, prepare your PKI infrastructure, test and deploy in phases, and build the operational capabilities to adapt as the landscape evolves.
In cryptography, “later” often means “too late.” The roadmap starts now.
