How to Migrate Your Platform for Post-Quantum Cryptography

Aug

2026

Time to read

Read so far

Written by:

Entrust

Time to read

Written by:

Entrust

Glowing digital cube suspended above a futuristic blue circuit board network

The National Institute of Standards and Technology (NIST) has set 2030 and 2035 as the deprecation and disallowance dates for today’s public-key cryptography.

That leaves most enterprise environments less than a decade to replace the Rivest-Shamir-Adleman (RSA) and elliptic curve cryptography (ECC) with post-quantum cryptography (PQC). These are algorithms that have underpinned digital trust for decades and secure the connections, identities, and experiences we rely on every day.

The migration to post-quantum cryptography can feel overwhelming until you break it down into an order of organized steps. A complete cryptographic inventory turns an open-ended mandate into a prioritized, system-by-system roadmap.

Key Takeaways

NIST has set 2030 as the deprecation date and 2035 as the disallowance date for RSA and ECC, which means the shift to post-quantum cryptography will touch nearly every system, application and piece of infrastructure that relies on public-key cryptography.
The Harvest Now, Decrypt Later threat means today’s encrypted data is already at risk. Organizations should prioritize migrating key establishment protocols that protect long-lived confidential data, while also planning the transition of digital signatures for documents, software, identities and other assets that must remain trustworthy for years.
A complete cryptographic inventory is a critical early step. Without it, organizations don't know the true scope of their cryptographic estate.
Migration strategy depends on the system: hybrid certificates for most Transport Layer Security (TLS) infrastructure, direct replacement where crypto-agile architecture already exists, and phased reengineering for legacy and embedded systems.
Crypto-agility, the ability to update algorithms without re-engineering dependent systems, determines how manageable this migration is, and the next one will be.

Why Post-Quantum Cryptography Migration Cannot Wait

Just 38% of organizations globally are actively transitioning to post-quantum cryptography, and 68% say managing cryptographic assets is already extremely or very difficult, according to Entrust's 2026 Global State of Post-Quantum and Cryptographic Security Trends report.

NIST's 2030 and 2035 deadlines for retiring today's public-key cryptography don't leave much runway for a migration. At the same time, data encrypted today is already being collected for decryption once a quantum computer can break it.

As Greg Wetmore, VP of Product Development at Entrust, put it, “The clock is ticking, and the solutions are available now – so enterprises can’t afford to delay action. It’s not a question of ‘Will quantum computers disrupt us?’ but ‘How quickly can we adapt our infrastructure to withstand what’s coming?’”

The NIST Timeline

NIST finalized its first three post-quantum cryptography standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Algorithms at the 112-bit security level, including RSA-2048, are deprecated after 2030 and disallowed after 2035.

Stronger key lengths, including the elliptic curves most organizations run today, stay allowed only until that same 2035 cutoff.

According to NIST's own guidance, historically, moving from algorithm standardization to full integration across information systems has taken 10 to 20 years. This migration, given its larger scope, is unlikely to move faster.

The Harvest Now, Decrypt Later Threat

Attackers don’t need a working quantum computer today to benefit from one later. They can capture encrypted data now and decrypt it once a cryptographically relevant quantum computer exists. This strategy is known as Harvest Now, Decrypt Later (HNDL).

That threat should help organizations determine which systems should migrate first. Encryption and key establishment protect data that has to stay confidential for years, so anything encrypted today with a quantum-vulnerable algorithm could already be exposed to future decryption. This makes quantum-resistant key establishment an immediate priority, since every day of delay potentially adds more captured data to the pool an attacker could decrypt later.

Digital signatures face a different, but still significant, risk. Signatures protecting long-lived documents, contracts, software, identities and records may need to remain trustworthy and verifiable for years. Once quantum computers can break today’s signature algorithms, attackers could potentially forge signatures and undermine the authenticity or integrity of systems and assets that still depend on them. This threat has been referred to as “Harvest Now, Forge Later”. Organizations should therefore prioritize migration based on both the confidentiality lifetime of their data and the trust lifetime of their signed assets.

Quantum-safe encryption depends on quantum-resistant key establishment, but a complete post-quantum transition must also address digital signatures and the systems that rely on them.

What You're Migrating To: NIST Post-Quantum Standards

The migration replaces two categories of classical cryptography: key establishment and digital signatures, both of which rely on asymmetric encryption that a quantum computer running Shor's algorithm can break outright. That's why quantum-resistant cryptography and encryption efforts concentrate on replacing them first.

That process rests on three NIST-standardized alternatives and one bridge approach:

ML-KEM (FIPS 203), the Module-Lattice-Based Key-Encapsulation Mechanism: the primary algorithm for key encapsulation, replacing RSA and ECDH key exchange in TLS and similar protocols.
ML-DSA (FIPS 204), the Module-Lattice-Based Digital Signature Algorithm: the primary algorithm for digital signatures, replacing RSA and ECDSA for certificate signing, code signing, and document signing.
SLH-DSA (FIPS 205), the Stateless Hash-Based Digital Signature Algorithm: an alternative to ML-DSA when different security assumptions are preferred.
Hybrid certificates: These pair a classical algorithm (RSA or ECC) with a PQC algorithm during the transition. Because the connection stays secure as long as either algorithm holds, systems keep working with clients and servers that haven't migrated yet. Most enterprises use this approach rather than switching over all at once.

