CBOM Explained: The Cryptography Bill Of Materials And How It Relates To SBOM

A cryptographic inventory is only as useful as the format it is kept in. Findings stored in spreadsheets with free-text columns are hard to merge, compare or check automatically. A cryptography bill of materials, or CBOM, solves this by describing cryptographic assets and their relationships in a standard, machine-readable structure.

This article explains where CBOM comes from, what it records, how it fits alongside the software bill of materials (SBOM) many organisations already produce, and why US federal policy now refers to it by name.

Where CBOM Comes From

CBOM is part of CycloneDX, an open bill of materials standard run by the OWASP Foundation. CBOM support arrived in CycloneDX version 1.6, and the first edition of the CBOM guide was published on 9 April 2024.¹ Version 1.7, released on 21 October 2025, added standard lists of cryptographic algorithm families and elliptic curves so that different tools describe the same thing in the same way.²

CycloneDX is also an international standard. Ecma International publishes it as ECMA-424, and the second edition, adopted in December 2025, specifies CycloneDX 1.7.³

What A CBOM Records

CycloneDX treats a cryptographic asset as a component, just as an SBOM treats a library or package as a component. The CBOM guide lists the asset types it can describe: algorithms, certificates, protocols, and related material such as private keys, public keys, secret keys, tokens and passwords.¹

The detail matters. The guide explains that knowing only the family (AES) is not enough, because the security level and the type of primitive depend on the specific variant (AES-128-GCM).¹ Each algorithm entry can also carry an object identifier and a field called nistQuantumSecurityLevel, which is set to 0 for quantum-vulnerable algorithms such as RSA and ECDH.¹ Where that field is filled in, a tool can pick out quantum-vulnerable algorithms quickly, then follow the recorded relationships to the keys, certificates, protocols and applications that depend on them. Anything discovery missed, or left without the field, will not show up.

Uses And Provides: Linking CBOM To SBOM

The most useful feature of CBOM is that it records dependencies. The guide separates two relationships: a library provides an algorithm by implementing it, while an application uses the algorithm, often indirectly through a protocol.¹ Its own example is TLS 1.3 using ECDH on the secp256r1 curve.

This graph answers questions a flat list cannot. If a library version has a flaw, you can see every application that depends on the algorithms it provides. If an algorithm must be retired, you can see every protocol and certificate that uses it, and from there every application.

CBOM data can sit inside an existing SBOM or live in a separate CBOM file linked to it through a reference mechanism called BOM-Link.¹ Keeping it separate can help where cryptographic details need tighter access control than the general software list.

What Organisations Use It For

The CBOM guide describes several uses beyond post-quantum readiness: general cryptographic asset management, finding weak algorithms, automated checks against policies, tracking expiring and long-lived keys and certificates, and recording certifications such as FIPS 140-3 and Common Criteria.¹ One example it gives is checking systems automatically against the NSA’s CNSA 2.0 algorithm suite, which the NSA announced in September 2022 as the future requirement for US national security systems.¹⁴ The CNSA 2.0 article covers that suite and its dates.

In the US, policy now points at CBOM directly. OMB’s memorandum M-26-15 wants the results of automated discovery collected in one central CBOM per agency, so that leaders can see the current state of their cryptography at any time.⁵ Executive Order 14412 goes a step further: it gives CISA, working with NIST, 270 days from 22 June 2026 to publish guidance on the minimum elements a cryptographic bill of materials should contain.⁶

Getting Started

Few organisations write CBOMs by hand. They are usually generated by discovery and build tools and then merged. A few early decisions make that easier.

First, decide where the data will live. Teams that already produce SBOMs in their build pipelines can add cryptographic components to them; teams with stricter access needs can keep a separate CBOM and link the two with BOM-Link.¹

Second, agree on names. The algorithm family and elliptic curve lists added in CycloneDX 1.7 are openly available and can be used even by teams that keep their inventory in another format, so different tools describe the same algorithm in the same way.² NIST’s NCCoE reached a similar conclusion in its discovery project, choosing a common interchange format so that output from different tools could feed one risk analysis.⁷

Third, capture lifecycle fields such as expiry dates from the start. The CBOM guide treats expiring and long-lived material as one of the format’s main uses, and that information drives prioritisation later.¹