Post-quantum migration is a 2026 project

The post-quantum transition has been discussed as a distant problem for a decade. It is now a project with a schedule, standardized algorithms, and shipping implementations, and the reason to start is not that quantum computers exist.

harvest now, decrypt later#

The threat model that makes this urgent has nothing to do with when a cryptographically relevant quantum computer arrives.

An adversary records your encrypted traffic today and stores it. When they can break the key exchange — in five years, in fifteen — they decrypt the archive.

So the question is not "when will quantum computers work." It is: how long does your data need to stay confidential?

Session tokens: minutes. Do not care.
Customer PII: years to decades. Care a lot.
Medical records: a lifetime. Care enormously.
Government and defense: generational.
Source code and trade secrets: depends, usually longer than you think.

If anything you transmit has a confidentiality horizon past roughly 2035, traffic you send today is already at risk. That is the whole argument and it does not depend on any prediction about quantum hardware.

what is standardized#

NIST finalized the core standards:

ML-KEM (FIPS 203), formerly Kyber — key encapsulation. This is the one that matters for TLS.
ML-DSA (FIPS 204), formerly Dilithium — digital signatures.
SLH-DSA (FIPS 205), formerly SPHINCS+ — hash-based signatures, conservative fallback with larger signatures.

The guidance across national security agencies is consistent: begin migration now, complete it well before 2035, prioritize by confidentiality horizon.

what is already shipping#

More than most people realize.

TLS key exchange. Hybrid X25519 plus ML-KEM is deployed by default in major browsers and supported by major CDNs and load balancers. A meaningful fraction of web traffic is already post-quantum protected for key exchange, and most people running those services did not do anything to enable it.

Check yours:

bash

openssl s_client -connect example.com:443 -groups X25519MLKEM768 </dev/null 2>&1 \
  | grep -i "negotiated\|group"

SSH. OpenSSH has shipped post-quantum key exchange by default for several releases. If your servers are current, your SSH sessions are already hybrid.

Signatures are lagging, and that is the harder half. Certificate chains, code signing, and firmware verification all involve long-lived trust anchors and ecosystem-wide coordination. ML-DSA signatures and public keys are substantially larger than ECDSA, which has real consequences for handshake size, embedded devices, and anything with a fixed-size signature field.

what to actually do this year#

1. Inventory your cryptography. Where do you use asymmetric crypto, with what algorithm, and what is the confidentiality or integrity horizon? Most organizations cannot answer this and the exercise is more valuable than any individual migration step.

2. Get to hybrid key exchange. For most people this means: update TLS libraries, update the load balancer, verify the negotiated group. It is largely free and it addresses the harvest-now threat, which is the urgent one.

3. Build crypto-agility. The lasting fix is not "migrate to ML-KEM." It is "be able to change algorithms without a rewrite." Hard-coded algorithm choices scattered through a codebase are the actual problem, and they will be the problem again for whatever comes after this.

Centralize crypto in one module. Make the algorithm a configuration value. Version your protocol so you can negotiate.

4. Ask your vendors. Every SaaS provider, every library, every hardware security module. The answers will be uneven and asking creates the pressure that fixes it.

5. Do not roll your own. Use the vetted implementations. The failure mode for post-quantum crypto is a side-channel in a hand-written implementation of a lattice operation, and that failure is silent.

the thing that makes this hard#

It is a migration with no visible benefit. Nothing gets faster. No feature ships. The success condition is that in fifteen years, nothing bad happens.

That is the hardest kind of project to fund, and it is why the organizations that do it well will be the ones that started when it was still early enough to be cheap.