Post-Quantum Cryptography Migration: What Security Teams Need to Do Before It's Too Late

Most security teams understand the quantum computing threat at a conceptual level. Far fewer have started the work. The migration from classical to post-quantum cryptography is not a software update — it is a multi-year infrastructure overhaul touching every system that establishes encrypted sessions, signs code, manages certificates, or stores encrypted data. And unlike most transitions, this one has a hard deadline driven not by regulatory bodies but by the mathematics of quantum computation and the intelligence community's assessment of adversary capabilities.

This guide is for security leaders, architects, and engineering teams who need to move from awareness to action. We will cover why classical cryptography breaks, what the NIST standards actually say, the specific systems that need to change, and a phased migration roadmap that organizations can begin executing today.

Why RSA and ECC Break Against a Quantum Computer

The security of RSA depends on the computational hardness of factoring large integers. The security of elliptic curve cryptography depends on the hardness of the elliptic curve discrete logarithm problem. Both of these problems are classically hard — no efficient classical algorithm is known that can solve either in polynomial time as key sizes grow.

In 1994, mathematician Peter Shor published a quantum algorithm — now called Shor's algorithm — that solves both problems in polynomial time on a quantum computer. A quantum computer running Shor's algorithm can factor an RSA-2048 key, solve the discrete logarithm underlying ECC-256, and break Diffie-Hellman key exchange. The algorithm is not hypothetical: it is mathematically proven to work. The only remaining variable is whether sufficiently large, error-corrected quantum computers can be built.

Current estimates from NIST, NSA, and the intelligence community project that cryptographically relevant quantum computers (CRQCs) — machines large enough to break RSA-2048 in a practical timeframe — could emerge within 10 to 15 years. Some academic estimates are more aggressive. No serious security authority believes classical public-key cryptography will remain safe beyond 2040.

What about symmetric encryption?

Symmetric ciphers like AES are affected differently. Grover's algorithm provides a quantum speedup for unstructured search, which effectively halves the security level of a symmetric key — so AES-128 drops to 64 bits of effective security, which is considered broken, while AES-256 drops to approximately 128 bits, which remains acceptable. Hash functions like SHA-256 are similarly weakened but not broken. The migration priority is entirely focused on asymmetric cryptography and key exchange.

The NIST Post-Quantum Standards

In August 2024, NIST finalized the first three post-quantum cryptography standards. These were the output of an eight-year competition involving hundreds of cryptographers, dozens of candidate algorithms, and multiple rounds of public cryptanalysis. The standards are not experimental — they are ready for production deployment.

FIPS 203: ML-KEM (CRYSTALS-Kyber)

ML-KEM (Module Lattice-based Key Encapsulation Mechanism) is the primary post-quantum standard for key establishment. It replaces ECDH (Elliptic Curve Diffie-Hellman) for key exchange in TLS, SSH, VPNs, and any protocol that negotiates a session key. ML-KEM is based on the mathematical hardness of the Module Learning With Errors (MLWE) problem, a lattice-based problem for which no efficient quantum algorithm is known. It offers three security levels (ML-KEM-512, ML-KEM-768, ML-KEM-1024) corresponding roughly to 128, 192, and 256 bits of classical equivalent security. ML-KEM-768 is the recommended default for most deployments.

FIPS 204: ML-DSA (CRYSTALS-Dilithium)

ML-DSA (Module Lattice-based Digital Signature Algorithm) is the primary post-quantum standard for digital signatures. It replaces RSA and ECDSA for code signing, TLS certificate signing, document signing, and any use case where a signature must be verifiable. ML-DSA is also based on lattice mathematics and offers three parameter sets (ML-DSA-44, ML-DSA-65, ML-DSA-87). Signatures are larger than RSA or ECDSA signatures — approximately 2.4 KB for ML-DSA-65 versus 64 bytes for ECDSA-256 — which has implications for certificate sizes, bandwidth, and storage in high-volume environments.

FIPS 205: SLH-DSA (SPHINCS+)

SLH-DSA (Stateless Hash-based Digital Signature Algorithm) is a backup signature scheme standardized alongside ML-DSA. Its security is based on hash function properties rather than lattice mathematics, which makes it a valuable hedge: if a future cryptanalytic breakthrough undermines lattice-based algorithms, SLH-DSA remains secure under different mathematical assumptions. It is significantly slower than ML-DSA for signing and produces larger signatures, so it is recommended for use cases where the diversity of mathematical assumptions matters more than performance — for example, long-lived root CA certificates, firmware signing, or other high-value, low-frequency signature operations.

Harvest Now, Decrypt Later: Why the Threat Is Already Active

The most dangerous misconception about post-quantum security is that the threat is future-tense. It is not. The threat is present-tense for any data with long-term sensitivity.

