Every TLS handshake your systems complete today can be captured and stored by an adversary who plans to decrypt it later. That is the entire threat model behind harvest-now-decrypt-later: attackers do not need a quantum computer to start; they need your ciphertext, patience, and storage — all of which are cheap. For data with a confidentiality lifetime measured in decades — health records, intellectual property, state contracts, long-lived key material — the exposure window did not open when quantum hardware matured. It opened the day someone started recording your traffic.
The standards debate, meanwhile, is over. NIST finalized FIPS 203 (ML-KEM, from the Kyber lineage), FIPS 204 (ML-DSA, from Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) in August 2024. Major browsers and CDNs negotiate hybrid post-quantum key exchange in production today. What remains is not cryptographic research. It is an engineering migration, and it behaves like every large migration you have ever run — inventory, prioritization, dual-running, cutover — except the deprecated component is mathematics.
Why the deadline is fuzzy but the work is not
Nobody can tell you the year a cryptographically relevant quantum computer arrives, and anyone selling you a date is selling something else too. Regulators stopped waiting. The NSA's CNSA 2.0 guidance pushes US national security systems toward quantum-resistant algorithms with hard milestones stretching to 2033. European agencies including BSI and ANSSI recommend hybrid schemes now. The useful planning tool remains Mosca's inequality: if the time your data must stay secret plus the time your migration takes exceeds the time until a capable quantum machine exists, you are already late. For most enterprises the migration term alone — realistically five to ten years across a full estate — dominates the equation.
Start with a cryptographic bill of materials
You cannot migrate what you cannot see, and cryptography hides everywhere:
- ▸Transport: TLS terminators, service meshes, VPN concentrators, SSH fleets, message brokers.
- ▸Identity and signing: PKI hierarchies, JWT and OIDC token signing, code signing, document signing, firmware verification.
- ▸Data at rest: database TDE, disk encryption, backup encryption, KMS and HSM configurations.
- ▸The long tail: embedded devices, IoT fleets, smart cards, and third-party SaaS you do not control.
Build a cryptographic bill of materials (CBOM) — CycloneDX 1.6 added first-class support for exactly this. Combine passive network observation of negotiated cipher suites with static scanning for crypto API usage, then record the algorithm, key size, library, and — critically — how hard each usage is to change.
Hybrid first: what to deploy in 2026
For key exchange, the answer is settled: hybrid X25519MLKEM768 in TLS 1.3. Chrome and Firefox negotiate it, OpenSSL 3.5 ships ML-KEM, and the large CDN and cloud providers support it at the edge. Hybrid construction matters because it fails safe — a break in either component still leaves the other protecting the session. Signal's PQXDH and Apple's PQ3 for iMessage are good design references for the same principle in messaging protocols.
Signatures are the harder half. ML-DSA signatures run to several kilobytes, certificate chains carry multiple signatures, and bloated handshakes collide with middlebox assumptions and MTU limits in ugly, hard-to-debug ways. Expect PKI migration to trail key-exchange migration by years, and test early: some network gear silently drops large ClientHello messages, and you want to find that appliance in staging.
A pragmatic migration roadmap
1. Assign ownership — a named engineer with budget, not a working group with a wiki. 2. Build the CBOM and keep it continuously updated; treat it like your SBOM. 3. Classify data by confidentiality lifetime; anything sensitive beyond 2035 migrates first. 4. Enable hybrid key exchange at internet-facing termination points and measure handshake failures. 5. Add PQC readiness to vendor contracts: demand algorithm roadmaps and crypto-agility guarantees in writing. 6. Refactor for crypto-agility — route all cryptography through a small internal abstraction so the next algorithm swap is a configuration change, not an archaeology project. 7. Stand up a parallel PQC test PKI and rehearse issuing, rotating, and revoking ML-DSA certificates before production forces you to.
Where teams actually get stuck
- ▸Hardcoded assumptions: 32-byte key buffers, fixed-size database columns for signatures, protocol fields sized for RSA-2048. These are the silent killers of any swap.
- ▸Hardware dependencies: HSMs and smart cards need firmware support for the new algorithms, and procurement cycles for that hardware are measured in years.
- ▸Device fleets: a payment terminal or industrial sensor deployed today with classical-only crypto will still be in the field in 2035. Buy crypto-agile or accept the writedown.
- ▸Do-it-yourself hybridization: combine algorithms only through standardized constructions. Hand-rolled composite schemes are how you fail both an audit and an attack.
The business case does not depend on guessing the quantum timeline. A current cryptographic inventory shortens every future incident response. Crypto-agility turns the next algorithm deprecation — quantum or otherwise — into routine maintenance. And regulators, cyber insurers, and enterprise customers are already asking for PQC roadmaps in due diligence. The organizations that treat post-quantum migration as a decade of small, boring, well-sequenced changes will barely notice the transition. The ones that wait for a headline will do it as an emergency, at emergency prices, on someone else's schedule.