Post-Quantum Cryptography: The Migration Has Already Started

Almost every secure connection on the internet — HTTPS, VPNs, signed software updates, messaging — relies on public-key algorithms that a sufficiently large quantum computer would break. That computer doesn't exist yet. But the replacement algorithms do, they're standardised, and they're already running in your browser. Post-quantum cryptography has moved from research topic to migration project, with deadlines attached.

The threat, precisely

RSA, Diffie-Hellman and elliptic-curve cryptography are secure because factoring large numbers and computing discrete logarithms are infeasible for classical computers. Shor's algorithm solves both efficiently on a quantum computer. Estimates of the machine required have been falling — recent work puts a cryptographically relevant quantum computer at under a million noisy physical qubits, down from tens of millions a decade ago — and while no such machine exists, national security agencies treat its arrival in the 2030s as a planning assumption.

Symmetric cryptography (AES) and hash functions (SHA-2, SHA-3) are much less affected: Grover's algorithm gives only a quadratic speed-up, which doubling the key size neutralises. AES-256 is considered quantum-safe. The migration is about public-key cryptography specifically.

Harvest now, decrypt later

The reason this is urgent before the computer exists: an adversary can record encrypted traffic today and decrypt it once they have the capability. Anything that must stay confidential for a decade or more — government communications, health records, intellectual property, financial data, private messages — is exposed now if it's protected by classical key exchange. This is why key exchange is being migrated first, and signatures (which only need to be secure at the moment of verification) second.

The standards

After an eight-year open competition, NIST published its first post-quantum standards in August 2024:

• ML-KEM (FIPS 203, formerly CRYSTALS-Kyber) — a lattice-based key encapsulation mechanism for establishing shared secrets. This is the workhorse replacement for Diffie-Hellman and RSA key exchange.
• ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) — a lattice-based digital signature scheme, the primary replacement for RSA and ECDSA signatures.
• SLH-DSA (FIPS 205, formerly SPHINCS+) — a hash-based signature scheme with larger signatures but security assumptions that don't depend on lattices, as a conservative backup.

A fourth, FN-DSA (Falcon), is following, and NIST selected HQC, a code-based scheme, in 2025 as a backup key-encapsulation mechanism with different mathematical foundations to ML-KEM. Diversity matters: one candidate (SIKE) was broken by a classical laptop in 2022 late in the process, a reminder that new mathematics carries new risk.

What's already deployed

Faster than most people realise. Chrome, Firefox, Safari and Edge, and Cloudflare, Google and most major CDNs, negotiate hybrid key exchange — X25519 combined with ML-KEM — by default; a majority of Cloudflare's human-originated TLS traffic has been post-quantum protected since 2025. Signal and Apple's iMessage moved their messaging protocols to post-quantum key agreement in 2023–24. OpenSSH defaults to a hybrid post-quantum key exchange. OpenSSL 3.5 shipped the NIST algorithms. The "hybrid" approach — combining a classical and a post-quantum algorithm so that breaking either alone isn't enough — is the standard transition pattern, protecting against both quantum attack and the possibility that a new algorithm has an undiscovered flaw.

The deadlines

US federal policy (NSM-10 and the NSA's CNSA 2.0 suite) requires new national security systems to prefer quantum-resistant algorithms by 2025–27 and complete migration by the early 2030s. NIST's own guidance deprecates RSA and ECC at 112-bit security by 2030 and disallows them by 2035. The UK's NCSC has published a 2028/2031/2035 timeline for discovery, priority migration and completion. The EU has a coordinated roadmap along similar lines. Regulators in finance and telecoms are folding these into supervisory expectations. If you're a supplier to any of these sectors, the deadline is effectively yours.

How to run the migration

1. Inventory your cryptography. Where is public-key crypto used — TLS, VPNs, SSH, code signing, PKI, HSMs, embedded devices, vendor products? Most organisations don't know. Automated discovery tools and a cryptographic bill of materials (CBOM) are the starting point.
2. Prioritise by confidentiality lifetime and exposure. Long-lived secrets crossing networks first; internal signatures later.
3. Build crypto agility. The real lesson of this migration is that algorithms should be configuration, not code. Abstract them behind interfaces so the next transition is a setting change.
4. Deploy hybrid now wherever your stack supports it — browsers, TLS terminators, VPNs and SSH mostly already do.
5. Plan for the practical differences. Post-quantum keys and signatures are larger (ML-KEM public keys are around 1.2 KB versus 32 bytes for X25519; ML-DSA signatures are 2–4 KB). That affects packet sizes, certificate chains, constrained devices and anything that hard-codes buffer lengths.
6. Push your vendors. Ask every supplier for their PQC roadmap. Hardware security modules, IoT devices and legacy appliances are where migrations get stuck.

The migration to post-quantum cryptography will take a decade for most large organisations — the same as the transitions from DES and SHA-1, both of which ran late. The difference is that this time the deadline is set by an adversary's capability rather than a standards body's patience.