The "harvest now, decrypt later" (HNDL) strategy works as follows: an adversary intercepts and stores encrypted network traffic today — TLS sessions, VPN tunnels, SSH sessions — at scale. The encrypted data is useless to them now because they lack the ability to break the encryption. But once sufficiently powerful quantum computers become available in 10 to 15 years, they retroactively decrypt everything they collected. The window of protection for any data you transmit today is bounded by the arrival of cryptographically relevant quantum computers, not by the expiration of your TLS certificate.

CISA and NSA intelligence assessments indicate that nation-state actors — primarily China — are actively executing this strategy at scale against US government networks, critical infrastructure, defense industrial base contractors, and high-value commercial targets. The mass interception infrastructure exists and is operational. The storage is cheap. The quantum computers are the only variable.

Which data is actually at risk?

Not all data needs to be quantum-safe by 2030. The risk calculation depends on the sensitivity lifetime of the data. Ask: if this data were decrypted in 2035, would it cause harm?

• Immediate migration priority: Health records, financial records, legal documents, intellectual property, mergers and acquisitions communications, government secrets, long-term contracts, personally identifiable information subject to data retention laws
• Medium priority: Business strategy, personnel records, source code, authentication credentials (passwords rotate; historical credential exfil matters less)
• Lower priority: Public information, operational data with short relevance windows, data that will be irrelevant within five years regardless

What Needs to Change: A Full System Inventory

Post-quantum migration is not a library upgrade. Every system that relies on asymmetric cryptography for confidentiality, integrity, or authentication needs to be assessed and updated. Here is a complete inventory of affected systems.

TLS / HTTPS

Every TLS handshake negotiates a key exchange using ECDH or RSA key encapsulation. This is the highest-volume attack surface for HNDL — billions of encrypted sessions per day across the public internet. Migrating TLS requires updating the cipher suites negotiated during handshake to include ML-KEM key exchange. Both the server and the client must support PQC cipher suites. Major browsers (Chrome, Firefox) have already shipped hybrid ML-KEM + X25519 in experimental form. Nginx, Apache, and cloud load balancers are adding PQC support. The recommended migration path is hybrid mode: negotiate both X25519 (classical) and ML-KEM-768 simultaneously, so the session is secure even if one algorithm has a flaw.

SSH Keys and Handshakes

