PQC Migration: A Complete Guide to Post-Quantum Cryptography Migration

This guide covers the strategies, challenges, regulatory pressures, and practical realities of migrating to quantum-resistant cryptography. It is designed for security leaders, IT architects, and compliance teams who need to understand the full scope of the effort ahead and start building their migration roadmap.

Why PQC Migration Cannot Wait

There have been several migration efforts in the past: every version of TLS, starting from SSL, to TLS 1.0 to 1.3, SHA-1 to SHA-2/SHA-3, DES to 3DES to AES, and the key-size upgrade of RSA from 1024 to 2048/3072. However, the most comparable precedent for the PQC transition is the migration from RSA to Elliptic Curve Cryptography (ECC), since that implied a change in algorithms, underlying mathematical assumptions, as well as changes that needed to be made to the protocols that use those algorithms. That transition to ECC took more than a decade, and many organizations never completed it. The migration to PQC will be an order of magnitude more difficult, given the inherent challenges of larger key sizes, new security requirements, multiple migration stages, and the need for coordinated policy across entire enterprises.

Most experts agree that a cryptographically relevant quantum computer (CRQC) (one powerful enough to break traditional public-key cryptography) will exist within the next 5 to 10 years. The timeline is uncertain, but the outcome is not: once a CRQC is built, it will completely break the public-key algorithms that underpin virtually every secure communication on the internet today.

What makes this particularly dangerous is that nation-state adversaries will almost certainly not announce when they achieve this capability. The first CRQC may operate in secret, silently compromising encrypted communications before anyone realizes the threat has materialized.

Organizations cannot afford to wait for certainty. The complexity of PQC migration which spans discovery, strategy selection, testing, deployment, and ongoing management, means that starting late is functionally equivalent to starting too late.

The Harvest Now, Decrypt Later Threat: Why Encryption Migration Comes First

One of the most urgent drivers of PQC migration is the Harvest Now, Decrypt Later (HNDL) attack. This threat accounts for adversaries that are already intercepting and storing encrypted network traffic today, with the intention of decrypting it once a CRQC becomes available. This makes HNDL an immediate threat to confidentiality, not a future one.

Any organization protecting data that must remain confidential for a decade or more is functionally already exposed. Healthcare records, government communications, financial data, intellectual property, and long-term contractual information are all at risk from harvest now, decrypt later attacks.

This threat directly shapes migration priorities. To counter HNDL, the key establishment protocols used during encrypted communications must be quantum-safe. These are the mechanisms that negotiate the shared encryption key during a TLS handshake or similar exchange protocol. If the key establishment is compromised, the entire session is exposed, including all symmetrically encrypted data.

Digital signatures (used for authentication), by contrast, face a different risk profile. A digital signature only needs to be secure at the moment it is verified. An adversary cannot retroactively forge a signature that was already validated using a traditional algorithm. This means digital signature migration, while still necessary before a CRQC exists, does not carry the same retroactive urgency.

This asymmetry creates a clear prioritization framework:

1. Migrate key establishment protocols to PQC first to protect confidentiality against HNDL attacks happening today.
2. Migrate digital signature algorithms to PQC second to protect authentication and integrity before a CRQC is built.

Certain protocols are already being standardized with this two-step approach in mind, providing PQC security guarantees for confidentiality while retaining traditional algorithms for authentication as an interim measure.

Migration Strategies: Choosing the Right Path

PQC migration is fundamentally a risk management exercise. There is no single correct approach. The right strategy depends on an organization’s risk tolerance, compliance obligations, operational constraints, and the sensitivity of the data it protects. Not all organizations have the same needs or can take the same risks. Choosing the right approach is a combination of balancing all the risks involved and the resources available. Below, we describe the pros and cons of each approach.

Prioritizing Confidentiality: Encryption First, Then Full PQC

The staged approach described above (migrating key establishment protocols first, then addressing digital signatures) is one of the most practical strategies available. It allows organizations to address the most urgent threat (HNDL) with relatively less effort, while deferring the more complex signature migration.

Pro: The rationale behind this approach is as follows. PQC digital signatures (the ones that have been so far standardized by NIST) are significantly larger than their traditional counterparts. This has a downstream effect on protocols that use digital signatures. In X.509 certificate chains, for example, which are used in TLS, because certificate chains require multiple certificates (and consequently multiple signatures) the increased size can require significant architectural changes to the PKI to handle PQC certificate chains. In this approach, organizations are addressing the HNDL threat by deploying PQC encryption first, while simultaneously building a plan to properly address these structural challenges to fit PQC signatures.

