Getting ahead of post-quantum: what to inventory now

In August 2024, NIST finalised its first post-quantum cryptography standards: FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. That milestone moved post-quantum from a subject for researchers to a planning concern for anyone responsible for systems that must stay confidential for years.

The threat model that matters today is not a quantum computer breaking your traffic tomorrow. It is harvest-now-decrypt-later: an adversary capturing encrypted data now, in the expectation of decrypting it once sufficiently capable quantum hardware exists. Any data whose sensitivity outlives the migration timeline is already exposed to that risk, which is why the clock effectively started before the hardware arrived.

For most organisations, the honest near-term priority is not to migrate. It is to build a cryptographic inventory, and almost no one has one. You cannot protect what you cannot see, and cryptography is scattered: TLS termination, stored secrets, signed tokens, document signing, code signing, hardware modules, and the long tail of libraries pulled in by dependencies. The first deliverable is a map of where cryptography is used, for what, and with what algorithms and key lifetimes.

That map immediately pays for itself, independent of quantum concerns. Most inventories surface expired certificates, deprecated algorithms still in use, and keys with no owner and no rotation policy. Fixing those is good hygiene that improves your posture today, and it is the necessary foundation for any future transition.

The design principle to adopt now is crypto-agility: building systems so the algorithm can be changed without re-architecting the application around it. Where cryptographic choices are abstracted behind a clear interface, a future transition to post-quantum algorithms becomes a controlled change rather than a rebuild. Where they are hard-coded and scattered, it becomes a very expensive one.

None of this calls for alarm or a rushed rip-and-replace. It calls for the unglamorous groundwork: inventory what you have, fix what is already broken, and make your cryptography agile enough to move when the time comes. Organisations that do that quietly now will treat the eventual migration as routine.