Crypto Inventory & CBOM (Cryptography Bill of Materials): The Guide

Last updated: October 24, 2026 | Affiliate Disclosure

Every PQC plan eventually runs into the same question: where are we actually using cryptography today?

Not “in theory.” Not “the standard stack.” I mean:

  • which endpoints still negotiate RSA,
  • where ECDSA is assumed in certificate profiles,
  • which appliances hard-code algorithms,
  • which signing keys live in an HSM vs a laptop keystore,
  • which devices can’t be updated,
  • and which teams own each dependency.

That’s a crypto inventory problem. A CBOM turns that inventory into a structured artifact you can share and track.

What Is CBOM?

A Cryptography Bill of Materials (CBOM) is an inventory representation of cryptographic assets and their relationships (algorithms, keys, certificates, and how they map to components/services).

CycloneDX explicitly supports CBOM modeling and describes CBOM as a way to represent cryptographic assets and dependencies.
Source: CycloneDX CBOM capability page
https://cyclonedx.org/capabilities/cbom/

CycloneDX v1.7 is standardized as ECMA‑424 (Dec 2025) and explicitly includes modeling for cryptographic artifacts.
Source: ECMA‑424 page
https://ecma-international.org/publications-and-standards/standards/ecma-424/

Crypto inventory vs CBOM (why you want both)

  • Crypto inventory is the operational reality: a dataset you can query (“show me all endpoints using ECDHE with X25519”; “show me certificates expiring in 30 days”; “show me RSA signing keys in non-HSM storage”).
  • CBOM is the portable, shareable representation: something you can attach to systems/releases, hand to auditors, or use to coordinate migration.

You can start with an inventory and generate a CBOM later. But you should decide early what you want the CBOM to be for (PQC readiness reporting, compliance, procurement, or internal governance).

What to inventory (the minimum useful set)

A crypto inventory that actually helps PQC work includes at least these five buckets:

1) Protocol posture (what you negotiate on the wire)

  • TLS versions and cipher suites / groups in use
  • SSH KEX algorithms in use
  • VPN/IKE configurations in use (where available)
  • exposed endpoints and their certificate chains

2) Certificates and trust

  • public and private CAs (roots/intermediates)
  • issuance profiles/templates (what algorithms and key sizes they assume)
  • where trust stores are managed and updated
  • certificate consumers (services, devices, agents)

3) Keys (custody and access)

  • where private keys live (HSM, KMS, software keystore, file system)
  • which are exportable vs non-exportable
  • who can use them (roles, service identities, approvals)
  • rotation policies and last rotation dates

4) Signing systems (the “long-lived validity” area)

  • code signing, firmware signing, document signing
  • which artifacts are signed and how verifiers validate
  • timestamping usage (if any) and verification constraints

5) “Hard to change” dependencies

  • embedded devices
  • vendor appliances
  • legacy clients
  • environments with compliance constraints that limit crypto module choices

This last bucket is where timeline risk hides.

Where crypto inventory data actually comes from (real sources)

A strong crypto inventory is usually assembled from multiple streams:

A) External observation (what your internet-facing endpoints present)

  • handshake scanning and certificate chain collection
  • Certificate Transparency log monitoring (for public certs)

This is often the fastest “start tomorrow” stream.

B) Internal observation (what your internal endpoints negotiate)

  • internal TLS scans
  • service mesh/control plane telemetry (if applicable)
  • load balancer and proxy telemetry (where available)

C) PKI and issuance logs (what you issued)

  • CA logs (public CA portals, internal CA issuance logs)
  • CLM platform inventories

D) Code/build-time evidence (what your software depends on)

  • SBOMs + build metadata (libraries that include crypto)
  • dependency graphs where crypto libraries appear
  • CI policy checks (“this repo uses X crypto provider; approved?”)

E) Key management evidence (what lives in HSM/KMS)

  • KMS inventories and IAM policy attachments
  • HSM partitions, key objects, signing operations logs (where available)

The “right” approach is layered. No single source gives you the full truth.

What makes a CBOM useful (and what makes it shelfware)

A CBOM becomes valuable when:

  • it has ownership (assets map to teams/systems)
  • it has lifecycle context (prod vs dev; release ID; time captured)
  • it tracks algorithm families and parameter sets, not just “PQC yes/no”
  • it’s updated on a schedule (or per release), not once

A CBOM becomes shelfware when it’s a one-time spreadsheet with no owner and no update cycle.

How CBOM supports PQC planning (without becoming bureaucracy)

Here are concrete, practical uses:

  • Prioritization: find where RSA/ECC is used in “hard to update” places.
  • Procurement: ask vendors for explicit roadmaps against your inventory.
  • Risk reduction: eliminate expired certs and weak configurations now (independent of PQC).
  • Change control: track what changed between releases (“we removed RSA signing from service X”).
  • Auditability: demonstrate a disciplined approach to crypto agility.

This aligns with NIST’s crypto agility framing: migration success depends on operational capability, not only algorithm selection.
Source: NIST CSWP 39‑upd1 (Final)
https://csrc.nist.gov/pubs/cswp/39/upd1/considerations-for-achieving-crypto-agility/final

A simple operating cadence (what teams actually sustain)

A cadence that works without heroics:

  • Weekly: certificate expiry + new unknown endpoints review
  • Monthly: crypto posture summary (top risks, progress metrics)
  • Per major release: CBOM snapshot attached to release artifacts

Treat the inventory like a production asset: change-controlled, queryable, and owned.

Vendor shortlist (crypto inventory / CBOM tooling)

This is intentionally small and category-based, because the tools change fast; the categories don’t.

Disclosure: Some outbound links may be affiliate or referral links. This does not change which tools are included.

External discovery (what the world sees)

CBOM / crypto inventory platforms

Certificate lifecycle management (often doubles as inventory + governance)

FAQ

Do we need a CBOM, or is a certificate inventory enough?

A certificate inventory is necessary but not sufficient. PQC planning also depends on keys, signing systems, protocol posture, and “hard to change” dependencies. A CBOM helps you represent those relationships and share them across teams.

Is CBOM a standardized thing or a vendor buzzword?

CBOM is supported within CycloneDX’s capability model, and CycloneDX v1.7 is standardized as ECMA‑424, which explicitly includes cryptographic artifact modeling. The value still depends on how you implement and maintain it.

What’s the fastest first step?

Start with what you can observe quickly: external endpoint scanning + certificate inventory + ownership tagging. Then layer internal telemetry and key custody data over time.

Further reading (primary sources)

Scroll to Top