How to build a cryptographic inventory (CBOM) in six steps

A cryptographic inventory, or CBOM when it is kept in a machine-readable format, is the list of every place your systems use cryptography and what each use depends on. If someone has asked you how exposed your company is to quantum computers, this is the only way to give an answer backed by evidence, and it is the first step in every published migration plan: the UK NCSC puts discovery before its 2028 milestone, OMB M-26-15 makes inventory the core of its first phase for US agencies, and the G7 financial roadmap lists “discovery and inventory” as phase two, right after awareness.

The guide below is written for the security architect or engineering lead who has to produce that inventory. It covers six steps, what to record for each item, and the mistakes we see most often in published advice and vendor pitches.

What goes into a cryptographic inventory?

Every use of public-key cryptography, and a record of the rest. For each item you want to know which algorithm and key size it uses, where it runs, who owns it, what data it protects, and how hard it would be to change.

The categories are broader than most teams expect:

Step 1: Decide the scope and who owns it

Start with the systems that protect data with a long shelf life, not with the whole company. Health records, pension and insurance data, national ID data, contracts and customer financial history are the typical candidates, because “harvest now, decrypt later” means their exposure starts the day the traffic is recorded.

Write down three things before anyone runs a scanner: which business units and environments are in scope for the first pass, who owns the inventory once it exists (usually security architecture, sometimes the PKI team), and what “done” means for this pass. A scoped first pass that finishes is worth more than a company-wide effort that stalls in the fourth month.

Step 2: Collect what the organization already knows

Before scanning anything, pull the lists that already exist. Your certificate authorities and certificate management tools know which certificates were issued, with which algorithms and when they expire. HSM consoles and cloud key management services can export key inventories. The CMDB, if it is maintained, knows which applications run where. Architecture diagrams, even old ones, show the integrations.

This step is cheap and it gives you the skeleton that scans will fill in. It also shows quickly where nobody knows the answer, which is itself a finding.

Step 3: Scan what is on the network

Network discovery tells you what cryptography is really negotiated, as opposed to what the documentation says. Scanning your TLS and SSH endpoints shows the protocol versions, key exchange groups, certificate algorithms and key sizes in use. Passive analysis of traffic at gateways catches internal services that nobody listed.

Record what you see, including the good news. Some connections are probably already post-quantum: OpenSSH 10.0 made the hybrid mlkem768x25519-sha256 key exchange its default in April 2025, and OpenSSH 10.1 warns when a session is not using a post-quantum key exchange. Browsers and large cloud providers have moved in the same direction. Knowing which connections already use hybrid key exchange keeps you from spending migration budget on them.

Scanning has limits. It shows the endpoint, not the code behind it, and it sees nothing that isn’t on the network: files encrypted at rest, signed documents, firmware.

Step 4: Look inside code, binaries and dependencies

Code analysis finds the cryptography that applications call directly. Static analysis tools can flag calls to cryptographic APIs and hard-coded algorithm names. A software bill of materials (SBOM) tells you which applications ship OpenSSL, Bouncy Castle or other libraries, and in which versions, which matters because upgrading a library is often the migration.

Look specifically for three things that cause pain later. Hard-coded algorithms, where the choice of RSA or a specific curve is written into the code instead of configuration. Keys and certificates stored in repositories or configuration files. Custom cryptographic code written in-house, which is rare but always expensive to migrate.

Commercial discovery tools from vendors such as IBM and SandboxAQ combine network, code and host scanning. CISA works with NIST’s National Cybersecurity Center of Excellence to evaluate automated cryptography discovery and inventory tools for US federal agencies. The tools save time, but check what they can see in your environment before you buy, especially for mainframes, packaged vendor software and devices.

Step 5: Ask your vendors and service providers

A large part of your cryptography lives in products you cannot scan or change: SaaS platforms, core banking and ERP systems, payment processors, HSM firmware, managed network services. The only way to inventory it is to ask.

A short questionnaire works better than a long one. Ask each vendor which public-key algorithms their product uses and where, whether they support ML-KEM (FIPS 203) and ML-DSA (FIPS 204) or hybrid modes today, what their dated roadmap for post-quantum support is, and whether cryptographic algorithms can be changed by configuration or require a new version. Vague answers are useful data too: a vendor that cannot answer in 2026 is a migration risk.

The G7 statement makes the same point for banks: smaller institutions depend heavily on vendors, and it suggests obtaining “detailed vendor roadmaps for specific cloud and cryptographic services” to plan. Add post-quantum clauses to contracts that are being renewed now, since many will still be in force in 2030.

Step 6: Record it in a standard format and rank it

A spreadsheet is fine for the first pass. For anything that has to last, use a standard format so tools can read it and you can exchange it with vendors. CycloneDX 1.6, released on 9 April 2024, added CBOM support, developed with IBM Research, to describe algorithms, keys, certificates and protocols and link them to the software components that use them.

Whatever the format, each entry needs at least these fields:

Then rank. The simplest method that works is two scores per item: how long the protected data must stay secret, and how hard the cryptography is to change. Items with long secrecy periods and hard changes (a VPN between data centers carrying customer records, an HSM model with no post-quantum firmware) go to the top of the migration plan. Items with short-lived data and easy changes can wait for normal upgrade cycles.

What are the common mistakes?

The most common one is treating the inventory as a one-time project. Certificates are reissued, applications are deployed and vendors are replaced every month. Connect the inventory to change management and certificate issuance so it stays current, and plan at least a yearly review. Payment organizations already have a version of this obligation: PCI DSS v4.0 requirement 12.3.3 asks them to keep an inventory of the cipher suites and protocols in use and review it at least once every twelve months.

Other mistakes we see in published plans:

• Counting certificates and stopping there. Certificates are the easiest part to find and only one part of the exposure.
• Treating symmetric cryptography as the main problem. AES-256 and SHA-2 are not the urgent issue; key exchange and signatures are.
• Leaving out hardware with long lifecycles. ATMs, POS terminals, meters and industrial devices bought today may still run in 2035.
• Writing the inventory for auditors instead of engineers. If the team doing the migration cannot use it to plan work, it needs more detail about ownership and changeability.

How long does a cryptographic inventory take?

It depends more on how organized your records are than on company size. A scoped first pass over critical systems is a matter of weeks when certificate and key management are centralized, and much longer when they are not. What takes longest is usually step 5, because vendor answers arrive slowly. That is one reason to start the questionnaires early, in parallel with scanning.

Deadlines set elsewhere make the timing concrete. The EU roadmap asks member states to begin inventories by the end of 2026, and the UK NCSC expects discovery and an initial plan by 2028. Our post-quantum migration deadlines tracker lists the rest, and our post-quantum cryptography explainer covers the algorithms you will be migrating to.

If you want help scoping and running the inventory, it is the first phase of our post-quantum cryptography migration work, and a lighter version is part of the quantum readiness assessment. Banks and insurers can see how it fits their regulatory context on the banking and finance and insurance pages.