Con: However, there are cases where digital signature migration is also urgent. Hardware with long design and deployment lifecycles (i.e. devices that will be in the field for decades) may need PQC digital signatures integrated now, during the design phase, because they cannot be easily updated once deployed.

Con: In contrast to what was said above, because signatures are a foundational component of large-scale PKI, it is also important to start planning PKI migration well in advance. It is necessary to migrate the entire certificate chain, which takes a significant amount of effort. For more details, see the subsection below on PKI migration.

Hybrid Cryptography: Hedging Against Unknown Risks

Some organizations are concerned that PQC algorithms, being newer, may harbor undiscovered vulnerabilities. This concern is not theoretical. As a matter of fact, the PQC algorithm SIKE made it to the final round of NIST’s standardization process before researchers discovered it was completely breakable by a classical computer. While this does not imply that every PQC algorithm has undiscovered vulnerabilities, it does provide a reason to exercise precautions.

Pro: Hybrid cryptography addresses this uncertainty by combining a traditional algorithm with a PQC algorithm so that the system remains secure (if done properly) as long as either one is secure. From a security perspective, a well-designed hybrid approach offers the best of both worlds.

Con: Hybrid implementations are inherently more complex, producing larger cryptographic artifacts, requiring more code, and demanding more development and testing resources. They also create a follow-on migration obligation: once confidence in PQC algorithms is established, organizations will need to migrate again from hybrid to pure PQC.

Con: For key encapsulation mechanisms (KEMs), hybrid approaches are less costly because KEMs are ephemeral and do not require long-term identity infrastructure. Hybrid signatures, by contrast, involve persistent keys, certificates, and complex trust infrastructure, including the potential need for dual PKI migration.

NIST allows simple concatenation for deriving hybrid shared secrets, provided at least one component is generated by an approved mechanism. This flexibility can help organizations avoid delays while PQC algorithms complete certification processes.

CNSA 1.0 to CNSA 2.0: The Government Migration Path

The NSA has defined two cryptographic suites to guide organizations through the transition:

• CNSA 1.0 uses traditional cryptographic algorithms with larger parameters, providing marginally longer security against quantum attacks. It is an interim measure rather than a long-term solution. CNSA 1.0 only serves as a temporary bridge until PQC deployment.
• CNSA 2.0 specifies PQC algorithms standardized by NIST, intended for long-term use. The migration to CNSA 2.0 follows a staggered timeline, with NSA guidelines specifying when different use cases must transition.

Organizations operating within the U.S. defense supply chain or managing National Security Systems are expected to follow this two-migration path: first to CNSA 1.0 as a bridge, then to CNSA 2.0 as the permanent solution.

Pro: This allows organizations to remain compliant with the requirements imposed by the U.S. government.

Pro: This approach is also well-suited for organizations for which migration represents a significant risk and want to follow best practices.

Con: By design, this delays protection against the Harvest Now Decrypt Later threat, until CNSA 2.0 is deployed.

Summary and trade-offs

The tradeoffs corresponding to each approach can be summarized in the following table.

Criterion	Confidentiality First	Hybrid	CNSA 1.0 → CNSA 2.0
HNDL Mitigation	Immediate	Immediate	After CNSA 2.0
Compliance alignment	Medium	Medium	High
Engineering complexity	Medium	High	Medium
Number of migrations	2	2	2
PKI impact	Deferred initially	High	Medium
Protection against PQC algorithm uncertainty	Low	High	Low
Long-term quantum readiness	High (after signature migration)	High (after eventual simplification)	High (after CNSA 2.0)

As it is clear, every approach requires multiple migrations, either by prioritizing confidentiality, by migrating to hybrid first, or by performing parameter upgrades before PQC deployment. The key insight is that cryptographic agility is what makes managing multiple migration stages feasible. Without the ability to swap algorithms through policy-driven management, each migration becomes a costly, manual, error-prone project.

What Makes PQC Migration So Difficult in Practice

The theoretical case for PQC migration is straightforward. The practical execution is anything but. Several operational challenges make this transition harder than any previous cryptographic upgrade.

Discovering Your Cryptographic Footprint

