Post-Quantum Cryptography Migration Has Started — Most Organizations Are Not Ready

In August 2024, NIST published three finalized post-quantum cryptography standards: ML-KEM (based on CRYSTALS-Kyber), ML-DSA (based on CRYSTALS-Dilithium), and SLH-DSA (based on SPHINCS+). These algorithms are designed to resist attacks from quantum computers — a threat that doesn't yet fully exist but is approaching fast enough that organizations protecting long-lived secrets need to act now.

Most haven't. Security teams that are stretched managing today's threats often treat post-quantum migration as a future problem. It isn't. The threat model is already active.

The Harvest Now, Decrypt Later Problem

The reason post-quantum migration is urgent today — even though cryptographically relevant quantum computers don't yet exist — is a strategy called Harvest Now, Decrypt Later (HNDL). Nation-state threat actors are collecting encrypted internet traffic today, storing it, and planning to decrypt it once quantum computing reaches sufficient capability.

If your organization transmitted sensitive data — financial records, intellectual property, government communications, personal health information — in the last several years, that data may already be in adversary storage. When a sufficiently powerful quantum computer arrives, the RSA and elliptic curve encryption protecting it becomes breakable retroactively.

CISA and NSA have estimated that cryptographically relevant quantum computers could emerge between 2030 and 2035. That's not a comfortable buffer — it's a hard deadline for migrating any data or communications that need to remain confidential for more than a few years.

What the New Standards Actually Are

The three NIST standards address different cryptographic functions:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) replaces RSA and Elliptic Curve Diffie-Hellman for key exchange — the mechanism that establishes shared secrets between two parties communicating over an insecure channel. This is what protects HTTPS connections and TLS sessions.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) replaces RSA and ECDSA for digital signatures — verifying that a message, software update, or certificate actually came from who it claims to come from.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) provides an alternative signature scheme with different mathematical foundations (hash functions rather than lattices), serving as a hedge against lattice-based vulnerabilities.

All three are based on mathematical problems — lattice problems and hash functions — that are believed to be hard for quantum computers to solve, unlike the factoring and discrete logarithm problems that underpin RSA and elliptic curve cryptography.

Who's Already Moving

The early movers are predictably the organizations with the highest threat profiles and the longest data lifespans.

Google integrated ML-KEM into Chrome 116 in 2023, making TLS connections between Chrome and Google servers quantum-resistant by default. Apple has added post-quantum key exchange to iMessage's PQ3 protocol. Signal implemented its own post-quantum key agreement (PQXDH) in 2023. Cloudflare has been experimenting with post-quantum TLS for years and now offers it in production.

In government: NSA has mandated that National Security Systems must begin migration by 2025 and complete it by 2030. CISA has issued guidance for critical infrastructure operators. The UK's National Cyber Security Centre has published similar timelines.

What Makes Migration Hard

Post-quantum migration is not a simple software update. It requires finding and replacing cryptographic primitives embedded throughout an organization's systems — a process called cryptographic inventory or crypto-agility assessment.

The scale of the problem is large. A typical enterprise uses TLS everywhere, code signing for software deployments, SSH for server access, encrypted email, encrypted databases, encrypted backup systems, VPNs, and hardware security modules for key storage. Each of these needs assessment: which algorithm is in use, what data it protects, and how long that data needs to remain confidential.

Legacy systems compound the difficulty. Industrial control systems, medical devices, financial infrastructure, and government systems often run software that hasn't been updated in a decade or more. Patching cryptographic algorithms in firmware or embedded systems is frequently impractical without hardware replacement.

Performance is another concern. Post-quantum algorithms have larger key sizes and signature sizes than their classical equivalents. ML-KEM public keys are 1.2 KB versus 91 bytes for ECDH. ML-DSA signatures are 2.4-4.6 KB versus 64-72 bytes for ECDSA. For bandwidth-constrained or latency-sensitive applications, this matters.

Crypto-Agility: The Right Long-Term Architecture

The lesson the security community is drawing from post-quantum migration is not just update to new algorithms — it's build systems that can change algorithms without re-engineering everything. This principle is called crypto-agility.

Crypto-agile systems negotiate which algorithms to use at runtime, store algorithm identifiers alongside encrypted data, and support multiple algorithms simultaneously during transition periods. TLS 1.3 has crypto-agility built in — that's why deploying post-quantum TLS is achievable via a software update. Systems that hardcoded their algorithms don't have this option.

Organizations building new infrastructure today should treat crypto-agility as a non-negotiable architectural requirement. The organizations that will struggle most in the next wave of cryptographic transitions — whether post-quantum, new signature schemes, or algorithm deprecations — are those that treated cryptography as a solved problem rather than a layer that needs to be maintained.

What To Do Now

The immediate practical steps for most organizations: conduct a cryptographic inventory to identify where RSA, ECDH, and ECDSA are in use; prioritize systems that protect long-lived secrets or sensitive communications; begin testing post-quantum algorithms in non-production environments; and update TLS configurations to negotiate post-quantum key exchange where library support exists (OpenSSL 3.x supports ML-KEM in hybrid mode).

The organizations that treat 2030 as a comfortable deadline will find themselves in crisis mode by 2028, when the migration workload becomes undeniable and the supply of experienced cryptographic engineers becomes competitive. The ones who start the inventory now — even if full migration takes years — will have options. The ones who don't will not.