Symmetric encryption is a different case. Many environments also rely on it for bulk data protection, and quantum computing threatens it in a much smaller way. Grover’s algorithm (a quantum algorithm for searching through possibilities faster than classical computers) only halves its effective security strength rather than breaking it right away. AES-256 stays secure after that; AES-128 doesn't, and should be upgraded.

Crypto-agility, the capacity to update cryptographic algorithms without reengineering the systems that rely on them, determines how manageable this migration is. Organizations with crypto-agile infrastructure can more readily swap algorithms as standards evolve. Those without it face far more complexity including a potential full reengineering effort for every affected system.

Step 1: Discover and Inventory Your Cryptography

You cannot migrate cryptography you cannot see. Over time, cryptographic assets accumulate across applications, infrastructure, cloud services, code libraries and third-party systems, likely with no centralized visibility. Given the volume and complexity of the modern cryptographic estate, creating and maintaining a complete inventory manually is not realistic.

Automated discovery tools can scan across environments to identify where cryptography is used, including algorithms, keys, certificates, protocols, libraries and dependencies. The result should be a living Cryptographic Bill of Materials (CBOM): a structured, continuously updated inventory that shows what cryptographic assets exist, where they are located, what they protect and which systems depend on them.

A CBOM is increasingly recognized as a foundation for post-quantum readiness and cryptographic governance. It gives organizations the visibility needed to identify quantum-vulnerable cryptography, prioritize migration based on risk and manage remediation through consistent policies, ownership and reporting. Rather than treating inventory as a one-time exercise, organizations can use the CBOM as an ongoing control to govern their cryptographic estate throughout the transition.

Step 2: Assess Risk and Prioritize Migration

Once the inventory is built, score every asset against five risk dimensions to determine what gets migrated first:

Data sensitivity and longevity: How sensitive is the protected data, and how long does it need to stay confidential? Long-lived sensitive data in healthcare, government, or financial systems moves to the top of the queue.
Quantum vulnerability: RSA and ECC systems are the primary targets. AES-256 systems can be deprioritized, and AES-128 systems should be evaluated for an upgrade.
System criticality: Would compromise or an outage of this system materially disrupt operations? High-criticality systems need more careful planning, including testing and a staged rollout, but that doesn't automatically put them first in line.
Migration complexity: How deeply is the cryptographic dependency embedded? A TLS certificate on a web server is far easier to migrate than a cryptographic primitive compiled into Internet of Things (IoT) or embedded-system firmware.
Regulatory exposure: Systems in scope for compliance frameworks with emerging post-quantum requirements, covered in more detail below, carry external deadlines that constrain sequencing.

That scoring produces a tiered migration roadmap. Tier 1 covers the highest-urgency assets: long-lived sensitive data with HNDL exposure. Tier 2 covers critical systems where migration complexity is manageable. Tier 3 covers lower-risk or higher-complexity systems addressed later in the migration window.

Regulatory Deadlines as a Prioritization Factor

National security systems face an even tighter timeline than NIST's general 2030 and 2035 dates. The National Security Agency (NSA)'s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires new acquisitions to support quantum-resistant algorithms starting January 1, 2027.

For U.S. federal agencies, Office of Management and Budget (OMB) Memorandum M-23-02 established cryptographic inventory reporting in 2022, and OMB M-26-15, issued in June 2026, now lays out a five-phase migration timeline running through 2035. Organizations with government contracts should check current OMB and agency guidance, since federal requirements continue to evolve.

In financial services, the EU's Digital Operational Resilience Act (DORA) and the Payment Card Industry Data Security Standard (PCI DSS) 4.0's Requirement 12.3.3 both call for a documented cryptographic inventory and an ongoing strategy for algorithm risk, with specific post-quantum timelines still being finalized by regulators in each jurisdiction.

Step 3: Choose Your Migration Strategy

The risk tiers described above set the sequence for migration. Which of the following three strategies applies to a given system depends on its architecture: how deeply its cryptography is embedded, and how much interoperability with classical infrastructure is still needed.

Hybrid Migration

Hybrid certificates combine a classical algorithm with a PQC algorithm in the same certificate, so a connection stays secure if either algorithm holds. This is the most broadly applicable strategy for TLS infrastructure, since it keeps systems interoperable with clients and servers that haven't migrated yet.

However, PQC keys and signatures are larger than their classical equivalents, which adds overhead to every handshake and certificate.

Lift-and-Replace

Direct replacement, swapping the classical algorithm for its PQC equivalent without a hybrid bridge, works when a system’s cryptography is already abstracted behind a configurable library or service. That's exactly what crypto-agile architecture provides.

