The usual framing of post-quantum migration is a race against a machine that does not exist yet. That framing gets the deadline wrong, and the error runs in the dangerous direction.
An adversary who can record encrypted traffic today and store it does not need a quantum computer today. They need one eventually. Everything you transmit under classical key exchange right now is a bet that it will stop mattering before that day comes.
Work out your own deadline
The standard formulation is blunt and useful. Take the number of years your data must stay confidential, add the number of years your migration will take, and compare that sum to how long you think you have. If the sum is larger, you are already late.
Most teams badly underestimate the second term. Migration is not swapping a cipher suite. It is:
- Finding every place cryptography happens, including the vendored library nobody remembers adding
- Discovering which of those places have hard-coded key sizes or buffer assumptions
- Negotiating with every counterparty whose system you have to interoperate with
- Rolling out without breaking clients you do not control and cannot force to upgrade
On a codebase of any age, step one alone takes longer than anyone budgets. That is why Quantum-Safe Handshake ships an auditor alongside the transport.
What the audit keeps finding
We have run the auditor across a fair number of open codebases now. The recurring findings are boring, which is exactly why they survive.
Key sizes baked into buffers. A 32-byte array that has been correct for a decade. ML-KEM keys do not fit. The failure is not cryptographic, it is a buffer overflow in code nobody has touched since it was written.
Protocol fields with no room to grow. A single-byte algorithm identifier, or a length field that cannot express a larger key. Migrating means a wire format change, which means a flag day.
Transitive dependencies doing their own crypto. The application uses a modern library. A dependency three levels down bundles its own. Your migration is only as complete as the layer you forgot.
The hard part is not choosing the algorithm. That decision is made. The hard part is that your codebase has assumptions about key sizes written into places that are not labelled "crypto".
Hybrid, not replacement
We build hybrid by default: a classical key exchange and a post-quantum one, run together, with the shared secret derived from both. It costs bandwidth and a little handshake latency. It buys something worth more.
The post-quantum schemes are newer and have had less adversarial attention than the classical ones. A hybrid construction is broken only if both halves fall. Given how young the lattice-based analysis is relative to decades of work on the classical side, betting everything on the new thing would be a strange kind of confidence.
shared = kdf(
x25519(client_sk, server_pk), # classical half
ml_kem_768(client_sk, server_pk), # post-quantum half
transcript_hash,
)Bind the transcript hash into the derivation. Downgrade attacks in hybrid schemes are a real class of bug, and the mitigation is that both parties commit to what they think they negotiated.
Start with discovery
If you do one thing this quarter, do not pick an algorithm. Find out where your cryptography actually lives. Every team we have talked to was surprised by the inventory, and every one of them was surprised in the direction of more work, not less.