Post-quantum migration: inventory first, agility second, algorithms last

A post-quantum migration is the work of replacing the public-key cryptography you rely on today with algorithms a quantum computer cannot break, before that computer exists.

It is not a switch you flip. It is a multi-year programme, closer in shape to the move off SHA-1, or to IPv6, than to a patch. And the part that decides whether it goes smoothly is not which algorithm you pick. It is whether you know where your cryptography lives and whether you can change it without rebuilding the system around it.

What a quantum computer actually breaks

Be precise here, because the panic usually is not. A large, fault-tolerant quantum computer running Shor's algorithm would break the maths behind RSA and elliptic-curve cryptography: the key exchange and the digital signatures that sit under almost every TLS session, code signature, VPN tunnel and SSH connection in use today. That is the real exposure.

Symmetric cryptography and hashes are far less affected. Grover's algorithm chips at them, but only enough that moving to AES-256 and SHA-384 keeps you comfortable. So a post-quantum migration is not "replace all your cryptography." It is a targeted replacement of the public-key half: key establishment and signatures.

Why now, and not when the computer arrives

The threat does not wait for the hardware. The near-term risk is harvest now, decrypt later: an adversary records your encrypted traffic, or copies your encrypted data, today, stores it, and decrypts it once a capable quantum computer exists. Anything that has to stay confidential for years, health records, government data, long-lived intellectual property, anything with a long regulatory retention period, is already exposed in that model even though nothing has been broken yet.

That is why the deadlines are real without a quantum computer in the room. NSA's CNSA 2.0 sets a path for national security systems to prefer post-quantum algorithms from around now and use them exclusively by the early 2030s, with full migration targeted by the middle of the decade, and the EU published a coordinated roadmap on a similar horizon. If you sell to government, that timeline reaches you through procurement whether or not you are directly in scope.

The destination

The standards exist now, which removes the old excuse to wait. NIST finalised the first three in August 2024: ML-KEM (FIPS 203) for key establishment, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. For firmware and software signing specifically, the hash-based schemes LMS and XMSS are already recommended and available, because code you sign today is verified for a long time and that is exactly the long-lived case.

You do not deploy these alone at first. The recommended path is hybrid: run a classical algorithm and a post-quantum one together, so a session or a signature is safe unless both are broken. Hybrid key exchange combining X25519 with ML-KEM is already shipping in major browsers and across large content delivery networks. This is not theoretical. It is in production traffic now.

The migration, in order

Here is the shape that works. The order matters far more than the algorithm choice.

1. Inventory first. You cannot migrate cryptography you have not located. Find where public-key crypto is used: TLS certificates, code signing keys, VPN and SSH configurations, encrypted data stores, the libraries your applications pull in, and the kit your vendors ship. Record the algorithms, the key lifetimes, and which data must stay secret longest. The output is sometimes called a cryptographic bill of materials. This stage is the bulk of the early effort, and it pays off regardless of what comes next.
2. Prioritise by exposure. Long-lived secrets and long-lived systems go first, because they carry the most harvest-now-decrypt-later risk and are the hardest to change later. A short web session matters less than a firmware signing key that has to be trusted for a decade.
3. Build crypto-agility. The ability to change algorithm without re-architecting. Most legacy systems hard-wire their cryptography, and that rigidity, not the new maths, is what makes the migration slow. Anything that needs a firmware update or a vendor release to change algorithm, think IoT, OT and SCADA, cannot pivot quickly, so it needs attention early.
4. Roll out, hybrid first. Turn on hybrid where it is supported, starting with lower-stakes systems, and keep the classical algorithm alongside until confidence is high. The algorithm choice, the part everyone fixates on, is the last and easiest step.

Where it gets hard

• The crypto you do not control. Vendor products, managed services and dependencies carry their own algorithms. Part of your migration is a procurement exercise: ask for roadmaps, and set post-quantum support as a requirement.
• Signatures outlive sessions. A TLS session lasts seconds. A signed firmware image or a long-validity certificate is trusted for years, so signing migrations need a longer runway than transport encryption.
• Bigger keys and payloads. Post-quantum keys and signatures are larger than their classical equivalents, which can stress constrained devices, packet sizes and handshake budgets. Test, do not assume.
• The certificate tie-in. Shorter certificate lifetimes and automated issuance, already arriving for other reasons, use the same muscles you need for an orderly post-quantum certificate transition. The teams that automated their certificate lifecycle will migrate far more smoothly.

Best practices

1. Build the cryptographic inventory before anything else. It is the deliverable that makes every later decision possible.
2. Rank by data lifetime and system lifetime, and start where harvest-now-decrypt-later bites hardest.
3. Make crypto-agility a design requirement for anything new, so the next change is configuration rather than a rebuild.
4. Adopt hybrid first, in lower-stakes environments, before you touch anything critical.
5. Put post-quantum readiness into vendor and procurement requirements, because much of your exposure sits in code you did not write.
6. Track the standards and the deadlines that apply to you (NIST, CNSA 2.0, and your sector's regulator) rather than guessing.
7. Do not invent your own scheme or rush an exotic one. Use the finalised standards, in hybrid mode.

The part to take away

A post-quantum migration is inventory first, agility second, and algorithms last. The cipher is the easy decision and the final one. The hard part, the part worth starting now, is knowing exactly what cryptography you have and being able to change it without rebuilding the system around it.

Harvest now, decrypt later means the clock for your long-lived data started a while ago. The work that protects it is not glamorous, and it is mostly an inventory.