How is a CBOM different from an SBOM?

An SBOM inventories software components; a CBOM inventories cryptographic assets: algorithms, keys, certificates, and protocol configurations, including cryptography that lives inside components, configuration files, and compiled binaries. Modern formats like CycloneDX can carry both in the same document family.

Does a CBOM contain my actual keys?

No, and it must not. A proper CBOM records metadata: that a key exists, its type and size, where it lives, and its expiry, never the key material itself. An inventory that extracted secret values would itself be a security incident.

A quantum-readiness view computed over the CBOM: every cryptographic asset classified as quantum-vulnerable or quantum-safe against the finalized NIST post-quantum standards, aggregated into a posture you can track and report. Some frameworks treat it as its own BOM dimension.

What is a CBOM? The cryptography bill of materials, explained

A CBOM, a cryptography bill of materials, is a machine-readable inventory of the cryptographic assets in a piece of software or a system. Where an SBOM tells you which components you ship, a CBOM tells you which cryptography you actually use: the question almost no organization can currently answer, and the one that post-quantum migration and modern regulation both start with.

What counts as a cryptographic asset

A complete CBOM covers four surfaces:

Algorithms in use: which primitives, modes, and key sizes are invoked, and where: in your source code, in your dependencies, and in compiled binaries you may not have source for.
Keys and certificates: X.509 certificates, keystores, SSH keys, and their parameters, expiry, and location. Metadata only, never the key material.
Protocol configurations: TLS versions and cipher suites as actually configured across servers, services, and frameworks.
Evidence and provenance: where each asset was found and how, so the inventory can be audited rather than believed.

The compiled-binary surface deserves emphasis: vendor software and statically linked libraries carry their own cryptography that never appears in any source tree, and an inventory that skips them misses some of the oldest, weakest algorithms in the estate.

Why the CBOM became urgent

Two drivers. First, post-quantum migration: moving off RSA and elliptic-curve cryptography is a multi-year program whose first step is a complete inventory, and government timelines have made that first step a present-tense obligation. Second, regulatory attention: crypto hygiene failures (expired certificates, deprecated protocols, legacy algorithms) recur in incidents often enough that frameworks in several jurisdictions now describe cryptographic inventories explicitly, alongside the SBOM.

What separates a real CBOM from a checkbox

Three properties, the same ones that separate real SBOMs from paperwork:

Generated from artifacts: source, configuration, certificates, and binaries actually analyzed, not a survey of what teams remember using.
Honest about unknowns: runtime-selected algorithms and unresolvable binaries declared as known-unknowns instead of omitted.
Continuously regenerated: cryptography changes with every dependency bump, so generation belongs in the build pipeline, not in an annual audit scramble.

From inventory to verdict

Once the CBOM exists, the quantum-readiness classification is computable: every asset marked quantum-vulnerable or quantum-safe against the finalized NIST standards, rolled up into a posture number you can track quarterly. That number is what turns the quantum conversation from anxiety into a burn-down chart.

BOMNexa generates CBOMs from real artifacts across all four surfaces, classifies every asset for quantum readiness, and declares its known-unknowns, entirely inside your network.