Cryptography Bill of Materials
CBOM
ALSO: CBOM · crypto bill of materials · cryptographic BOM
A Cryptography Bill of Materials (CBOM) is a machine-readable inventory of every cryptographic asset in a system or organization: the algorithms in use, where they are implemented, the keys and certificates that depend on them, the protocols that negotiate them, and the libraries that provide them. It extends the software bill of materials (SBOM) concept from components to cryptography.
The CBOM exists because you cannot assess quantum risk (or execute a migration) without knowing what cryptography you actually run. Most organizations discover their cryptographic estate is far larger and more tangled than assumed: embedded in vendor products, pinned in old configs, and hard-coded in internal services.
CycloneDX standardized CBOM as part of its version 1.6 specification, giving the industry a common format for describing cryptographic assets and their dependencies, so inventories can be generated by tools, exchanged with vendors, and tracked over time.
01.What a CBOM records
A useful CBOM goes beyond naming algorithms; it captures the relationships that make migration planning possible: which certificate chains anchor which services, which library version provides which primitive, and which protocol configurations negotiate which cipher suites.
- Algorithms and parameters: RSA-2048, ECDSA P-256, AES-128-GCM, ML-KEM-768
- Keys: type, length, purpose, rotation policy, storage (HSM, KMS, file)
- Certificates: chains, expiry, signature algorithms, issuing CAs
- Protocol configurations: TLS versions and cipher suites, SSH key-exchange settings, VPN parameters
- Crypto libraries and versions: OpenSSL, BoringSSL, Bouncy Castle, language runtimes
- Dependencies between assets: which services break if a given algorithm is retired
02.CBOM vs SBOM
An SBOM answers 'what software components ship in this system?'; a CBOM answers 'what cryptography does this system depend on, and how?'. The two intersect (a crypto library is both a software component and a cryptographic provider), but the CBOM adds crypto-specific detail an SBOM never captures: key sizes, certificate lifetimes, negotiated protocol parameters, and quantum vulnerability classification.
CycloneDX 1.6 models both in one format, which matters operationally: vulnerability tooling, procurement, and compliance pipelines that already consume SBOMs can extend to cryptographic posture instead of inventing a parallel process.
03.CBOMs in regulation and guidance
Cryptographic inventories are now a compliance object, not just an engineering aid. OMB memorandum M-23-02 requires US federal agencies to maintain inventories of systems using quantum-vulnerable cryptography, and the joint CISA/NSA/NIST quantum-readiness guidance tells critical infrastructure operators to build exactly the artifact a CBOM formalizes. Sector regulators and large enterprises increasingly ask vendors for cryptographic transparency as part of procurement.
The direction of travel mirrors SBOMs after the 2021 executive order on cybersecurity: first a recommended practice, then a procurement requirement, then an audit item.
04.From CBOM to migration plan
The CBOM is the input to risk assessment, not the output of the program. Each asset gets classified (quantum-vulnerable or safe), then ranked by the lifetime of the data it protects, its exposure, and the cost of change. That ranking, essentially applying Mosca's inequality per system, becomes the migration roadmap: which TLS endpoints move to hybrid key exchange first, which certificate hierarchies need post-quantum signature planning, which vendor products need contractual pressure.
Because estates change continuously, a CBOM is only trustworthy if it is regenerated continuously; a one-off spreadsheet is stale before the migration it was meant to guide begins.
FREQUENTLY ASKED
How is a CBOM different from an SBOM?
An SBOM lists the software components in a system; a CBOM lists its cryptographic assets (algorithms, keys, certificates, protocols) and the dependencies between them. A CBOM records crypto-specific facts an SBOM omits, like key lengths, certificate expiry, and whether an algorithm is quantum-vulnerable. CycloneDX 1.6 supports both in a single format.
Is there a standard CBOM format?
Yes. CycloneDX 1.6, published by OWASP in 2024, added first-class cryptographic asset types (algorithms, keys, certificates, and protocols) with properties for parameters, dependencies, and quantum security classification. Using the standard format keeps inventories tool-generatable and exchangeable with vendors and auditors.
How do you actually build a CBOM?
Through automated discovery across several evidence sources: scanning code and dependencies for crypto API usage, inspecting TLS/SSH/VPN configurations, enumerating certificates and keys from stores and KMS/HSM systems, and observing negotiated protocols on the network. Manual questionnaires do not scale and go stale; discovery has to be repeatable so the CBOM stays current.
Why does a CBOM matter for post-quantum migration?
Because migration scope is defined by the inventory. Without a CBOM, organizations migrate the systems they remember and miss the ones that matter: old VPN concentrators, vendor appliances, hard-coded RSA in internal tools. With one, quantum-vulnerable usage becomes a ranked worklist with owners, dependencies, and verifiable completion.
SOURCES