Post-Quantum Readiness
What Is a CBOM? Cryptographic Bill of Materials Explained
A CBOM inventories every cryptographic algorithm, certificate, and protocol you run. Learn how it extends SBOM (CycloneDX 1.6) and why it matters for PQC migration — and scan your public TLS free to start yours.
What Is a CBOM? Cryptographic Bill of Materials Explained
SBOM (Software Bill of Materials) is now a standard requirement for enterprise software. The next evolution is CBOM — Cryptographic Bill of Materials — which inventories every algorithm, certificate, key, and protocol in your environment.
If you have been through an SBOM implementation, you understand the core concept: you cannot secure what you cannot see. CBOM applies the same logic to cryptography. Before you can migrate to post-quantum cryptography, you need a structured, machine-readable inventory of every cryptographic asset.
This article explains what a CBOM is, how it extends SBOM, why CycloneDX 1.6 adopted it, and how to generate one for your organization.
SBOM vs CBOM: What's the Difference?
A Software Bill of Materials (SBOM) inventories software components — libraries, frameworks, packages, and their versions. It answers: what open-source components are in our application, and do any have known vulnerabilities?
A Cryptographic Bill of Materials (CBOM) inventories cryptographic components — algorithms, certificates, protocols, key sizes, and their relationships. It answers: where does cryptography live in our infrastructure, which algorithms protect which data, and are any of them quantum-vulnerable?
They are complementary. An SBOM tells you that OpenSSL 3.0 is in your application. A CBOM tells you that OpenSSL 3.0 is configured to use RSA-2048 with SHA-256 for TLS 1.2 on port 443, protecting customer PII with a certificate that expires in 60 days.
The CycloneDX 1.6 CBOM Specification
In 2024, CycloneDX 1.6 adopted a CBOM extension based on work contributed by IBM Research. The CBOM specification adds three new object types to the CycloneDX format:
- Crypto Asset — An individual cryptographic component: an algorithm (RSA, AES, ML-KEM), a certificate, a key, a protocol (TLS 1.3, SSH), or a library (OpenSSL, BoringSSL).
- Crypto Property — Attributes of a crypto asset: key size, mode of operation, padding scheme, curve name, hash function.
- Crypto Related Evidence — How the asset was discovered: static analysis, network scan, configuration review, manual audit.
A CBOM can capture the full cryptographic posture: a TLS certificate uses RSA-2048 with SHA-256 signatures, was issued by DigiCert, protects the api.example.com endpoint, was discovered via external scan, and is classified as quantum-vulnerable.
What a CBOM Should Include
A complete CBOM covers:
- TLS certificates: Subject, issuer, algorithm, key size, SAN entries, validity period, endpoint, TLS version negotiated
- Code-level crypto dependencies: Algorithms called in application code, libraries used, key generation patterns
- Infrastructure crypto: SSH host keys, VPN cipher suites, database encryption at rest, cloud KMS keys
- Protocol configurations: TLS versions enabled, cipher suites in negotiation, signature algorithms accepted
- Vendor-managed crypto: Certificates and algorithms managed by third-party services that affect your data
Why CBOM Matters for PQC Migration
CBOM directly supports PQC migration planning in three ways:
- Automated discovery of migration targets: A CBOM flags every RSA-2048 instance, every ECC P-256 certificate, every SHA-256 with RSA signature. Instead of manually searching code and configs, you query the CBOM.
- Blast radius analysis: When a certificate or algorithm needs to change, the CBOM shows which systems, services, and data flows depend on it. This turns migration from guesswork into systematic planning.
- Compliance evidence: A CBOM is an auditable artifact. You can show a regulator or auditor exactly which cryptographic assets exist, what state they are in, and how they are being tracked over time.
How to Generate a CBOM
There are two paths:
Path A: Tool-generated (automated). Use a cryptographic discovery platform that produces CycloneDX CBOM output. IBM Quantum Safe Explorer, AppViewX AVX PQC Tool, and Keyfactor AgileSec all produce CBOMs from their discovery engines. These tools scan code, networks, and configurations and export findings in CBOM format.
Path B: Manually constructed (for smaller environments). Build a structured inventory spreadsheet and convert it to CycloneDX JSON format. This works for organizations with a small number of known cryptographic assets but does not scale to enterprise environments where assets number in the thousands.
For most organizations, the practical path is: start with external discovery (CipherReady for TLS certificate and DNS inventory), export findings, map them to CBOM fields, then expand to internal discovery as the program matures.
CBOM and Regulatory Compliance
CBOM is being referenced in emerging regulatory guidance:
- OMB M-23-02: US federal agencies must submit annual cryptographic inventories. A CBOM in CycloneDX format is the recommended output.
- EU Cyber Resilience Act: SBOM is required for digital products by December 2027. CBOM is expected to follow as cryptographic visibility becomes a regulatory requirement.
- PCI DSS 4.0: Cryptographic inventory and certificate lifecycle management are required. CBOM provides the structured format.
- CNSA 2.0: Mandates transition to CNSA-approved algorithms with timelines tracked per asset — a natural fit for CBOM-based tracking.
FAQ
Q: Is CBOM the same as an SBOM with crypto data added? A: No. CBOM extends the SBOM data model with cryptographic-specific object types. An SBOM with crypto annotations is not the same as a CycloneDX 1.6 CBOM, though they can be merged.
Q: Do I need a CBOM if I already have a certificate inventory spreadsheet? A: A spreadsheet is a starting point. A CBOM in CycloneDX format is machine-readable, version-controllable, and interoperable with audit and migration tooling. For compliance and scale, CBOM is the target state.
Q: How often should a CBOM be updated? A: At minimum quarterly, with each infrastructure change, and on certificate rotation. Automated discovery tools can produce updated CBOMs on each scan.
Q: Does CipherReady produce a CBOM? A: CipherReady's external assessment output covers the TLS certificate, DNS, and HTTP header layers of a CBOM. It provides the public-facing cryptographic inventory that forms the foundation. For full internal code-level CBOM, it integrates into a broader discovery strategy.
Start Free Readiness Scan →
View Resources →