What Is NIST-PQC Migration?

NIST-PQC Migration Explained

NIST-PQC migration prepares organizations to replace vulnerable public-key cryptography with quantum-resistant algorithms standardized by the National Institute of Standards and Technology. The migration affects the cryptographic foundations used across enterprise security, including identity, authentication, certificates, TLS, VPNs, software signing, secure boot, and encrypted communications.

The urgency comes from the risk that future cryptographically relevant quantum computers could break widely used public-key algorithms such as RSA, elliptic curve cryptography, and Diffie-Hellman. While large-scale quantum computers capable of breaking these systems do not yet exist, adversaries can already collect encrypted data today and store it for future decryption.

This threat is known as harvest now, decrypt later, or HNDL. For organizations that protect long-lived sensitive data, the risk is immediate because the exposure begins when encrypted data is captured, not when quantum computers become available.

Preparing for NIST-PQC migration is not simply a technical upgrade. It requires enterprise-wide planning across security, IT, engineering, compliance, procurement, vendor management, and executive leadership.

Figure 1: Harvest Now, Decrypt Later Lifecycle

Recommended Reading: What Is Q-Day?

Why Organizations Need to Prepare Now

Adversaries are currently recording encrypted traffic from high-value targets with the intent to decrypt it once a quantum computer is available. Unit 42’s 2026 Global Incident Response Report highlights that AI has compressed the attack lifecycle, allowing threat actors to move from initial access to data exfiltration in as little as 72 minutes.

Migration to NIST PQC will take years for many enterprises. Cryptography is deeply embedded in applications, devices, cloud services, third-party tools, network infrastructure, and identity systems.

Many organizations lack full visibility into where cryptography exists, which algorithms are in use, or which systems depend on vulnerable public-key methods.

Delaying preparation creates several risks:

• Sensitive data may be harvested now and decrypted later.
• Legacy systems may become more difficult and more expensive to upgrade.
• Vendors may not be ready when migration pressure increases.
• Compliance expectations may outpace internal readiness.
• Organizations may lack the required inventory to prioritize risk.
• Critical systems may experience performance or interoperability issues during a rushed migration.

The practical goal is not to replace every algorithm immediately. The first goal is to understand exposure, build a migration roadmap, and make sure future systems can support post-quantum cryptography.

NIST-PQC Standards Organizations Need to Understand

Security leaders should understand which NIST standards affect enterprise migration planning.

FIPS 203: ML-KEM for Key Exchange

FIPS 203 defines ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism. ML-KEM is designed for quantum-resistant key exchange and is expected to be used in areas such as TLS, VPNs, and secure session establishment.

Organizations should evaluate where current systems use RSA, Diffie-Hellman, or elliptic curve cryptography for key exchange. These systems are likely candidates for future ML-KEM support or hybrid deployment.

FIPS 204: ML-DSA for Digital Signatures

FIPS 204 defines ML-DSA, the Module-Lattice-Based Digital Signature Algorithm. ML-DSA supports quantum-resistant digital signatures for identity, software signing, certificates, secure boot, and supply chain validation.

Organizations should identify systems that depend on digital signatures to prove trust, authenticity, or integrity. These may include software update pipelines, code-signing systems, certificate authorities, identity providers, and device authentication workflows.

Unit 42 research indicates that 23% of incidents involve attackers abusing trusted SaaS integrations. Digital signatures are mandatory because they prove that an identity, message, update, or transaction has not been forged or altered. As quantum risk grows, organizations will need quantum-resistant signature schemes to maintain trust in software, devices, users, and services.

FIPS 205: SLH-DSA for High-Assurance Signatures

FIPS 205 defines SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm. SLH-DSA provides a hash-based signature option that can serve as a conservative fallback where long-term assurance is more important than speed or compact signature size.

Organizations should consider SLH-DSA for high-assurance signing use cases where long-term integrity matters and larger signatures are acceptable.

Steps to a Successful PQC Migration

Migrating to post-quantum cryptography requires more than swapping out encryption algorithms. Organizations need a phased approach that identifies where cryptography is used, assesses quantum-related risk, prioritizes vulnerable systems, establishes governance, and updates security controls without disrupting business operations. The following eight steps provide a practical roadmap for moving from cryptographic discovery to quantum-safe readiness.

Step 1: Build a Cryptographic Inventory

Organizations cannot migrate what they cannot see. The first step in NIST-PQC preparation is a cryptographic inventory across applications, infrastructure, cloud environments, endpoints, identities, and third-party systems.

A cryptographic inventory should document:

The inventory should also identify business owners, technical owners, data sensitivity, system criticality, and migration complexity.

This step usually exposes uncomfortable truths: shadow IT, expired certificates, legacy applications, unmanaged cryptographic libraries, and systems no one wants to admit are still running. That is exactly why the inventory matters.

Step 2: Identify Data at Risk from Harvest Now, Decrypt Later Attacks

Not every system needs the same migration urgency. Organizations should prioritize data based on how long it must remain confidential.

High-risk data includes:

• National security information
• Trade secrets
• Intellectual property
• Medical records
• Financial records
• Legal communications
• Personally identifiable information
• Critical infrastructure data
• Long-term customer or citizen records

A simple way to prioritize is to ask:

If this encrypted data were stolen today and decrypted in 5, 10, or 15 years, would it still cause harm?

If the answer is yes, the system should move higher on the NIST-PQC migration roadmap.

Step 3: Prioritize Systems for Migration

After inventorying cryptographic assets and identifying sensitive data, organizations should rank systems by risk and business impact.

Priority should go to systems that:

