Post-Quantum Cryptography: Why Migration Starts Now

A cryptographically relevant quantum computer does not yet exist. But nation-state actors and well-resourced adversaries are already collecting encrypted traffic today, banking on the ability to decrypt it once one does. That threat — known as “harvest now, decrypt later” — is why governments, browser vendors, and cloud providers are migrating to post-quantum cryptography right now, not when quantum hardware actually arrives.

Why today’s public-key crypto is at risk

RSA and elliptic-curve cryptography (ECC) derive their security from mathematical problems — factoring large integers and solving the discrete logarithm — that are computationally intractable for classical computers. A sufficiently powerful quantum computer running Shor’s algorithm would solve both problems efficiently, rendering any data protected by those algorithms fully exposed.

Symmetric cryptography sits in a different position. Grover’s algorithm can speed up brute-force searches against symmetric ciphers and hash functions, but it only halves the effective key strength — not a catastrophic break. AES-256 and SHA-2/SHA-3 remain broadly safe at their current key sizes; AES-128 warrants more scrutiny. The urgent migration problem is almost entirely about public-key systems.

The “harvest now, decrypt later” scenario is what makes timing critical. Long-lived secrets — medical records, diplomatic communications, financial agreements — encrypted today under RSA or ECDH may still be sensitive in a decade. Waiting to migrate until quantum hardware matures is waiting too long.

The NIST post-quantum standards

After a multi-year evaluation process, NIST finalized three post-quantum cryptography standards in 2024. These cover both key encapsulation and digital signatures:

FIPS Number	Algorithm Name	Purpose	Origin
FIPS 203	ML-KEM (CRYSTALS-Kyber)	Key encapsulation mechanism (KEM)	Lattice-based
FIPS 204	ML-DSA (CRYSTALS-Dilithium)	Digital signatures	Lattice-based
FIPS 205	SLH-DSA (SPHINCS+)	Digital signatures	Hash-based

ML-KEM (FIPS 203) is the primary standard for establishing shared secrets — it replaces the Diffie-Hellman and ECDH key exchange at the heart of TLS. ML-DSA (FIPS 204) is the recommended signature algorithm for most use cases. SLH-DSA (FIPS 205) offers a hash-based alternative for contexts that want a fundamentally different security assumption — its strength rests on properties of hash functions rather than lattice problems, making it a useful hedge if lattice cryptanalysis advances unexpectedly.

Hybrid deployment in TLS

Rather than switching cold to unproven algorithms, the industry has adopted a hybrid approach: run the classical key exchange and the post-quantum KEM in parallel, combine their outputs, and use the result as the session key. Combining X25519 (classical ECDH) with ML-KEM is already deployed in TLS by major browsers and large cloud services. A passive attacker recording that traffic needs to break both algorithms to recover the session key — the classical part provides security today; the post-quantum part provides security against a future quantum computer.

This hybrid model is the right transition path: it doesn’t sacrifice classical security during the migration period, and it means traffic captured now will remain protected even if Shor’s algorithm becomes practical.

What symmetric crypto needs

For symmetric algorithms the migration is simpler. Grover’s algorithm effectively halves key strength, so the practical guidance is: prefer AES-256 over AES-128 for new systems protecting long-lived data, and prefer SHA-256 or SHA-3 over shorter digests. No fundamental restructuring of symmetric cryptographic infrastructure is required — it’s an upgrade in key length, not a change in algorithm family.

The practical migration checklist

Post-quantum readiness is not a single update; it’s a process. A reasonable starting framework:

• Inventory your cryptography. Know which services, certificates, and data stores rely on RSA or ECC. You can’t migrate what you haven’t found. Libraries, TLS configurations, signing keys, and VPN credentials all count.
• Prioritize long-lived secrets. Data that needs to stay confidential for years or decades is highest risk under “harvest now, decrypt later.” Protect it first.
• Adopt crypto-agility. Design systems so the cryptographic algorithm can be swapped without restructuring the whole application. Hard-coding “RSA-2048” is the wrong pattern; parameterizing the algorithm is the right one.
• Update libraries and TLS. OpenSSL, BoringSSL, and most major TLS libraries are already adding ML-KEM and ML-DSA support. Running an updated TLS stack with hybrid X25519+ML-KEM key exchange is the highest-leverage near-term action for most services.
• Watch certificate infrastructure. The WebPKI and code-signing infrastructure still run on classical signatures. ML-DSA certificates are coming, but the rollout will take time — track the CA/Browser Forum guidance.

You don’t need to do everything at once, but you do need to start. The inventory and crypto-agility steps carry value regardless of quantum timelines.

How this connects to broader security hygiene

Post-quantum migration sits alongside related security investments. If you haven’t already hardened your web layer — understanding how HTTPS and TLS actually work gives you the foundation to reason about what’s changing at the protocol layer. Phishing-resistant authentication like passkeys reduces credential-theft exposure independent of the quantum question. And since cryptographic libraries live in your dependency tree, software supply chain security determines whether the post-quantum code you deploy is actually the code you intended to deploy.

The takeaway

The algorithms are finalized, the hybrid deployments are live, and the standards are clear. Post-quantum cryptography is no longer a research problem — it is an engineering migration problem. The calendar pressure comes not from quantum hardware being imminent, but from adversaries who are patient: encrypted traffic stored today may be decrypted years from now. Organizations that treat this as “future work” are already behind.