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: 1. 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. 2. 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 syste