Preparing for Post-Quantum Cryptography: Migration Strategies and Practical Steps

In August 2024, NIST published three finalized post-quantum cryptography standards: ML-KEM (based on CRYSTALS-Kyber, FIPS 203), ML-DSA (based on CRYSTALS-Dilithium, FIPS 204), and SLH-DSA (based on SPHINCS+, FIPS 205). A fourth standard, FN-DSA (based on FALCON), was finalized shortly after. These publications mark the end of an eight-year standardization process that began in 2016 when NIST issued its call for quantum-resistant cryptographic algorithms. The standards are real, the timelines are public, and organizations that begin preparation now have years to execute an orderly migration. Organizations that wait will face the same crisis they faced with Log4Shell — a scramble to identify and remediate exposure under emergency conditions.

The threat model is straightforward to articulate and genuinely alarming in its implications. The public-key cryptographic algorithms most widely used today — RSA, Diffie-Hellman, and elliptic curve cryptography — derive their security from mathematical problems that classical computers cannot solve efficiently. Factoring large integers (RSA) and computing discrete logarithms (DH, ECC) are computationally intractable for classical hardware at the key sizes in common use. Shor's algorithm, published in 1994, shows that a sufficiently powerful quantum computer can solve both problems in polynomial time — effectively breaking these algorithms. The question is not whether a cryptographically relevant quantum computer will exist but when.

The strongest signal is not a single event. It is the pattern that keeps appearing across institutions.

Reporting Note

Current estimates from academic and government sources suggest cryptographically relevant quantum computers are 10-20 years away, though timelines are genuinely uncertain. The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), published in September 2022, began requiring post-quantum algorithms for National Security Systems by 2025 for some use cases and mandates complete migration by 2033. The urgency is driven not by the expected arrival date of quantum computers but by the 'harvest now, decrypt later' (HNDL) threat: adversaries — most likely nation-state intelligence services — are recording encrypted traffic today with the intention of decrypting it once quantum capability exists. Data encrypted with RSA-2048 today is vulnerable to quantum decryption in ten years. If that data must remain confidential for ten years — and health records, legal documents, government communications, and long-term financial contracts frequently must — then the threat is present now, not hypothetical.

Cryptographic inventory is the first and most labor-intensive step in the migration. You cannot migrate cryptography you have not mapped. A comprehensive cryptographic inventory documents every place in the organization's systems where asymmetric cryptography is used: TLS endpoints and their certificate parameters, SSH host keys and client keys, code signing certificates, document signing workflows, email encryption (S/MIME), VPN tunnels and their key exchange algorithms, hardware security modules and their key types, database encryption keys, identity federation tokens and their signature algorithms, and any application-level encryption. Many organizations discover during this exercise that cryptographic usage is more widespread and less standardized than previously understood. A 2022 survey by the Ponemon Institute found that only 30% of organizations could fully identify where cryptographic keys and certificates resided in their environment.

Classification of data by confidentiality longevity determines migration priority. The fundamental question for each data type is: how long must this data remain confidential? Data that needs to be confidential for only one year faces minimal HNDL risk given current quantum timelines. Data that must remain confidential for 20 years — patient health records under HIPAA, attorney-client privileged communications, classified government intelligence, proprietary research data — faces very real HNDL risk. Organizations should identify their highest-longevity confidentiality requirements and prioritize PQC migration for the systems that protect that data, even if the overall program will take years to complete.

NIST's guidance strongly recommends hybrid approaches during the migration window. A hybrid key encapsulation mechanism combines a classical algorithm (like X25519 or P-256) with a post-quantum algorithm (ML-KEM) in a way that the resulting key material is secure as long as at least one algorithm is unbroken. This provides a safety net in both directions: if quantum computers arrive faster than expected, the PQC component provides protection; if unforeseen weaknesses are found in the new PQC algorithms, the classical component maintains security. The IETF has standardized hybrid key exchange for TLS 1.3 (RFC 8446 with hybrid extensions), and Google, Cloudflare, and Apple have deployed hybrid PQC in their TLS implementations in production. Google's Chrome browser began supporting X25519Kyber768 hybrid key exchange in August 2023, and Cloudflare reported that approximately 20% of TLS connections to its edge were using hybrid PQC by early 2024.

TLS is both the most impactful and the most tractable migration target. TLS protects the majority of internet traffic and encrypts communications for most enterprise applications. The key exchange phase — where client and server establish a shared secret — is the component vulnerable to Shor's algorithm. Migrating TLS key exchange to ML-KEM (with X25519 hybrid) requires updating the TLS library: OpenSSL 3.x, BoringSSL, and AWS-LC all have experimental or production PQC support. The certificate authentication component of TLS (typically RSA or ECDSA signatures on certificates) is also vulnerable but presents a different challenge: certificate chains involve multiple parties (CAs, intermediate CAs, end entities), and updating signature algorithms requires coordination across the PKI ecosystem. The CA/Browser Forum, which governs publicly trusted TLS certificates, is working on timelines for PQC algorithm support in the root store programs.

