Every post-quantum migration plan rests on an inventory. Most organisations start by running a scanner, exporting a list of algorithms, and calling it a cryptographic bill of materials. That list is a useful input. It is not an inventory, and a roadmap built on it will not survive first contact with the systems it describes.
The difference is what each entry carries with it. A scan result tells you an algorithm appeared somewhere. A CBOM tells you which system uses it, who owns that system, what data it protects, how long that data stays sensitive, and how hard the algorithm would be to change.
The seven surfaces
Cryptography hides in more places than a code scanner reaches. A complete discovery exercise covers all of these, and a partial one should say plainly which it skipped.
- Source code, including vendored dependencies and generated clients
- Configuration, where cipher suites and key sizes are usually set and rarely reviewed
- Certificates and their issuance chains, including internal certificate authorities
- Network endpoints, observed rather than declared, because the declared position is frequently wrong
- Key stores and hardware security modules, including what each key actually protects
- Appliances and firmware, which often cannot be changed without a vendor release
- Third-party services, where your exposure is real and your control is not
The last two are where roadmaps break. An appliance you cannot upgrade and a payment provider who has no migration date are both hard constraints on your own timeline, and both are invisible to a code scan.
What every entry needs
An entry without these fields cannot be prioritised, which means it cannot be scheduled, which means it will not be fixed.
- 01Algorithm and parameters, including key size and mode, not just the family name
- 02Location, precise enough that an engineer can open it without asking you where it is
- 03Purpose, which distinguishes a signature that expires in an hour from a key protecting data for twenty years
- 04Owner, a named team rather than a department
- 05Data classification and sensitivity lifetime, which is what turns an inventory into a priority order
- 06Change difficulty, measured honestly, including whether a vendor release is on the path
- 07Evidence, the artifact the entry came from, so the finding can be re-checked rather than argued about
The sensitivity lifetime field does most of the work. Without it, every finding looks equally urgent, and teams default to fixing whatever is easiest rather than whatever is most exposed.
Why the inventory has to be rebuildable
A CBOM produced once by a consultancy and handed over as a spreadsheet is out of date the week after delivery. New services ship, certificates rotate, and vendors change their stack.
The deliverable that matters is the method, not the snapshot. That means the discovery queries, the parsing rules, the exclusions and why they were made, and a documented path to running the whole exercise again. If regenerating the inventory requires the original consultants, the client bought a document rather than a capability.
A reasonable first scope
Full coverage on the first pass is the wrong goal. It takes long enough that the organisation loses interest before anything is prioritised. A better first scope is every system that handles data with a sensitivity lifetime beyond five years, plus every internet-facing endpoint, plus the top twenty vendors by data exposure.
That produces a defensible starting register in weeks rather than quarters. The remaining estate gets added on a schedule, against a method that is already proven.