A CBOM, or cryptography bill of materials, lists the cryptographic assets in your software: algorithms, keys, certificates and how they relate to components. An SBOM lists the components themselves. The CBOM answers a different question: which cryptography do we use, and where, if an algorithm has to be replaced?
The short definitions
An SBOM is an inventory of software components and their relationships. A CBOM extends that idea to cryptographic material. CycloneDX describes its CBOM capability as a way to discover, manage and report on cryptographic assets in preparation for a quantum-safe future. It covers algorithms, keys, certificates and their relationships to software components, and it helps surface weak spots such as outdated algorithms or lapsed certificates.
The CycloneDX standard, published by Ecma as ECMA-424, lists cryptographic artifacts among the things the format covers, next to services, dependencies, vulnerabilities and machine learning models. So a CBOM is not a separate file format. It is cryptographic content expressed in the same document model.
SBOM versus CBOM at a glance
| Question | SBOM | CBOM |
|---|---|---|
| What does it list? | Libraries, frameworks, packages | Algorithms, keys, certificates |
| Typical trigger | New advisory for a package | Algorithm deprecation, certificate expiry |
| Who reads it? | AppSec, procurement, customers | Security architecture, platform and crypto owners |
| Link between them | Components that bring crypto in | Components that use each asset |
The link matters. A crypto library appears in your SBOM. The CBOM tells you what that library is configured to do.
Why teams are asking about it
The CycloneDX page frames the use case around a quantum-safe future. If a standards body retires an algorithm, you need to find every place it is used. Package inventories alone cannot tell you, because the choice of algorithm often lives in configuration or code, not in the dependency list.
Do you need one now?
Probably not as a separate project today, unless a customer or regulator asks for it. A sensible start:
- Make sure your SBOM is current. Without a component inventory you cannot find where crypto libraries live.
- List the places your products terminate TLS, sign artifacts or encrypt data at rest.
- Record the algorithm and key length used in each place, and who owns it.
- Track certificate expiry dates.
- Revisit the format question once a buyer asks, since tooling is still maturing.
What to avoid
Do not claim a CBOM proves your cryptography is strong. It is an inventory, like an SBOM. It shows what exists, not whether the choices are sound. And do not promise customers a CBOM before you know who maintains it, because a stale cryptographic inventory is worse than none.
A worked example
Take a fictional payments service. Its SBOM lists a web framework, a TLS library, a JSON parser and a signing library. That is useful, but it does not say how the service uses cryptography. These details are invented for illustration.
A cryptographic inventory for the same service might record the following:
| Asset | Where used | Owner | Notes |
|---|---|---|---|
| Algorithm used for TLS connections | Public API gateway | Platform team | Set in configuration |
| Algorithm used to sign tokens | Auth module | Identity team | Provided by the signing library |
| Server certificate | Public endpoint | Platform team | Expiry date tracked |
| Key used to encrypt backups | Storage layer | Infrastructure | Rotation schedule recorded |
Each row ties an asset to a component in the SBOM. When a standards body retires an algorithm, you search the inventory for it, find the places it is used, and see which component and team to talk to. The SBOM alone would have told you that a signing library exists, but not which algorithm it is configured to use.
Who in the company cares
Security architects care because they plan migrations. Platform and infrastructure teams care because certificates and keys expire. Compliance teams may care because auditors ask how data is protected. AppSec cares because crypto libraries show up in advisories. A single document can serve all of them, if someone owns it.
How to start small
- Pick one product. Do not try to cover the company.
- List the places it terminates connections, signs, verifies or encrypts.
- For each place, record the algorithm, key size where relevant, and the component that implements it.
- Add certificate expiry dates and an owner.
- Link each record to the SBOM component by its identifier.
- Review the list on a schedule, since a stale list misleads.
You can keep this in a spreadsheet at first. The CycloneDX model can represent cryptographic assets, so you can move into the standard format when a buyer or tool asks for it.
What a CBOM cannot tell you
It does not tell you whether a choice is secure. It records that an algorithm is in use, not whether it is appropriate for the data. It also does not find cryptography hidden in code that never touches a library you know about. Treat it as a map that gets more accurate as you survey more of the territory.
Questions to ask a vendor who offers one
- How are cryptographic assets discovered: from configuration, from code, from binaries?
- What is the update process when a certificate is renewed?
- Can the output be exchanged in a standard format?
- How is it linked to the SBOM for the same product?
Timing
The CycloneDX page frames the CBOM around a quantum-safe future. You do not need a finished program today to start. A one page inventory for your most sensitive product is a reasonable first step, and it makes later work cheaper.
Where Safeguard fits
Safeguard focuses on SBOM and dependency scanning, reachability analysis and compliance evidence. The component inventory it produces is the base layer a crypto inventory would build on. You can test a project with the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click into a few components and note how direct and transitive packages are separated.
Quick check
Is a CBOM a different file format from CycloneDX?
No. CycloneDX represents cryptographic assets in its own model, alongside components, services and other data.
Does a CBOM replace an SBOM?
No. They answer different questions and are most useful together.
Who should own a cryptographic inventory?
Usually a security architecture or platform owner, with each asset row naming the team that operates it.
Sources
Last reviewed: 19 October 2026.