Without it, even a straightforward swap turns into a reengineering project, since the algorithm choice is hard-coded into application logic rather than pulled from a configuration file.

Phased Re-Engineering

Legacy applications and embedded systems (IoT firmware and industrial control systems among them) rarely support a quick swap or a hybrid bridge. They need a phased reengineering plan that treats the cryptographic migration as part of a larger modernization or replacement effort. Keep them on the Tier 3 roadmap rather than dropping them from it.

Step 4: Test Before You Deploy

Whichever strategy applies, validate before anything reaches production, starting with these four checks:

Algorithm performance testing: ML-KEM and ML-DSA produce larger keys and signatures than RSA and ECC. Test the effect on latency and throughput, particularly in high-volume environments like payment processing and authentication systems.
Interoperability testing: PQC algorithms need to work with existing systems and network infrastructure. Test hybrid certificate compatibility across client and server environments in scope.
Hardware security module (HSM) validation: This confirms that the HSMs in the environment support the PQC algorithms being deployed. Entrust nShield 5 HSMs support ML-KEM, ML-DSA, and SLH-DSA natively, with the implementations validated through NIST's Cryptographic Algorithm Validation Program.
Staging environment: This runs the migration in a representative staging environment first. Document failure modes and rollback procedures before touching production traffic.

Step 5: Execute a Phased Deployment

Once testing confirms a migration path works, execution follows four phases:

Phase 1 (now through month 6): Tier 1 systems, long-lived sensitive data with the highest HNDL exposure, go first. Hybrid certificate infrastructure for TLS environments comes up in parallel.
Phase 2 (months 6 to 18): Tier 2 migrations execute, PKI updates to support hybrid and pure PQC certificate issuance, and key exchange protocols move to ML-KEM.
Phase 3 (through 2028): Remaining Tier 2 systems complete. Legacy and embedded systems on the Tier 3 roadmap begin reengineering where refresh cycles allow.
Phase 4 (2028 to 2035): Tier 3 migrations complete, classical-only certificate infrastructure retires, and PQC posture validates across the enterprise.

Moving from PQ preparedness to PQC adoption won't be the last cryptographic migration organizations face. Building crypto-agility as a lasting practice now means being prepared for whatever standard follows ML-KEM.

Starting Your Post-Quantum Cryptography Migration

That five-step roadmap rarely moves in a straight line once execution starts. Inventory work often reveals more than expected. Risk tiers shift as new regulatory guidance lands. Testing surfaces interoperability issues that weren’t visible on paper.

Organizations should plan for that iteration rather than treat the five steps as a single linear project. This keeps a migration moving instead of stalling after the first phase.

Entrust post-quantum cryptography solutions help organizations move from planning to implementation with an integrated foundation for crypto-agility. The Entrust Cryptographic Security Platform provides centralized discovery, visibility, policy and lifecycle management across the cryptographic estate, helping teams identify quantum-vulnerable assets, prioritize remediation and govern the transition at scale. PQ-ready PKI enables organizations to test and deploy hybrid and pure post-quantum certificate hierarchies, while nShield HSMs provide a hardware-based root of trust for secure post-quantum key generation, protection and cryptographic operations. Together, these capabilities help organizations manage migration as an ongoing, enterprise-wide program rather than a series of disconnected technology upgrades.

FAQs

What is post-quantum cryptography?

Post-quantum cryptography (PQC) is a set of algorithms built to stay secure against attacks from quantum computers, replacing RSA and ECC for key exchange and digital signatures.

Why should organizations migrate to post-quantum cryptography?

RSA and ECC will not survive a cryptographically relevant quantum computer, and data captured today can be decrypted retroactively once one exists. NIST has already set the deadlines: 2030 for deprecation, 2035 for disallowance.

When should organizations begin preparing for PQC migration?

Now. Given the scale of most cryptographic estates and how long past algorithm transitions have taken, waiting until closer to 2030 leaves little room for the inventory and phased rollout this migration requires.

Which platforms and systems need to be updated for post-quantum cryptography?

Anything using RSA or ECC: TLS and network security protocols, PKI and certificate infrastructure, code and document signing systems, VPNs, and any HSM or cryptographic library that implements these algorithms.

What are the first steps in a post-quantum migration?

Build a complete cryptographic inventory, then score each asset against data sensitivity, quantum vulnerability, system criticality, migration complexity, and regulatory exposure to produce a tiered migration roadmap.

How can organizations identify quantum-vulnerable cryptography?

Automated discovery tools scan on-premises and cloud environments to enumerate keys and certificates and flag RSA and ECC usage at any key length, surfacing shadow crypto that manual inventories miss.

Benchmark Your Readiness

See how your organization's cryptographic readiness compares. Read the 2026 Global State of Post-Quantum and Cryptographic Security report from Entrust and Ponemon Institute for the full picture.

Post-Quantum Cryptography

Entrust

View all of Entrust's Posts