Lessons from implementing post-quantum cryptography
Migrating to quantum-safe cryptography is less about picking an algorithm and more about knowing where your cryptography lives. Hard-won lessons from the work.
“Quantum-safe cryptography” sounds like an algorithm choice. In practice, the algorithms are the easy part. Now that the standards are settled — NIST has finalised ML-KEM, ML-DSA and SLH-DSA — the hard work is everything around them: finding where cryptography lives, changing it without breaking the systems that depend on it, and doing so before adversaries who harvest encrypted data today can decrypt it tomorrow.
Here is what we have learned actually doing it.
1. You cannot migrate what you cannot see
Every post-quantum migration begins with an uncomfortable discovery: nobody has a complete picture of where cryptography is used. It is in application code, yes — but also in TLS terminators, service meshes, message queues, database encryption, code-signing pipelines, HSMs, hardware, and a long tail of third-party libraries and vendor products.
The cryptographic inventory is the project’s critical path, not a preliminary. Budget for it accordingly. Automated scanning gets you started; it does not get you finished, because the riskiest cryptography is often the least visible — hard-coded, embedded in firmware, or buried in a dependency three levels down.
2. Crypto-agility beats any single algorithm
The systems that migrated smoothly were not the ones that chose the “right” algorithm early. They were the ones that had cleanly separated what they were protecting from how they were protecting it.
Where cryptographic primitives were abstracted behind a well-defined interface, swapping them was a contained change. Where algorithms, key sizes and formats were hard-wired throughout the code, every change rippled outward unpredictably. The lesson is durable well beyond this migration: build for the next cryptographic transition, because there will be one.
3. Go hybrid, and expect the sizes to hurt
In practice, the pragmatic path is hybrid — running a classical algorithm and a post-quantum one together, so you are no weaker than before even if one is later found wanting. That decision is now well supported, but it comes with a cost that surprises teams: post-quantum keys, ciphertexts and signatures are much larger than what they replace.
Bigger handshakes overflow assumptions baked in years ago — packet size limits, buffer sizes, records that were sized for a world of small elliptic-curve keys. We have seen migrations blocked not by cryptography but by a middlebox that silently dropped a larger-than-expected handshake. Test against real network paths, not just a happy-path lab.
4. It is a supply-chain problem, not a code problem
Very little of your cryptography is yours. It comes from TLS libraries, operating systems, HSM firmware, cloud key-management services, and every partner you exchange data with. Your migration therefore moves at the speed of your slowest dependency.
You can be fully post-quantum in your own code and still not be quantum-safe end to end.
Map the dependency chain early, put post-quantum readiness into procurement and vendor questionnaires, and track the roadmaps of the components you cannot change yourself. Some of them will be the long pole; you want to know which ones now.
5. Prioritise by data lifetime, not by system importance
The instinct is to start with the most critical systems. For the quantum threat specifically, the better lens is confidentiality lifetime. Data that must stay secret for ten or twenty years — and is exchanged over channels an adversary can record today — is exposed to “harvest now, decrypt later” right now, regardless of when large quantum computers arrive.
That reframing changes the order of work. Long-lived secrets and the key exchange protecting them come first; short-lived session data and signatures (which are only at risk once a capable quantum computer actually exists) can follow.
6. Treat it as a programme, governed for change
Post-quantum migration is not a project with an end date; it is a capability you stand up and keep. Standards evolved during the transition, guidance is still maturing, and implementations will need revisiting. The organisations coping well built governance that assumes change: a living inventory, owners for each cryptographic dependency, and a clear decision path for when — not if — something needs to be swapped again.
What we would tell you before you start
- Start the inventory now. It takes longer than any other part and everything depends on it.
- Invest in crypto-agility over algorithm debates. The interface matters more than the primitive.
- Test post-quantum sizes against real infrastructure, including the middleboxes and partners you do not control.
- Sequence by data lifetime. Harvest-now-decrypt-later is a present-day risk, not a future one.
- Govern it as an ongoing capability, not a one-off remediation.
None of this requires panic. It requires starting — deliberately, with eyes open — while there is still time to do it well rather than in a rush.
If you are planning a post-quantum migration, or want an independent read on your cryptographic exposure and a realistic path forward, get in touch.