The cryptographic inventory nobody has

Every conversation about post-quantum cryptography starts in the wrong place. It starts with algorithms — which lattice scheme, what key sizes, how much larger the handshake gets. Those are solved problems now. NIST finalised its first post-quantum standards in 2024: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. The mathematics is not what will make you late.

What will make you late is that you cannot answer a much simpler question.

Where is cryptography actually used across your integration estate?

Not in the abstract. Specifically: which endpoints, which algorithms, which key lengths, whose certificates, expiring when, owned by whom. Most organisations we talk to have some of this for their public-facing web estate and almost none of it for the layer underneath — the one where systems talk to each other.

The estate you forgot you had

Ask for a list of every place cryptography appears between your systems and you will typically get a gateway inventory and a shrug. The gateway is the easy part. The rest looks like this:

• Mutual TLS on every partner link, each with its own certificate chain and its own renewal process
• Signed tokens moving between services — JWTs, SAML assertions — each with an algorithm choice made years ago by someone who has left
• SFTP key pairs with suppliers, several of which were generated once and never rotated
• Message queues with TLS pinned to specific certificates
• Encrypted payloads at rest in staging tables, some of which nobody remembers writing
• Hard-coded algorithm choices inside individual integration flows, which is the worst category because there is no central place to change them

None of this is exotic. It is the ordinary sediment of fifteen years of integration projects. It is also, collectively, the thing that has to migrate.

Why the inventory is the long pole

There is a natural assumption that discovery is the quick preliminary and migration is the real work. In our experience it inverts.

Migration of any single interface is usually straightforward once you know it exists, know who owns it, and know what the counterparty supports. Discovery is what takes months, because it is not a scan — it is archaeology. Half the answers live in people's heads, a quarter live in a runbook nobody has opened since the last audit, and the remainder require reading integration code to find where an algorithm was chosen inline.

You cannot sequence a migration against an estate you have not enumerated. You cannot even size the programme. Every budget number produced before the inventory exists is a guess, and in our experience it is a low one.

The clock is data lifetime, not Q-day

The other thing that gets misread is urgency, and it gets misread in a way that produces genuine complacency.

The common framing is: a cryptographically relevant quantum computer arrives at some point, call it Q-day, so finish migrating before then. That framing makes the deadline feel distant and negotiable.

It is the wrong clock. The right one is how long your data has to stay secret.

An adversary does not need a quantum computer to capture traffic. They need one to read it. Encrypted data copied off the wire today can sit in storage until the capability exists — the pattern usually called harvest now, decrypt later. Which means that for anything with a long confidentiality requirement, the exposure decision is being made right now, by the cryptography you are using today.

If a payload you transmit this quarter must stay confidential for ten years, its protection was decided this quarter — not on the day your migration programme finishes.

This is why a migration that completes comfortably before Q-day can still leave you exposed. It protects everything sent after it. It does nothing for what was already captured.

Practically, this reorders the work. Prioritisation should follow data lifetime, not system importance. The interface carrying material with a decade-long secrecy requirement outranks the busier one carrying data that is worthless in a fortnight.

What a real inventory produces

The deliverable is not a spreadsheet of algorithms. Done properly it is closer to a cryptographic bill of materials — a structured, maintainable record covering:

1. Every interface and endpoint, including the internal ones and the ones owned by a third party
2. The algorithms, key sizes and certificate chains each one actually uses in production, verified rather than assumed from documentation
3. Ownership — a named human for each, which is frequently the hardest column to fill
4. Counterparty dependency — which entries cannot move until an external partner moves, since these determine the programme's critical path
5. Data lifetime for what crosses each interface, which drives prioritisation

That fifth column is the one most inventories omit and the one that makes the rest actionable.

It pays for itself without quantum

Here is the part we would rather say out loud than bury.

Nobody credible knows when Q-day is. Estimates range from roughly a decade to considerably longer, and anyone quoting you a precise year is selling something. We are not going to build a business on a countdown clock.

But the work stands on its own. A verified inventory of every cryptographic dependency, automated certificate lifecycle management, and algorithm choice lifted out of hundreds of individual interfaces into a central policy layer — that is ordinary good engineering. It is what stops an expired certificate taking down a partner feed on a Sunday. It is what turns the next algorithm deprecation, quantum-driven or not, into a deployment rather than a programme.

Crypto-agility is the actual objective. Post-quantum is simply the forcing function that finally gets it funded.

If your organisation cannot currently produce that list, that is the first piece of work — and it is worth doing whether or not you believe the timeline.