Most organizations do not have a complete inventory of where and how cryptography is used across their infrastructure. Certificates, keys, algorithms, and their dependencies are embedded in applications, devices, cloud environments, network appliances, and third-party integrations.

Manual audits at enterprise scale are impractical. The discovery phase requires automated tooling capable of scanning across the entire environment to build a comprehensive cryptographic inventory. Without this inventory, organizations cannot prioritize what to migrate, assess their exposure to HNDL attacks, or build a realistic migration roadmap.

Discovery is not a one-time activity. As new systems are deployed and configurations change, the cryptographic inventory must be continuously maintained.

Hardware and Long-Lived Device Challenges

Software-based cryptography can be updated through patches and configuration changes. Hardware is a fundamentally different problem.

Hardware has long design cycles and can be extremely difficult to update once deployed – particularly when devices are spread across large geographic areas. Automotive systems, satellites, industrial sensors, medical implants, and IoT devices may operate for decades without the ability to receive firmware updates. These devices are hard to reach, spread over a large geographical area and have a long lifecycle.

For these devices, cryptographic agility must be designed in from the start. If the hardware cannot support algorithm replacement, it may need to be physically replaced a cost that dwarfs the investment in getting the design right initially.

Organizations must also determine whether their PQC migration can be accomplished through software updates alone, or whether more expensive hardware updates are required. This assessment should include not only internal systems but also vendor-supplied and niche systems, where migration planning may require vendor participation.

PKI Migration: The Most Complex Piece

PQC migration is not simply an algorithm swap. For organizations running public key infrastructure (PKI), it requires coordinated changes across entire trust hierarchies: root certificates, intermediate certificates, trust anchors, validation paths, and every system that depends on them. This migration is expected to take several years, from the discovery and planning to the complete PQC deployment.

PQC signatures are larger, which directly impacts PKI migration. Certificate chains that currently fit within standard protocol constraints may exceed size limits when PQC signatures are used. This can require redesigning certificate hierarchies, adjusting protocol implementations, or adopting new approaches to certificate validation.

For organizations using hybrid signatures, the complexity multiplies further. Dual migration of PKI infrastructure means maintaining parallel trust hierarchies during the transition period.

Performance and Interoperability Trade-Offs

PQC algorithms have fundamentally different performance profiles than traditional algorithms. Key sizes, signature sizes, ciphertext sizes, and computational requirements all differ, and the difference is often dramatic.

The practical consequences may include:

• Increased bandwidth usage from larger cryptographic artifacts
• More round trips in protocol handshakes
• Potential for denial-of-service attacks exploiting the increased processing requirements
• HSM performance degradation for PQC signatures that process entire messages internally, rather than operating on pre-hashed digests
• Constrained device limitations where algorithm trade-offs can significantly affect throughput

Each PQC algorithm family offers distinct trade-offs across these dimensions. The “best” algorithm depends heavily on the specific hardware and use case, and the optimal PQC algorithm for some scenarios may not yet be standardized.

Dynamic algorithm negotiation, while necessary for crypto agility, can also introduce new attack surfaces including downgrade and confusion attacks. These risks require careful protocol design and continuous monitoring.

The Regulatory Landscape Driving PQC Migration Timelines

Regulatory pressure is compressing PQC migration timelines across industries and geographies. Organizations that treat migration as optional today may find themselves non-compliant tomorrow.

CNSA 2.0

The most concrete near-term deadline comes from the NSA: all new systems handling National Security Systems data must be compliant with CNSA 2.0. It is worth mentioning that deadlines started in 2025, and extend until 2033. This mandate affects not only government agencies but any organization operating within the U.S. defense supply chain.

The CNSA 2.0 timeline is staggered by use case, with the NSA providing specific guidelines for when different types of traditional public-key algorithms must be replaced by PQC algorithms. Organizations subject to these requirements need active migration programs now.

Global Government Guidance

The regulatory push extends well beyond the United States. Government agencies worldwide now recommend cryptographic agility alongside PQC migration planning:

• The White House issued National Security Memorandum NSM-10 directing federal agencies toward cryptographic modernization
• NIST published guidance emphasizing crypto agility as “a key practice that should be adopted at all levels, from algorithms to enterprise architectures”
• The Cybersecurity and Infrastructure Security Agency (CISA) and the National Cybersecurity Center of Excellence (NCCoE) have issued PQC migration advisories
• The UK’s National Cyber Security Center (NCSC) provides quantum-readiness guidance for critical infrastructure
• Germany’s Bundesamt für Sicherheit in der Informationstechnik (BSI) has recommended its own suite of PQC algorithms, including some being standardized by bodies other than NIST
• The Dutch Algemene Inlichtingen– en Veiligheidsdienst (AIVD) released guidance stating that “cryptographic agility helps with performing a smooth migration to PQC” and “helps with managing cryptography in general”

