Building a Cryptographic Inventory: The Step Everyone Skips

Every organisation that wants to move to post-quantum cryptography hits the same wall first, and it is not algorithm selection. It is that nobody knows where the current cryptography actually is.

You cannot migrate what you cannot find. A cryptographic inventory is the unglamorous prerequisite for everything else, and it takes longer than anyone budgets for.

Why this is harder than it sounds

The instinct is to check the applications your team wrote. That is the easy portion and usually the smallest. Cryptography accumulates in places nobody thinks of as cryptographic:

• TLS termination at load balancers, proxies and CDNs, each with its own cipher configuration
• Certificates for internal services, expiring on schedules nobody tracks centrally
• Signed firmware on devices that cannot be updated remotely
• Database encryption at rest, with keys managed by the database rather than by you
• Backups encrypted years ago with a scheme nobody documented
• Vendor appliances whose internals you cannot inspect
• Code-signing keys held by one person who set them up in 2018
• Hardcoded keys and pinned certificates inside mobile applications

The pattern is that cryptography is usually a side effect of some other decision. Nobody decided to use RSA-2048; they chose a product that used it.

What to record

An inventory that lists only algorithms is not much use. For each item you want to be able to answer four questions.

Where is it? The specific system, component and configuration file. “The payments service” is not a location; a repository path or an appliance setting is.

What is it protecting, and for how long? This determines urgency far more than the algorithm does. Data with a thirty-year confidentiality requirement is a different problem from a session token.

Who can change it? Your team, or a vendor on their release schedule. If a vendor owns it, your migration timeline is theirs.

What breaks if it changes? Compatibility with clients, with partners, with stored data signed under the old scheme.

How to find it

Three passes, in this order, because each catches what the previous one missed.

Network observation

Scan your own estate the way an outsider would. TLS scanning tools will enumerate every listening endpoint, its protocol versions, cipher suites and certificate details. This is fast and produces a reliable picture of externally visible cryptography. It also frequently finds services nobody remembered were running.

Code and configuration search

Grep the estate for the obvious markers: crypto library imports, key file extensions, algorithm names, certificate paths. Static analysis tools designed for this exist and are worth using, but a determined text search across all repositories finds most of it.

Procurement and vendor review

The parts you cannot see require asking. Write to every vendor whose product handles data in transit or at rest and ask two questions: what do you use today, and what is your post-quantum roadmap. The quality of the answer tells you a great deal about whether that vendor will still be viable in 2032.

Then prioritise by data lifetime

Once you have the picture, the ordering is not by risk severity in the usual sense. It is by how long the protected data stays sensitive, because that determines exposure to capture-now attacks.

Key exchange protecting long-lived confidential data goes first. Signatures can generally wait, because forging one requires a quantum computer that exists at the time of the forgery rather than one that might exist later.

Keep it alive

An inventory produced once and filed is worth very little, because the estate changes weekly. The version that pays for itself is generated automatically — scanning on a schedule, feeding a dashboard, alerting when something new appears using a deprecated primitive.

That is a larger engineering investment than a one-off audit, and it is the difference between knowing your position and having known it once.