Table of Contents

What Is NIST-PQC Migration?

3 min. read

Table of Contents

NIST-PQC (post-quantum cryptography) migration is the process of preparing enterprise systems, applications, identities, certificates, and encrypted communications for post-quantum cryptography standards developed by the National Institute of Standards and Technology.

Organizations can prepare by inventorying cryptographic assets, prioritizing high-risk data, testing quantum-resistant algorithms, adopting crypto-agility, and aligning vendor, procurement, and compliance programs with NIST post-quantum cryptography requirements.

Key Points

Start with cryptographic discovery: Organizations need a complete inventory of where RSA, ECC, Diffie-Hellman, certificates, keys, and cryptographic libraries are used.
Prioritize long-lived sensitive data: Data that must remain confidential for years is most exposed to “harvest now, decrypt later” attacks.
Adopt crypto-agility: Security teams need architectures that allow algorithms to be replaced without major system redesign.
Test before production: NIST-PQC algorithms can increase key sizes, signature sizes, packet sizes, and latency.
Align vendors and procurement: New systems should support NIST post-quantum cryptography standards and future cryptographic updates.

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.

Diagram showing how dynamic labels such as user ID, pod name, and IP address create millions of unique time series in observability systems, leading to high costs, slow queries, and complex management.

Figure 1: Harvest Now, Decrypt Later Lifecycle

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:

Inventory Area	What to Capture
Algorithms	RSA, ECC, Diffie-Hellman, AES, SHA, TLS versions, custom cryptography
Certificates	Issuers, expiration dates, key sizes, certificate chains, renewal processes
Keys	Key type, length, location, rotation schedule, ownership
Protocols	TLS, SSH, IPsec, S/MIME, VPN, mTLS, application-layer encryption
Libraries	OpenSSL, BoringSSL, Java cryptography libraries, vendor-provided libraries
Applications	Internal apps, SaaS integrations, APIs, customer-facing services
Infrastructure	Firewalls, load balancers, proxies, VPN gateways, network appliances
Devices	IoT, OT, mobile, embedded systems, unmanaged devices
Vendors	Third-party products, SaaS platforms, managed services, software dependencies

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:

Priority System	Why It Matters
PKI and certificate authorities	Trust foundation for identity, authentication, and encryption
VPN and remote access systems	Protect sensitive traffic across networks
TLS-enabled applications	Secure web, API, and application communications
Identity providers	Support authentication and access decisions
Code-signing systems	Protect software supply chain integrity
Secure boot systems	Validate trusted device and workload startup
Critical infrastructure systems	Often have long lifecycles and limited upgrade paths
IoT and OT devices	May be constrained, difficult to patch, or vendor-dependent

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.

Related Step	Action	Purpose
Step 1	Build a cryptographic inventory	Identify where cryptography is used across applications, infrastructure, cloud environments, endpoints, identities, certificates, keys, protocols, libraries, and vendors.
Step 1	Identify RSA, ECC, and Diffie-Hellman use	Locate public-key cryptography that may be vulnerable to future quantum attacks.
Step 1	Review PKI and certificate systems	Understand certificate authorities, certificate chains, expiration dates, key sizes, renewal processes, and trust dependencies.
Step 2	Map sensitive data flows	Identify where long-lived confidential data is stored, transmitted, or exposed to “harvest now, decrypt later” risk.
Step 2	Prioritize long-lived sensitive data	Determine which data would still cause harm if decrypted in 5, 10, or 15 years.
Step 3	Prioritize systems for migration	Rank systems based on quantum risk, business criticality, data sensitivity, regulatory exposure, and technical complexity.
Step 3	Identify high-priority trust systems	Prioritize PKI, VPNs, TLS-enabled applications, identity providers, code-signing systems, secure boot, critical infrastructure, IoT, and OT systems.
Step 4	Create a PQC working group	Establish cross-functional ownership across security, IT, engineering, identity, legal, compliance, procurement, vendor management, risk, and leadership.
Step 4	Define governance responsibilities	Assign ownership for inventory standards, risk prioritization, vendor requirements, testing, budget planning, and executive reporting.
Step 5	Implement crypto-agility	Enable algorithms, keys, libraries, and protocols to be replaced without major system redesign.
Step 5	Remove hardcoded cryptography	Use configurable cryptographic policies and centralized libraries to support future algorithm changes.
Step 6	Evaluate hybrid cryptography	Assess where classical and post-quantum algorithms may need to work together during the transition.
Step 6	Identify hybrid deployment candidates	Review TLS, VPNs, mTLS, API communications, secure remote access, cloud-to-cloud communications, and high-value data exchanges.
Step 7	Test performance and interoperability	Evaluate handshake size, latency, packet fragmentation, certificate chain size, CPU usage, memory consumption, and application compatibility.
Step 7	Validate rollback and failure behavior	Confirm that systems can recover safely if PQC or hybrid deployments create performance or compatibility issues.
Step 8	Assess vendor readiness	Determine whether vendors support NIST PQC standards, hybrid cryptography, crypto-agility, and future cryptographic updates.
Step 8	Add PQC language to procurement	Require new systems and contracts to include PQC readiness, crypto-agility, roadmap transparency, and support for NIST standards.
Final Planning Action	Create a phased migration roadmap	Sequence work across discovery, assessment, prioritization, pilots, migration, monitoring, and optimization.
Final Planning Action	Report readiness to leadership	Communicate exposure, progress, budget needs, vendor gaps, and migration timelines to executive stakeholders.

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

NIST-PQC migration is the process of preparing systems, applications, certificates, keys, protocols, and infrastructure to support post-quantum cryptography standards developed by NIST. The goal is to reduce exposure to quantum attacks against vulnerable public-key cryptography.

Organizations should start now, especially if they protect data that must remain confidential for many years. The first step is not the immediate replacement of all cryptography. The first step is inventory, risk assessment, vendor review, and roadmap development.

Organizations should prioritize systems that protect long-lived sensitive data, support identity and authentication, rely on certificates or digital signatures, enable secure remote access, or use vulnerable public-key algorithms such as RSA, ECC, and Diffie-Hellman.

Crypto-agility is the ability to replace cryptographic algorithms, keys, protocols, and libraries without redesigning major systems. It allows organizations to adapt as standards evolve, vulnerabilities emerge, or new regulatory expectations appear.

Hybrid cryptography is not always required, but it is a practical transition strategy. It combines classical cryptography with post-quantum cryptography to maintain current protection while adding quantum resistance.

No. AES-256 is a symmetric encryption algorithm and is generally considered resistant to quantum attacks when implemented correctly. NIST-PQC migration primarily focuses on vulnerable public-key cryptography, including RSA, ECC, Diffie-Hellman, and related signature or key exchange mechanisms.

The timeline depends on the organization’s size, cryptographic complexity, vendor dependencies, legacy systems, and regulatory requirements. Large enterprises should expect a multi-year effort that begins with discovery and prioritization.

Organizations should ask whether vendors support NIST standards such as ML-KEM, ML-DSA, and SLH-DSA; whether they support hybrid deployments; how they manage cryptographic updates; and what their roadmap is for post-quantum migration.