Hardware Security Module (HSM) readiness is a significant operational constraint. HSMs store cryptographic keys and perform cryptographic operations in tamper-resistant hardware. PQC algorithms have different mathematical properties than classical algorithms — larger key sizes, different computational patterns, different performance characteristics. Many deployed HSMs do not support PQC algorithms and cannot be upgraded via firmware; they require physical replacement. Thales Luna, Entrust nShield, and AWS CloudHSM have PQC roadmaps, but timelines and specific algorithm support vary. Organizations with HSM-dependent cryptographic workflows — particularly in financial services, government, and PKI operations — need to include HSM evaluation and procurement in their PQC migration plans, as hardware procurement cycles are measured in months.

Code signing is a supply chain security concern that PQC migration must address. The signatures on software packages, container images, firmware updates, and code-signing certificates protect the integrity of the software supply chain. If these signatures use RSA or ECDSA, they are vulnerable to quantum forgery — an attacker with a quantum computer could produce valid signatures on malicious software using a compromised or long-lived certificate. Sigstore, the open-source signing infrastructure, is adding PQC signature algorithm support. Package registries including npm, PyPI, and Maven Central need to update their signature verification infrastructure. The challenge is that code signing involves many participants — package publishers, registry operators, client-side tooling — and coordinating PQC migration across all of them is a multi-year ecosystem effort.

Performance is a legitimate concern that should not be dismissed but also should not be exaggerated. PQC algorithms generally have different computational costs than classical algorithms. ML-KEM has larger public keys than X25519 (1,184 bytes for ML-KEM-768 versus 32 bytes for X25519) but comparable computational performance. ML-DSA signatures are larger than ECDSA signatures — approximately 2,420 bytes for ML-DSA-65 versus 64 bytes for P-256 ECDSA — which affects certificate sizes in TLS handshakes, potentially impacting page load times and constrained network environments. SLH-DSA has very small keys but much larger signatures (7,856 bytes for SLH-DSA-128s) and slower signing operations, making it less suitable for high-throughput signing workflows. Algorithm selection should be informed by the specific performance requirements of the use case: ML-KEM for key exchange, ML-DSA for general-purpose digital signatures, SLH-DSA for use cases where signing speed is not critical but extreme assurance is needed.

Testing and gradual rollout are the operational principles that distinguish successful migrations. Start with non-critical, non-production environments. Implement PQC in a staging environment and measure performance impact, compatibility with existing client software, and any unexpected behavior in certificate validation or key exchange. Establish telemetry — monitoring for handshake failures, certificate validation errors, and unusual latency — before extending to production. Use canary deployments: direct a small percentage of traffic to PQC-enabled endpoints before full rollout. Maintain the ability to roll back: hybrid approaches preserve classical algorithm fallback, but rollback procedures for infrastructure changes need to be documented and tested. Microsoft's Digital Security and Resilience team has published detailed guidance on migration testing methodologies that is publicly available.

Supplier and vendor coordination is essential and often overlooked. Many cryptographic operations in enterprise environments are performed by third-party services: cloud TLS termination, identity federation (SAML and OIDC tokens signed by IdP certificates), payment processors, email services, API gateways. Each of these vendors has their own PQC migration timeline. Organizations should assess their critical vendors' PQC readiness, ask specifically about HNDL risk for data processed through those services, and include PQC migration timelines as a question in vendor security assessments and contract renewals. CISA's post-quantum cryptography guidance recommends incorporating PQC readiness into third-party risk management programs.

Governance and policy complete the program. Define which cryptographic algorithms are currently acceptable for new deployments — most organizations should already be requiring AES-256 for symmetric encryption and P-256 or X25519 for asymmetric, and should be deprecating RSA-1024 and SHA-1 immediately. Set timelines for deprecating RSA and classical ECC as the primary key exchange and signature algorithms, aligned with the CNSA 2.0 or NIST guidance timelines appropriate for the organization's risk profile. Assign ownership: who is responsible for the cryptographic inventory, who approves exceptions, who tracks migration progress. Include PQC readiness as a criterion in procurement for new hardware, software, and services. A PQC migration program without governance is a project; with governance, it becomes a sustained capability.

The realistic timeline for complete PQC migration across a large enterprise is five to ten years, which is why starting now matters. The first three years involve inventory, classification, pilot deployments, and hybrid TLS migration for internet-facing services. Years four through six involve extending PQC to internal services, migrating code signing infrastructure, and replacing non-upgradeable HSMs. The final phase addresses the long tail — legacy systems, embedded devices, partner integrations — that require the most custom work. Organizations that begin this work in 2024-2025 will be in controlled migration by the time quantum capability becomes relevant. Organizations that wait until the threat is imminent will face the same compressed, expensive, error-prone response that characterized Log4Shell remediation — except the stakes will be much higher.