SSH uses asymmetric cryptography in two places: host authentication (the server's host key proves identity) and key exchange (establishing the session encryption keys). Both need updating. OpenSSH 9.0+ supports hybrid ML-KEM key exchange. Host key types need to migrate from RSA/ECDSA to ML-DSA. All existing SSH authorized_keys entries are RSA or ECDSA — these will need to be regenerated and redistributed when classical algorithms are deprecated.

Code Signing

Every software release signed with RSA or ECDSA carries a signature that will eventually be forgeable by a quantum computer. This matters for long-lived artifacts: firmware, OS installers, root certificates, software update manifests, and any signed binary that may still be in deployment when quantum computers arrive. Code signing infrastructure needs to migrate to ML-DSA or SLH-DSA. Note that SLH-DSA's hash-based foundation makes it particularly attractive for root signing keys that need multi-decade security assumptions.

VPN Session Establishment

IPsec and WireGuard use Diffie-Hellman or ECDH for session key establishment — both broken by Shor's algorithm. The session traffic encrypted with AES-256 is quantum-safe, but the key exchange that establishes the session key is not. An HNDL attacker who recorded your VPN traffic today can decrypt it once they break the recorded key exchange. VPN gateway software needs PQC key exchange support; some enterprise VPN vendors have already shipped hybrid PQC modes.

Hardware Security Modules (HSMs)

HSMs are the longest lead-time item in any PQC migration. Current-generation HSMs from most major vendors (Thales, nShield, AWS CloudHSM, Azure Dedicated HSM) do not yet support ML-KEM or ML-DSA in hardware. New HSM models with PQC support are beginning to ship in 2025-2026. Organizations with significant HSM infrastructure need to plan for hardware replacement cycles — HSMs are not upgraded via firmware alone when the underlying cryptographic acceleration hardware does not support the new algorithms.

PKI Infrastructure

Certificate authorities issue certificates signed with RSA or ECDSA. Every certificate in your PKI hierarchy — root CA, intermediate CAs, leaf certificates for servers and clients — will need to be replaced with PQC-signed equivalents. The root CA certificate is the hardest to migrate because it must be trusted by all relying parties. Expect extended transition periods where dual-algorithm certificate chains (classical + PQC) are issued in parallel.

Email Encryption (S/MIME and PGP)

S/MIME and PGP encrypt email using asymmetric key exchange. Emails encrypted with RSA or ECC today could be retroactively decrypted. Both standards are working on PQC extensions. Organizations using S/MIME for sensitive email need to plan for key migration and inform counterparties.

Disk Encryption Key Wrapping

Many full-disk encryption schemes use asymmetric cryptography to wrap the symmetric encryption key. If the key wrapping uses RSA or ECC, an attacker who copies the encrypted disk today can unwrap the key later using quantum methods. The underlying AES-256 encryption of the disk contents is safe; the key management layer may not be.

Stored Encrypted Archives

Any encrypted archive or backup that was sealed with asymmetric key exchange inherits the HNDL problem. If the archive will still contain sensitive data when quantum computers arrive, it needs to be re-encrypted under a quantum-safe scheme — or the data it contains needs to be considered at risk.

Crypto Agility: The Architectural Prerequisite

Before migrating to any specific post-quantum algorithm, organizations need to address a more fundamental architectural question: are your systems capable of changing their cryptographic algorithms at all?

Crypto agility means designing systems so that the choice of cryptographic algorithm is a configurable parameter rather than a hardcoded implementation detail. A crypto-agile system can switch from ECDH to ML-KEM by updating a configuration or library version; a non-agile system requires rewriting the code that performs key exchange.

Most organizations discovered during the SHA-1 deprecation and TLS 1.0 migration that many of their systems had hardcoded algorithm choices buried deep in dependencies. The quantum transition will surface the same problem at larger scale. Systems built with crypto agility in mind — using abstract cryptographic interfaces, negotiating algorithms via protocol handshakes, and separating algorithm choice from cryptographic operations — migrate orders of magnitude faster and cheaper than systems that don't.

The lesson from SHA-1 and MD5 transitions: technical debt in cryptographic implementations is uniquely painful to pay down under deadline pressure. Building crypto agility now, even before deploying PQC algorithms, reduces the cost of the migration substantially.

The Migration Roadmap

The phased approach below is consistent with NIST SP 800-131B guidance, NSA CNSA 2.0 mandates, and CISA's PQC migration recommendations. Organizations in federal contracting or national security supply chains should treat the 2030 deadline as hard. Commercial organizations should treat it as the outer boundary of a risk-managed timeline.

Phase 1: Inventory and Assessment (2026 — Now)

You cannot migrate what you cannot find. The first phase is a complete cryptographic dependency inventory.

• Enumerate all TLS endpoints and the cipher suites they negotiate — automated scanning tools (testssl.sh, NMAP ssl-enum-ciphers, commercial ASM platforms) can produce this inventory at scale
• Identify all asymmetric key material: SSH host keys, SSH authorized_keys, code signing certificates, TLS certificates, CA certificates, HSM-protected keys, VPN pre-shared keys and certificates
• Catalog all HSM hardware models and their PQC roadmaps — contact your HSM vendor for their FIPS 203/204 support timeline
• Identify all libraries performing cryptographic operations: OpenSSL version, BoringSSL, LibreSSL, language-native crypto (Java Cryptography Architecture, .NET System.Security.Cryptography, Python cryptography library)
• List all software dependencies that implement or configure cryptographic operations — particularly those with hardcoded algorithm choices
• Identify data stores containing long-term sensitive data encrypted with asymmetric key wrapping

OMB M-23-02 already requires US federal agencies to complete this inventory and submit it to CISA. Commercial organizations are well-advised to run the same exercise — it will expose technical debt and architectural risks regardless of whether PQC migration is imminent.

Phase 2: Hybrid Deployment (2026–2027)

Hybrid mode is the transition-safe approach: deploy classical and post-quantum algorithms in parallel, so that a session is secure even if one algorithm proves to have a flaw. This is the approach NIST, NSA, and major vendors recommend for the transition period. Neither a classical break nor a PQC break alone compromises the session.

• Update TLS cipher suites on public-facing services to include hybrid X25519 + ML-KEM-768 key exchange — this is supported in OpenSSL 3.x with the OQS provider, and natively in recent versions of BoringSSL
• Update SSH server and client configurations to negotiate hybrid ML-KEM key exchange (OpenSSH 9.0+)
• Begin issuing dual-algorithm certificates where your CA infrastructure supports it
• Update code signing pipelines to produce both classical (ECDSA) and PQC (ML-DSA) signatures for new releases
• Evaluate and select HSM replacement or upgrade path; begin procurement for hardware that ships with FIPS 203/204 support
• Rebuild cryptographic abstraction layers to be algorithm-agnostic where they currently are not

Phase 3: Full PQC Deployment (2028–2030)

By this phase, hybrid mode has been validated, library support is mature, and most major protocol stacks have stable PQC implementations. The goal is to make PQC the primary algorithm and classical the fallback — reversing the Phase 2 priority order.

• Issue PQC-primary, PQC-only certificates for new endpoints; begin retiring classical certificate chains
• Replace HSMs that do not support FIPS 203/204 natively; re-key all HSM-protected material under PQC algorithms
• Migrate SSH authorized_keys and host keys to ML-DSA across all infrastructure
• Complete code signing migration: new releases are signed with ML-DSA; classical signatures become optional backcompat only
• Re-encrypt stored archives and database backups containing long-term sensitive data under PQC key wrapping
• Update VPN gateway firmware/software to use PQC-primary key establishment

Phase 4: Classical Algorithm Deprecation (Post-2030)

Once full PQC deployment is complete and sufficiently validated, classical asymmetric algorithms can be disabled. This phase is principally about removing attack surface and eliminating the risk of downgrade attacks that force negotiation of classical algorithms.

• Remove RSA and ECDH from TLS cipher suite negotiation — accept only ML-KEM
• Remove ECDSA and RSA from code signing and certificate issuance
• Retire classical PKI roots; complete trust store updates across all clients and operating systems
• Remove classical SSH key types from authorized_keys and known_hosts

Regulatory and Compliance Landscape

The regulatory picture is becoming clearer. Security teams should understand both where mandates exist today and where the compliance frameworks are heading.

NSA CNSA 2.0

The Commercial National Security Algorithm Suite 2.0 is NSA's authoritative list of algorithms approved for national security systems. CNSA 2.0, published in September 2022, mandates ML-KEM for key establishment and ML-DSA or SLH-DSA for digital signatures, with a transition target of 2030 for most systems and an extended deadline of 2033 for resource-constrained environments. Organizations in the defense industrial base, government contracting, or critical infrastructure sectors should treat CNSA 2.0 as a binding requirement.

NIST SP 800-131B

NIST Special Publication 800-131B (Transitioning the Use of Cryptographic Algorithms and Key Lengths) provides the formal NIST guidance on when algorithms become deprecated and disallowed. It is the normative document for federal agency cryptographic compliance and is widely referenced in non-federal security frameworks.

OMB M-23-02

This Office of Management and Budget memorandum requires all US federal agencies to inventory their cryptographic systems and begin planning for PQC migration. It is the government's formal acknowledgment that HNDL is an active threat requiring immediate preparation, not future planning.

SOC 2, ISO 27001, PCI DSS

None of these frameworks currently mandate PQC explicitly. However, all three embed the principle of crypto agility in their control frameworks: the requirement to use current, accepted cryptographic standards and to have processes for updating cryptographic controls as standards evolve. An auditor reviewing cryptographic controls in 2027 or 2028 will increasingly expect to see PQC planning and hybrid deployment as evidence of compliance with the intent of those controls — even before explicit PQC requirements appear in the frameworks themselves.

What to Do This Quarter

The full migration is a multi-year program. But there are concrete actions security teams can take now that reduce risk immediately and establish the foundation for the broader effort.

1. Run a cryptographic inventory. Use your ASM platform or a targeted scan to enumerate all TLS endpoints and the cipher suites they negotiate. Build a list of every asymmetric key type in your infrastructure. This alone will reveal more technical debt than most teams expect.
2. Assess your HSM posture. Contact your HSM vendor and get a written statement of their FIPS 203/204 support roadmap. If your current HSM model will not support PQC, begin budgeting for replacement now — procurement and deployment cycles for HSM infrastructure are measured in months to years, not weeks.
3. Identify your highest-sensitivity long-duration data. Any data your organization transmits today that needs to remain confidential past 2035 is already at HNDL risk. Flag those data flows and storage systems for priority migration.
4. Evaluate library versions. OpenSSL 3.x with the Open Quantum Safe provider supports ML-KEM and ML-DSA today in hybrid mode. Check which version of OpenSSL your servers are running. Check whether your language runtimes (Java, Python, .NET, Go) have stable PQC library support available.
5. Enable hybrid TLS in test environments. Configure a test deployment with hybrid X25519 + ML-KEM-768 TLS. Measure the performance impact — latency, CPU overhead, handshake size — in your specific workload. Most findings show the overhead is modest for typical web workloads but more significant for high-frequency, low-latency applications.
6. Assign ownership. Post-quantum migration touches cryptographic engineering, PKI operations, network/VPN teams, HSM administrators, code signing teams, and compliance. No single team can own all of it. Assign a program owner and a steering group now, before the timeline compresses.

Lorikeet Security Team

Penetration Testing & Cybersecurity Consulting

Lorikeet Security helps modern engineering teams ship safer software. Our work spans web applications, APIs, cloud infrastructure, and AI-generated codebases — and everything we publish here comes from patterns we see in real client engagements.

Practical security, written by practitioners.