Different jurisdictions may impose divergent cryptographic requirements. Germany, Korea, China, and Russia are each running independent standardization projects, potentially requiring different algorithms within their jurisdictions. Global organizations face the added complexity of maintaining compliance across multiple regulatory regimes simultaneously.

From Planning to Execution: What a PQC Migration Looks Like

PQC migration is not a linear checklist, but rather, it is a continuous risk management process that will unfold over years. The specifics will vary by organization, but the broad arc follows a consistent pattern.

Discovery and inventory comes first. Organizations need automated tooling to build a complete picture of their cryptographic assets, including every certificate, key, algorithm, and protocol in use across their environment. Without this foundation, everything that follows is guesswork.

Risk assessment and prioritization determines what to migrate first. Systems protecting long-lived confidential data face the highest urgency due to HNDL exposure. Systems with long hardware lifecycles need early attention because of deployment lead times. Compliance-driven deadlines (like CNSA 2.0) create hard prioritization boundaries.

Strategy selection is where organizations choose their migration path, either staged, hybrid, direct to PQC, or some combination, based on their specific risk profile, infrastructure, and regulatory obligations.

Testing and validation must happen before production deployment, regardless of the migration strategy. PQC algorithms behave differently than traditional ones, and the interactions with existing systems, protocols, and hardware must be thoroughly validated to avoid new security vulnerabilities or downgrades of the performance.

Deployment and lifecycle management is where the migration becomes operational. Certificates need to be re-issued, protocols updated, configurations changed, and policies enforced, ideally through automated lifecycle management rather than manual intervention.

Ongoing evolution is the final and permanent stage. NIST continues standardizing additional PQC algorithms optimized for different use cases. Other standards bodies are standardizing their own selections. The “best” algorithm for a given use case will change over time. Organizations must design systems for cryptographic agility so that future algorithm transitions are policy-driven rather than project-driven.

Each migration strategy to PQC involves multiple intermediate steps:

1. Confidentiality first
   a move to confidentiality-only protocols, then to full PQC;
2. Hybrid
   a move to hybrid, then to pure PQC;
3. CNSA
   a move to CNSA 1.0, then to CNSA 2.0.

Each path has trade-offs. The common thread is that crypto agility, which is the ability to swap algorithms through policy rather than re-engineering, is what makes any of these paths manageable.

How Keyfactor Can Help

Keyfactor’s platform provides the operational infrastructure organizations need to execute PQC migration at enterprise scale. Rather than approaching migration as a series of disconnected projects, Keyfactor enables a unified, policy-driven approach across discovery, PKI readiness, certificate lifecycle management, and cryptographic library support.

Cryptographic Discovery and Inventory

Keyfactor’s automated discovery tool helps organizations build a complete inventory of cryptographic assets, including certificates, keys, algorithms, and their relationships, across applications, devices, cloud environments, and on-premises infrastructure. This visibility is the prerequisite for every subsequent migration step.

Quantum-Ready PKI Infrastructure

Keyfactor’s EJBCA platform delivers built-in support for quantum-resistant and hybrid certificates, allowing organizations to test and validate PQC algorithms in pre-production environments before committing to production deployment. SignServer enables code signing with NIST-standardized PQC algorithms, extending quantum readiness to software supply chain security.

Automated Certificate Lifecycle Management

Keyfactor Command automates certificate renewal, provisioning, and lifecycle management across the enterprise. During PQC migration, this capability is critical. It enables organizations to swap cryptographic algorithms at scale without manual intervention or operational disruption. When migration policies change, Command enforces them automatically.

Bouncy Castle Cryptographic APIs

Bouncy Castle APIs in Java and C# give product teams the ability to integrate PQC algorithms into software and hardware today. As the cryptographic library that underpins many enterprise security implementations, Bouncy Castle provides a path to PQC readiness at the code level, with expert support from the library’s developers through Keyfactor’s crypto-agility platform.

Got PQC Migration Questions?
We’ve Got Answers.