What is a CBOM (Cryptography Bill of Materials)?
A cryptographic inventory only works if it's structured. Here's what a CBOM actually contains.
TL;DR: A Cryptography Bill of Materials (CBOM) is a structured inventory of the cryptographic assets in a system, covering algorithms, keys, certificates and the libraries that implement them. A CBOM is the cryptography counterpart to an SBOM, and the record an organisation needs before it can plan a migration to quantum-safe cryptography.
Cryptographic assets are some of the most overlooked parts of a codebase. They're essential to how software protects data, and they usually stay invisible until something forces a closer look. A Cryptography Bill of Materials (CBOM) makes them visible on purpose.
A CBOM is a structured inventory of cryptographic assets
A CBOM is a structured inventory of the cryptographic assets in a system. It applies the idea behind a Software Bill of Materials (SBOM) to cryptography specifically: where an SBOM maps software dependencies, a CBOM maps the encryption methods, algorithms, keys and certificates in use, along with the components that contain them.
Cryptographic elements are often buried several layers deep in dependencies. That makes them easy to miss and hard to reason about without a consistent format to hold the findings.
Each CBOM entry ties an asset to its purpose and status
A CBOM entry records what a cryptographic asset is, what it's used for and its current status, so weak or expiring cryptography can be traced back to a specific component. The table below shows a simplified CBOM for a single web service.
| CATEGORY | NAME | PURPOSE | STATUS | NOTES |
|---|---|---|---|---|
| Algorithm | AES-256 | Data encryption | Active | Meets FIPS 197 |
| Algorithm | RSA-2048 | Key exchange | Quantum-vulnerable | Plan migration to a post-quantum alternative |
| Library | OpenSSL 1.1.1 | Cryptographic library | End of life | Upgrade to a supported 3.x release |
| Key | TLS private key | HTTPS encryption | Active | 2048-bit RSA key, rotated annually |
| Key | API HMAC key | API authentication | Active | 256-bit symmetric key, rotated every six months |
| Certificate | Server TLS certificate | HTTPS encryption | Active | Issuer: Let's Encrypt, 90-day validity, auto-renewed |
A CBOM turns cryptographic findings into a durable record
A cryptographic finding is only useful if it's recorded somewhere durable. Without a CBOM, a weak algorithm can sit in production for years without anyone tying it to a real risk or taking ownership of the fix. With a CBOM, expired certificates, deprecated ciphers and quantum-vulnerable algorithms such as RSA and ECDH show up before they become incidents.
CycloneDX supports CBOMs inside existing SBOMs
CycloneDX, the OWASP standard for software and hardware bills of materials, has supported CBOMs natively since version 1.6. A CycloneDX CBOM can sit inside an existing SBOM or HBOM, so an organisation gets one view of its dependency graph that also shows which components carry cryptographic responsibility. Risk assessment can then start where it matters most.
The CBOM comes before the migration plan
A CBOM isn't a compliance checkbox. A CBOM is the record an organisation needs before it can plan a quantum-safe migration at all. NIST published its first post-quantum cryptography standards, FIPS 203, 204 and 205, in August 2024, so the target algorithms now exist. Building the inventory early is what turns "we should look into this eventually" into a plan you can track. For one deadline-driven example, see how to build a cryptographic inventory for CNSA 2.0.