up:: Cryptographic Bill of Materials (CBOM)
CBOM vs SBOM
What is the difference between a CBOM and an SBOM?
An SBOM lists the software components. A CBOM lists the cryptography inside them. Linking the two is what turns “we ship these libraries” into “these libraries use these algorithms,” which is the mapping a post-quantum migration actually needs.
Having an SBOM does not give you a CBOM. It tells you that a system includes OpenSSL. It does not tell you that OpenSSL is terminating TLS with an RSA-2048 certificate key held in a particular HSM, protecting a particular data class.
The short version:
- SBOM answers “what is in this software?” and it is a supply-chain artifact.
- CBOM answers “where does our cryptography live and what is it?” and it is a migration artifact.
- A CBOM is a specialized extension of the SBOM concept, and CycloneDX has carried a native CBOM schema since version 1.6.
- Different mandates drive each. The EU Cyber Resilience Act requires an SBOM from manufacturers; OMB M-23-02 requires federal agencies to inventory their cryptography.
- They are complements. The linkage is the deliverable, and neither one alone supports a migration.
What is an SBOM?
A software bill of materials is a machine-readable inventory of the components inside a piece of software, including libraries, dependencies and their versions.
It exists to make the software supply chain legible. When a vulnerability lands in a widely used library, an SBOM is what lets an organization answer whether it ships or runs the affected component, and where.
It is a regulated artifact in some jurisdictions. The EU Cyber Resilience Act requires manufacturers, under its vulnerability-handling requirements, to identify and document vulnerabilities and components including producing an SBOM in a commonly used machine-readable format.
What is a CBOM?
A cryptographic bill of materials is a structured inventory of every cryptographic algorithm, key, certificate, protocol configuration and cryptographic dependency across an environment.
It is granular in a way an SBOM is not. Not “we use RSA,” but “RSA-2048, protecting the TLS certificate key on application X, managed in this HSM, guarding this data class.”
Every entry carries an evidence grade, verified when proven from a technical artifact and documented when asserted but unverified. A CBOM built on documentation alone is unreliable, which is the failure mode that makes first-pass inventories misleading.
US federal policy mandates it. OMB M-23-02 requires agencies to inventory their cryptography. Full treatment at Cryptographic Bill of Materials (CBOM).
CBOM vs SBOM at a glance
| Dimension | SBOM | CBOM |
|---|---|---|
| Lists | Software components, libraries and versions | Algorithms, keys, certificates, protocol configurations and cryptographic dependencies |
| Question it answers | What is in this software? | Where does our cryptography live, and what is it? |
| Primary purpose | Supply-chain visibility and vulnerability response | Migration scoping and cryptographic risk assessment |
| Granularity | Component and version | Algorithm, parameter, key, location and data class |
| Typical entry | openssl 3.0.13 | RSA-2048, TLS certificate key on application X, in this HSM, guarding this data class |
| Evidence grading | Not an inherent part of the format | Central. Verified against documented, and the distinction decides reliability |
| Machine-readable format | CycloneDX, SPDX and others | CycloneDX carries a native CBOM schema from version 1.6 |
| Who mandates it | Manufacturers under the EU CRA, Annex I Part II | US federal agencies under OMB M-23-02 |
| How it is built | Build-time dependency resolution and package manifests | Active scanning, static analysis and configuration review, because cryptography is configured rather than declared |
| Does it support a post-quantum migration alone? | No | It is the foundational deliverable, and still incomplete without the SBOM linkage |
Sources: Cryptographic Bill of Materials (CBOM) and Cryptographic Supply-Chain Risk in this Guide, each citing its primary source; EU Cyber Resilience Act (CRA) Annex I Part II; OMB M-23-02.
How do they actually differ?
The deepest difference is that software is declared and cryptography is configured.
An SBOM can largely be generated from what a build already knows. Package manifests and dependency resolution produce it, because the components are stated somewhere by construction.
Cryptography is not stated anywhere by construction. The same library produces entirely different cryptographic posture depending on configuration, negotiated parameters, certificate contents and runtime conditions. That is why building a CBOM takes active scanning, static analysis and configuration review rather than reading a manifest, and it is why the two artifacts require different tooling and different skills.
The second difference is what completeness means. An SBOM is complete when every component is listed. A CBOM is complete when every place cryptography is used is listed, and the typical first-pass CBOM misses much of the estate, especially the cryptography inside vendor products where neither scanning nor source access reaches.
Where do they agree?
Both are bills of materials, and both exist because a supply chain became too deep to reason about informally.
Both are machine-readable by design, so both are consumable by vulnerability-management and governance platforms rather than living in spreadsheets.
Both are regulated artifacts in at least one major jurisdiction.
And both fail in the same direction, which is silent incompleteness. Neither format reports what it missed.
When do you need an SBOM?
Where the question is supply-chain exposure: whether an organization ships or runs a component, in what version, and where. It is also the compliance artifact for manufacturers placing products on the EU market.
When do you need a CBOM?
Wherever a post-quantum migration is being scoped, because the replacement’s scope is unknown without it. Organizations that migrate without one consistently discover new vulnerable systems throughout the project, systems never in scope, unknown to the security team, or assumed to be someone else’s responsibility.
It is also the input every risk model requires. Mosca’s theorem cannot be applied without knowing what systems exist and who controls them.
Why do people confuse them?
Because the CBOM was deliberately modeled on the SBOM, down to the name and the format.
That was the right design decision. Formalizing cryptographic inventory as a bill of materials rather than a loose spreadsheet captures the thing that matters: cryptography is a supply chain. An algorithm sits inside a library, inside an application, inside a system.
The confusion it produces is expensive, because an organization that already has an SBOM program reasonably assumes the cryptographic question is answered. It is not. The SBOM says which libraries are present. Only the CBOM says what those libraries are configured to do.
Is one replacing the other?
No. The direction of travel is toward linkage rather than replacement. CycloneDX carrying a native CBOM schema from version 1.6 is that convergence in practice: one format, two layers of question, with the cryptographic layer attached to the components it lives inside.
Common misconceptions
“We have an SBOM, so we have our cryptographic inventory.” The SBOM lists components. The cryptography inside them is configured rather than declared, and is invisible to a manifest.
“A CBOM is just an SBOM filtered to crypto libraries.” Filtering an SBOM to cryptographic libraries produces a list of libraries, not a list of algorithms, parameters, keys and locations.
“Either one can be generated automatically.” SBOMs largely can. A CBOM requires scanning, static analysis and configuration review, and even then the vendor-product portion is the hardest part.
“Once built, they are done.” Both drift as soon as anything changes. A CBOM in particular reflects configuration, which changes without a release.
“The formats are unrelated.” CycloneDX has carried a native CBOM schema since version 1.6.
Questions people ask
Do we need both? They answer different questions and the linkage is what makes either useful for a migration. See Cryptographic Supply-Chain Risk.
Which comes first? Migrations stall first on visibility, so the cryptographic inventory is the artifact that unblocks scoping. An existing SBOM program makes it faster rather than unnecessary.
Is a CBOM legally required? US federal agencies are required to inventory their cryptography under OMB M-23-02. Requirements outside that vary by jurisdiction and sector.
Is an SBOM legally required? Manufacturers placing products on the EU market face SBOM requirements under the Cyber Resilience Act’s vulnerability-handling provisions.
Can one tool produce both? CycloneDX can represent both, and producing them still involves different techniques, since one reads a build and the other inspects running systems and configuration.
Why is the vendor part so hard? Cryptography inside a vendor product is often invisible to both scanning and source analysis, which is why the vendor question becomes a written one. See The Vendor-Claims Checklist.
What does a good CBOM entry look like? Algorithm and parameter, the system and component it sits in, where the key lives, what data it protects, and an evidence grade saying whether that was verified or asserted.
Last verified 2026-08-10 · Maintained by Addie LaMarr, LaMarr Labs. Work with Addie at lamarrlabs.com.