Harvest Now, Decrypt Later: The Post-Quantum Migration Is Actually Happening

The reason PQC can't wait for quantum computers is captured in one inequality, known as Mosca's theorem: if (years your data must stay secret) + (years your migration takes) exceeds (years until a cryptographically relevant quantum computer), you are already late. Plug in realistic numbers — data lifetimes of 10–25 years for health, financial, legal, and state records; enterprise crypto migrations historically taking 5–10 years; CRQC estimates centering on the 2030s — and most organizations with long-lived secrets come out late today.

That is the logic of harvest now, decrypt later: intelligence agencies and well-resourced criminals record high-value encrypted traffic at scale now, betting on future decryption. The recording is cheap; only the decryption waits on physics. Consequences worth internalizing:

• Key exchange is the urgent half. Every TLS session's confidentiality rests on an ephemeral key agreement (X25519/ECDH today). Once quantum-broken, all recorded sessions open retroactively. This is why the internet is migrating key exchange first and fastest.
• Signatures are the slower half. A forged signature only matters at verification time — there's no retroactive attack on past authentications — so certificates, code signing, and identity can trail key exchange by years. (The exceptions: firmware and root certificates whose verification lifetime spans decades — those need PQ signatures early.)
• What survives untouched: AES and SHA-2/3 lose only half their effective bits to Grover's algorithm — AES-256 and SHA-256 remain safe. The migration replaces the public-key layer, not your symmetric or hashing stack.

The alphabet, finalized by NIST in August 2024 after an eight-year global competition:

• ML-KEM (FIPS 203, née Kyber) — lattice-based key encapsulation; the TLS workhorse. ML-KEM-768 is the recommended default.
• ML-DSA (FIPS 204, née Dilithium) — lattice-based signatures; the general-purpose replacement for RSA/ECDSA certificates.
• SLH-DSA (FIPS 205, née SPHINCS+) — hash-based signatures; slower and bigger but resting on the most conservative assumptions; the belt-and-suspenders option for firmware and roots. HQC, a code-based backup KEM selected in 2025, becomes the fourth standard (draft expected ~2026–27) as insurance against lattice cryptanalysis.

Deployment status as of mid-2026 — further along than most engineering leaders assume:

• Browsers: Chrome and Firefox negotiate hybrid X25519+ML-KEM-768 key exchange by default; a large and rising share of human web traffic to major CDNs (Cloudflare reported ~half by 2026) is already quantum-resistant on the key-exchange half. Akamai turned hybrid on by default for customers in February 2026.
• Protocols and stacks: OpenSSL 3.5 ships native ML-KEM/ML-DSA; Signal (PQXDH) and Apple iMessage (PQ3) run post-quantum messaging at billions-of-users scale; SSH, VPNs, and major cloud KMS services offer PQ modes.
• Mandates: CNSA 2.0 requires US national-security systems to begin PQC adoption by January 2027 with class-by-class deadlines through 2033; NIST's transition guidance (IR 8547) targets deprecating RSA/ECC by 2030 and disallowing them by 2035; the EU and UK have published aligned national roadmaps with 2030–2035 horizons.

Note the pattern in every serious deployment: hybrid — classical + post-quantum run together, session keys derived from both, so an attacker must break X25519 and ML-KEM. Hybrid converts "trust the new math" into "trust either math," which is what made default-on politically possible this early.

• Handshakes get heavier, mostly tolerably. ML-KEM-768 adds roughly 1–2 KB in each direction versus X25519's 32 bytes; measured TLS impact at CDN scale is single-digit-percent latency in the median, worse on lossy/constrained networks (where an extra packet can mean an extra round trip). CPU cost is comparable to or better than classical ECDH — lattice math is fast; size, not speed, is the tax.
• Signatures are the real bloat. An ML-DSA signature runs ~2.4–3.3 KB against ECDSA's ~64–96 bytes, and a full PQ certificate chain multiplies that — one reason certificate migration trails key exchange, and why standards work on shorter chains and merkle-tree certificates is active. Expect PQ certificates in general web PKI to phase in over 2026–2029 rather than arrive at once.
• Embedded and long-lived devices are the hard tail. Cars, meters, medical devices, and industrial controllers shipping in 2026 will still be verifying signatures in 2040 — anything without crypto-agility (upgradable algorithms) being deployed today is future e-waste with a compliance deadline. This, not the web, is where migration pain concentrates.
• Interop archaeology. The migration is exposing decades of middlebox assumptions — TLS inspection appliances, hardcoded cipher lists, handshake-size limits. Budget for discovery of systems nobody knew still existed; every crypto transition in history has been mostly an inventory problem wearing a math costume.

• 1. Inventory (start this quarter). Build a cryptographic bill of materials: every TLS endpoint, certificate, library, protocol, HSM, and hardcoded algorithm — including which suites your endpoints actually negotiate today. Inspecting your own certificates' key types, signature algorithms, and expiries is the literal first work item, and it's automatable.
• 2. Classify by data lifetime. Apply Mosca's inequality per system: anything protecting 10+-year secrets over networks gets priority; ephemeral traffic can ride the default browser/CDN wave.
• 3. Enable hybrid key exchange where it's a checkbox. For most stacks behind modern CDNs, load balancers, or OpenSSL 3.5+, hybrid ML-KEM is now configuration, not engineering. Take the free win and measure handshake sizes on your worst networks.
• 4. Demand crypto-agility in everything you buy. Procurement language requiring upgradable algorithms and PQ roadmaps costs nothing today and prevents the 2035 hostage situation. For anything you ship with a 10+-year life, PQ signatures (or at least agile verification) should be a 2026 requirement, not a future one.
• 5. Sequence signatures deliberately. Roots and firmware first (longest verification lifetimes), then code signing, then leaf certificates as CAs and standards mature. Watch CNSA 2.0 and NIST IR 8547 dates — they're becoming the de facto commercial schedule via vendor compliance.
• 6. Assign an owner. Every successful crypto migration in history had a named team and a deadline; every failed one had a committee and a someday. The 2030 deprecation date is seven certificate renewals away — that's the whole margin.