Marin Ivezic
Most cryptographic inventories fail in the same way. Someone sends a survey to forty application owners, collects thirty-one responses, builds a spreadsheet with columns for system name, algorithm, and key length, and reports coverage. The spreadsheet is real. The coverage is not. What it records is the cryptography those thirty-one people happened to know about, which is a small and non-random subset of the cryptography actually running.
This matters more than it used to. Since NIST published its first post-quantum standards in August 2024 – ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures – the migration question has moved from theoretical to scheduled. And you can’t schedule a migration for systems you haven’t found.
This piece is about running an inventory that holds up. It is organised around what works and what fails, because in our experience the failures are consistent enough to be listed.
Start With What an Inventory Is For
A cryptographic inventory is a record of where cryptography is used across an organisation’s systems, what algorithms and key lengths are in use, what protects what, and who owns each instance. That last part gets dropped surprisingly often, and it is the part that determines whether the inventory is useful.
The purpose shapes the method. An inventory built to satisfy an auditor needs breadth and a signature. An inventory built to drive a migration needs enough detail that an engineer can open the record, find the system, and know what has to change. These are different documents. Teams frequently build the first while believing they have built the second, and discover the difference eighteen months later when migration planning starts and every record has to be reopened.
Decide which one you are building before you start. If the answer is the migration inventory – and for post-quantum work it should be – then the fields you need are stricter than they first appear. Algorithm name isn’t enough. RSA appears in a record; RSA-2048 for TLS termination on an internet-facing load balancer, owned by the platform team, with certificates issued from an internal CA on a 90-day rotation, is a record you can act on.
What Interviews Are Actually Good For
The standard critique of interview-based inventory is that people do not know their own cryptography. That is true, and we’ll get to why. But the critique gets applied too broadly, and teams end up discarding a method that does one job better than any scanner.
Do use interviews to map boundaries and ownership. Where does a trust boundary sit? Which team owns the certificate lifecycle for a given service? Which system talks to which, and where does a session terminate? Who signs off on a cipher suite change? No tool answers these. They live in people’s heads and in architecture decisions that were never written down, and an hour with the right engineer is faster than any amount of scanning.
Do use interviews to surface known unknowns. “We inherited that system in the 2019 acquisition and nobody here has looked inside it” is one of the most valuable sentences an inventory can capture. It converts an invisible risk into a tracked item.
Do use interviews to find vendor black boxes. When a product is closed and the vendor will not disclose implementation detail, the interview identifies the gap and starts the vendor conversation. Automation returns nothing useful here, because there is nothing to scan.
Do not use interviews to enumerate algorithms. This is the failure mode. Ask a developer which cryptographic algorithms their application uses and you will get an answer about the algorithms they chose deliberately. You will not get the ones the framework chose, the ones the database driver negotiated, the ones in the container base image, or the ones the hardware does below the operating system.
That’s how modern software is built, and no individual developer can see all of it.
Why the Answers Are Incomplete
Cryptography is designed to be invisible. A developer calls a function to write a record; underneath that call the connection is negotiated, the payload is encrypted in transit, the storage layer encrypts at rest, and the whole exchange is authenticated. None of this appears in the application code. It shouldn’t have to.
Three layers hide cryptography from the people best placed to report it.
Dependency depth. An application imports a library, which imports another, which imports a cryptographic implementation. The developer sees the first import. Dependency trees for a typical enterprise application run to hundreds of packages, and cryptographic functions sit several levels down in most of them.
Platform and runtime defaults. Cipher suites negotiated by a TLS library, key derivation performed by an identity provider, encryption applied by a managed database service – these are configuration, not code, and they are frequently owned by a different team from the one being interviewed.
Firmware and hardware. Secure boot chains, trusted platform modules, hardware security modules, disk encryption implemented in the drive controller, cryptographic instruction sets in the processor. This layer is invisible from the application entirely and is rarely documented outside the vendor’s specification sheet.
Then there are the organisational factors, which are less interesting technically and just as damaging in practice. Staff turnover takes implementation knowledge with it. Specialisation means the network team, the application team, and the identity team each hold a partial view and nobody holds the whole. And nobody wants to write “unknown” in a spreadsheet cell that a director will read, so ambiguity gets resolved optimistically.
The result is an inventory that systematically misses the categories hardest to remediate later.
What Discovery Tooling Catches
There’s no single tool that finds all cryptography, and any vendor claiming otherwise is describing an ambition. Different methods see different layers, and the practical question is which combination covers your environment.
Static Code Analysis
Static analysis examines source code or compiled artefacts without running them, looking for calls into cryptographic libraries, algorithm identifiers, and hard-coded key material.
It is fast across large codebases and it finds things nobody remembers writing – hard-coded keys, deprecated algorithm choices left in from a previous era, cryptography implemented by hand where a library should have been used. It needs source access, so it covers in-house code and open-source dependencies and stops at the boundary of anything proprietary. It also produces false positives at a rate that requires a human triage pass, and it misses anything loaded dynamically at runtime.
Dynamic Analysis
Dynamic analysis watches an application while it executes, recording actual calls into cryptographic libraries and the parameters passed to them.
This is the method that resolves the question static analysis leaves open: not what the code could do, but what it does. It catches dynamically loaded modules and it works without source access. The cost is setup – you need a running instance in a controlled environment – and coverage is limited to the execution paths your test traffic exercises. A code path that only runs during disaster recovery won’t appear.
Network Traffic Analysis
Network analysis inspects traffic in flight to identify protocols and negotiated parameters: TLS versions and cipher suites, SSH key exchange methods, anything still running unencrypted.
It finds deprecated protocol versions and unprotected internal traffic quickly, and it does so without touching any endpoint. It cannot see inside the encrypted payload, so it tells you nothing about cryptography used internally within an application, and it only sees traffic that crosses a point you are monitoring.
Configuration and System Scanning
Configuration scanning reads system settings, cryptographic policy, registry entries, and installed module inventories to establish what the platform is configured to do.
It catches organisation-wide policy – which cipher suites are enabled, which algorithms the operating system will accept – and it detects hardware security modules, which are dedicated devices that generate and store keys in tamper-resistant hardware. It requires privileged access on each system scanned, and it reports platform capability rather than application behaviour. A system configured to permit a weak cipher may never actually negotiate it.
Dependency Analysis
Dependency analysis walks the package tree of an application and identifies which components implement cryptographic functions, including transitively.
This is the direct answer to the dependency-depth problem, and it is the method most likely to surprise the application owner. It relies on accurate manifest data, so it degrades where dependencies are vendored, patched locally, or pulled outside the package manager, and it will not identify custom implementations that do not announce themselves as cryptographic.
Binary Analysis
Binary analysis dissects compiled executables to identify cryptographic routines by their structure and constants, without source code.
It reaches the closed third-party software that static analysis cannot, which makes it the method of choice for vendor products where disclosure has failed. It is slow, it needs genuine expertise to interpret, and optimised or obfuscated builds resist it.
Cloud Configuration Scanning
Cloud scanning queries provider APIs to identify key management configurations, encryption settings on storage and database services, certificate inventories, and managed identity configurations.
It is essential wherever meaningful workload runs in a cloud environment, and it captures a layer that no on-premises method reaches. Its limits are the provider’s limits: what the API exposes is what you get, and coverage differs between providers, which means separate tooling for each.
Certificate and Key Discovery
Certificate discovery enumerates the certificates and keys in use, their algorithms, key sizes, expiry dates, and issuing chains, building a view of the public key infrastructure – the system of certificate authorities, certificates, and keys that underpins identity and trust across an environment.
Certificates carry the heaviest cost in post-quantum migration, and this is the method that maps them. It maps the certificate estate well and it finds expired and orphaned material. It focuses on asymmetric cryptography and it misses keys embedded in application code or stored outside managed key stores.
Firmware and Hardware Analysis
Firmware analysis examines device firmware and embedded systems for cryptographic implementations: secure boot chains, signature verification routines, embedded keys.
In operational technology, industrial control, and connected device environments this is not optional, because that is where the cryptography lives and where it is hardest to change. It needs specialised tooling and expertise, and hardware diversity means each device family is close to a separate exercise.
Log Analysis
Log analysis mines existing system and application logs for records of cryptographic operations, negotiation failures, and deprecation warnings.
It costs almost nothing to start because the data already exists, and deprecation warnings in particular are a cheap source of findings. What it sees depends entirely on what was logged, so coverage is uneven and often thin.
The Combination, Not the Tool
Read those ten together and the pattern is clear. Static analysis covers code you wrote. Binary analysis covers code you bought. Network analysis covers what crosses the wire. Configuration scanning covers what the platform permits. Certificate discovery covers the identity layer. Firmware analysis covers everything below the operating system.
Each one has a blind spot that another one covers, which is why the selection question is not “which tool is best” but “what does my environment look like, and which combination covers it.”
Do start from an environment assessment. An organisation running mostly in-house applications in a single cloud has a different tooling profile from a utility with two decades of accumulated operational technology and a small software estate. Map your own shape first: how much code is yours, how much of the estate is cloud, how much is embedded, how old is the oldest thing still in production.
Do run a pilot before committing. Pick one representative system, run two or three candidate tools against it, and compare what each returned. This surfaces integration friction, false positive rates, and output format problems while they are still cheap to discover.
Do plan for the triage pass. Every automated method produces findings a human has to assess. Budget for it. An inventory programme that funds the tooling and not the analyst produces a database of unreviewed alerts.
Do not treat tool coverage as inventory coverage. A scanner that ran successfully across 400 hosts covered 400 hosts, not the estate. Track what was in scope, what was out of scope, and why, as a first-class part of the inventory record.
Turning Findings Into a CBOM
A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable record of the cryptographic assets in a system: the algorithms, key lengths, protocols, certificates, and the relationships between them and the components that use them. It is the cryptographic equivalent of a Software Bill of Materials (SBOM), which lists software components and their dependencies, and the CBOM concept was proposed as an extension to the CycloneDX specification for exactly that reason.
The word “structured” is doing the work in that definition. A spreadsheet is a record; a CBOM is a record with a schema, which means it can be diffed against last month’s version, queried for every instance of a given algorithm, and consumed by other tooling. When ML-DSA or SLH-DSA adoption reaches your certificate authority, the question “which of our services will this affect” should be a query, not a project.
Building one from discovery output involves four steps, and the second is where most of the effort goes.
Aggregate. Pull findings from each tool into a common store. Different tools name the same thing differently, so this step includes normalising algorithm names, key size representations, and system identifiers. It’s tedious and it’s unavoidable.
Deduplicate and reconcile. The same cryptographic instance will be reported by several methods, and the reports will not agree. Static analysis says the code supports three cipher suites; network analysis says one is actually negotiated; configuration scanning says a fourth is permitted by policy. All three are true and they describe different things. Resolve these into a single record that states what is configured, what is used, and what is possible, because migration planning needs all three.
Enrich. Add what the tools cannot see: system owner, business function, data classification, dependency relationships, and vendor status for anything closed. This is where the interview output goes, and it is the step that turns a technical scan result into something a migration programme can plan against.
Classify by quantum exposure. Separate what breaks from what weakens. RSA, elliptic curve cryptography in its usual forms, Diffie-Hellman key exchange – these are broken by a sufficiently capable quantum computer running Shor’s algorithm, and they need replacement. Symmetric cryptography is in a different position: Grover’s algorithm offers a quadratic speedup against key search, which is a real effect but a manageable one, and AES-256 remains comfortably outside its reach. Treating both categories with equal urgency wastes effort on the wrong systems.
Do record uncertainty explicitly. A field for confidence, and a field for how the finding was discovered, cost nothing at entry and are invaluable later. “Algorithm unconfirmed, vendor request outstanding, opened 2025-03-14” is a better record than a blank cell or a guess.
Do not build the CBOM as a one-off document. The estate changes weekly. An inventory produced as a project deliverable is accurate on the day it is signed and degrades from there. Wire the discovery tooling into whatever runs continuously in your environment, even if the initial pass is a project.
Prioritise by Data Lifetime, Not by System Criticality Alone
The usual instinct is to rank systems by business criticality and migrate downward from the top. That ordering is reasonable for most security work and it is incomplete for post-quantum migration, because of harvest now, decrypt later – HNDL, the practice of capturing encrypted traffic today and storing it until a quantum computer capable of breaking it becomes available. Under HNDL, the exposure of a system depends on how long its data stays sensitive, not only on how important the system is today.
A payment authorisation service is highly critical and its individual messages lose sensitivity in hours. A file transfer channel carrying long-term contracts, personal data, or intellectual property might rank lower on a criticality register and carry far more HNDL exposure, because a copy captured today is still damaging in fifteen years.
So the inventory needs a data-lifetime field, and prioritisation should read both columns. Systems that are critical and carry long-lived confidential data go first. Systems that carry long-lived data but are not otherwise prominent belong higher in the queue than an ordinary criticality ranking would place them.
Do capture data retention and sensitivity duration during enrichment. It’s far cheaper to ask while you have the system owner’s attention than to run a second pass later.
Do not defer everything until the inventory is complete. Some systems are known to need migration regardless of what discovery finds – anything terminating TLS externally, anything with an RSA-based signing chain, anything with certificates in a long-lived trust anchor. Start those while discovery continues. Sequencing the two in parallel is not a compromise between thoroughness and speed; it is what a competent programme looks like.
The reverse error is equally common: declaring inventory unnecessary because “everything needs replacing anyway.” Everything does eventually need attention, and that tells you nothing about order, dependency, or effort. An organisation that starts remediating without an inventory will migrate the systems it can see, and the systems it cannot see are precisely the ones that will still be running RSA-2048 in 2033.
Design the Inventory So It Survives the First Migration
Crypto-agility is the field most inventories omit, and it decides how much of the record is still usable after the first migration. The term means a system can change its cryptographic algorithms without redesign – algorithms configured rather than compiled in, key sizes parameterised, protocol versions negotiable. That is the actual goal of post-quantum preparation, because ML-KEM and ML-DSA are the current answer, not the final one, and the next transition will come.
The inventory should support that goal, which means recording not only what algorithm a system uses but how hard it would be to change it. A service reading its cipher suite from a configuration file and a device with an algorithm burned into firmware may hold identical entries in an algorithm column and represent completely different remediation projects.
Do add an agility assessment to each record. Three levels is enough: configurable without code change, requires code change, requires hardware or vendor replacement. That single field is the difference between a migration estimate and a guess.
Do not let the inventory become a static artefact owned by nobody. Assign it an owner, give it a review cadence, and connect it to change management so that new systems enter it at deployment rather than at the next audit.
The Short Version
Interviews map boundaries, ownership, and known unknowns. They do not enumerate algorithms, because the people being interviewed cannot see most of the cryptography in their own systems, and that is a property of how software is built rather than a failure of diligence.
Automated discovery finds what interviews miss, and no single method finds everything. Match the combination to your environment, pilot before you commit, and budget for the human triage pass that every automated method requires.
Consolidate into a structured CBOM rather than a spreadsheet, because the value of the inventory is realised at query time, months and years after collection. Record uncertainty, record how each finding was discovered, and record how hard each instance would be to change.
Prioritise on data lifetime alongside criticality, and start remediating the obvious cases while discovery continues.
Cryptographic inventory is one of the practical skills covered in Quantum Academy’s post-quantum cryptography programs, alongside migration planning, algorithm selection, and building the business case for a PQC program. You can see the full portfolio and current enrollment options at quantumacademy.com/.
For migration methodology in depth, including inventory as a phase within a full program structure, see pqcframework.org. For deeper technical background on the algorithms and the threat model behind them, PostQuantum.com covers both at length.