• Transmit or store long-lived sensitive data
• Use RSA, ECC, or Diffie-Hellman for key exchange
• Support identity, authentication, or trust decisions
• Rely on digital signatures for software integrity
• Connect to critical infrastructure
• Support regulated workloads
• Depend on third-party cryptographic libraries
• Have long procurement or replacement cycles
• Are difficult to patch or update

Common high-priority systems include:

The migration roadmap should balance quantum risk, business criticality, operational complexity, and vendor readiness.

Step 4: Create a NIST-PQC Governance Program

NIST-PQC migration cuts across many teams, so it needs governance. A dedicated PQC working group or center of excellence can help coordinate strategy, ownership, budget, and execution.

The governance group should include representatives from:

• Security
• IT
• Network engineering
• Cloud engineering
• Application development
• Identity and access management
• Legal
• Compliance
• Procurement
• Vendor management
• Risk management
• Executive leadership

This group should own:

• Cryptographic inventory standards
• Risk prioritization
• Migration roadmap
• Vendor requirements
• Procurement language
• Testing requirements
• Compliance alignment
• Budget planning
• Executive reporting

Without governance, PQC migration can become scattered across teams, tools, and vendors. That leads to duplicated work, inconsistent decisions, and avoidable risk.

Step 5: Build Crypto-Agility into the Environment

Crypto-agility is the ability to replace cryptographic algorithms, keys, libraries, and protocols without redesigning major systems. It is one of the most important requirements for NIST-PQC migration because standards, vendor implementations, and best practices will continue to evolve.

Organizations can improve crypto-agility by:

• Centralizing cryptographic libraries
• Avoiding hardcoded algorithms
• Using configurable cryptographic policies
• Standardizing certificate and key management
• Maintaining accurate cryptographic asset ownership
• Building algorithm replacement into software development practices
• Requiring vendors to support cryptographic updates
• Testing fallback and rollback procedures

Crypto-agility also protects organizations beyond the quantum transition. If a future vulnerability affects a cryptographic algorithm or implementation, agile environments can respond faster and with less disruption.

Step 6: Evaluate Hybrid Cryptography

During the transition to post-quantum cryptography, many organizations will use hybrid cryptographic deployments. Hybrid approaches combine a classical algorithm, such as ECDH, with a post-quantum algorithm, such as ML-KEM.

Hybrid cryptography helps organizations maintain current security while adding quantum resistance. If a post-quantum algorithm or implementation later reveals an issue, the classical algorithm still protects against conventional attacks during the transition period.

Organizations should consider hybrid deployment for:

• TLS
• VPNs
• mTLS
• API communications
• Secure remote access
• High-value data exchange
• Cloud-to-cloud communications
• Critical business applications

Hybrid deployment should be tested carefully because it can increase handshake size, affect latency, and create interoperability issues with existing infrastructure.

Step 7: Test Performance and Interoperability

NIST-PQC migration can affect performance because post-quantum keys, ciphertexts, and signatures are often larger than classical equivalents. That does not mean migration is impractical, but it does mean organizations need testing before production rollout.

Testing should evaluate:

• TLS handshake size
• Packet fragmentation
• Latency
• Load balancer behavior
• Firewall inspection
• VPN negotiation
• Certificate chain size
• Memory consumption
• CPU usage
• IoT and mobile device constraints
• Application compatibility
• Failure and rollback behavior

For example, larger PQC signatures may affect certificate chains, software signing, or constrained devices. Larger key exchange payloads may affect TLS handshakes, VPNs, and network appliances.

The goal is to identify these issues early, not during an emergency migration window.

Step 8: Align Vendors, Procurement, and Contracts

NIST-PQC migration depends heavily on vendor readiness. Many organizations rely on third-party products for identity, cloud services, network security, endpoint security, application delivery, certificate management, and software development.

Procurement and vendor management teams should require vendors to answer:

• Do you support NIST PQC standards?
• Which standards do you support: ML-KEM, ML-DSA, SLH-DSA?
• Do you support hybrid cryptography?
• What is your PQC roadmap?
• Can your product support crypto-agility?
• Which cryptographic libraries do you use?
• How are certificates, keys, and algorithms managed?
• What customer configuration changes are required?
• What performance impacts should we expect?
• What is the migration timeline?

New technology purchases should include PQC readiness and crypto-agility requirements. Otherwise, organizations may keep buying systems that become future migration problems.

NIST-PQC Migration Checklist

Organizations preparing for NIST-PQC migration can use the following checklist to assign ownership, prioritize risk, and sequence work across security, IT, compliance, procurement, and vendor teams.

Common NIST-PQC Migration Challenges

Limited Cryptographic Visibility

Many organizations do not know where cryptography is used. This is the biggest blocker to migration. Without visibility, teams cannot prioritize systems, estimate cost, or understand risk.

Legacy and Embedded Systems

Older applications, IoT devices, OT systems, and embedded technologies may not support modern cryptographic updates. These systems may require compensating controls, vendor replacement, or longer migration timelines.

Vendor Dependencies

Many enterprise systems rely on vendor-managed cryptography. If vendors do not support NIST-PQC standards or crypto-agility, internal migration plans may stall.

Performance and Compatibility Issues

Post-quantum cryptography can increase payload sizes and affect network behavior. Organizations need testing to avoid problems with load balancers, firewalls, certificates, and latency-sensitive applications.

Lack of Ownership

PQC touches security, IT, legal, compliance, engineering, and procurement. Without clear ownership, teams may assume someone else is handling it. Spoiler: that usually ends badly.

NIST-PQC Migration FAQs