SBOM vs CBOM: software components versus cryptographic assets
An SBOM tells you which cryptographic library is present. A CBOM tells you which algorithms, keys, protocols and certificates are actually in use. Post-quantum planning needs the second.
- An SBOM inventories software components; a CBOM inventories cryptographic assets and how they are used.
- CERT-In defines CBOM asset types for algorithms, keys, protocols and certificates.
- CycloneDX supports both in one specification, so a CBOM can reference SBOM components.
- Post-quantum migration depends on knowing where quantum-vulnerable algorithms are used, which an SBOM alone cannot show.
What each one records
An SBOM lists the software components in a product with their versions, suppliers and relationships [1]. A CBOM (Cryptographic Bill of Materials) lists cryptographic assets. CycloneDX describes the CBOM as a way to "discover, manage, and report on cryptographic assets", representing algorithms, keys, certificates and their relationships to software components [2]. CBOM support was introduced in CycloneDX 1.6 [3], and version 1.7 added standardised algorithm-family and elliptic-curve lists [4].
A deeper introduction is in What is a CBOM?
Side-by-side
| SBOM | CBOM | |
|---|---|---|
| Inventory of | Libraries, packages, frameworks, runtimes | Algorithms, keys, protocols, certificates |
| Typical question | Are we running a vulnerable version of library X? | Where do we use RSA-2048, TLS 1.0 or an expiring certificate? |
| CERT-In baseline | 21 fields such as name, version, supplier, licence, hashes [5] | Asset-type fields: algorithm primitive, mode, classical security level, OID; key size and state; protocol version and cipher suites; certificate issuer, validity and signature algorithm [5] |
| Discovery method | Manifests, lockfiles, build metadata, image analysis | Code analysis for crypto API calls, configuration, keystores, certificates, network protocol inspection |
| Main risk driver | Known vulnerabilities, licences, EOL | Weak or quantum-vulnerable algorithms, key lengths, expiry, protocol versions |
Why an SBOM is not a CBOM
An SBOM might show that a product includes a cryptographic library at a particular version. It does not show which algorithms the product calls, what key sizes it uses, which protocol versions it negotiates, or which certificates it depends on. One library can provide both strong and weak algorithms, and the application's configuration decides which are used. CERT-In's CBOM fields are defined at this asset level for that reason [5].
CERT-In's CBOM asset types
CERT-In's Version 2.0 guidelines define minimum CBOM elements for four asset types [5]:
| Asset type | Minimum elements |
|---|---|
| Algorithms | Name, asset type, primitive, mode, crypto functions, classical security level, OID, list |
| Keys | Name, asset type, id, state, size, creation date, activation date |
| Protocols | Name, asset type, version, cipher suites, OID |
| Certificates | Name, asset type, subject name, issuer name, not valid before, not valid after, signature algorithm reference, subject public key reference, certificate format, certificate extension |
None of these can be derived from an SBOM's component list. They need cryptographic discovery in code, configuration, keystores and network traffic.
Why it matters now: post-quantum migration
NIST finalised its first post-quantum standards, FIPS 203, 204 and 205, on 13 August 2024 [6]. NIST's draft transition guidance, IR 8547, proposes deprecating quantum-vulnerable algorithms at the 112-bit security level after 2030 and disallowing them after 2035 [7]. Planning that migration requires knowing where RSA, elliptic-curve and other public-key algorithms are used, which is CBOM information. CERT-In pairs the CBOM with the QBOM for this reason; see What is a QBOM?
How they work together
- Use the SBOM to find which applications include cryptographic libraries and at which versions.
- Build CBOMs for critical applications to capture algorithms, keys, protocols and certificates.
- Link CBOM assets to SBOM components, which CycloneDX supports within one document model [2].
- Prioritise by business criticality and data lifetime, not just algorithm strength.
Start with the SBOM programme you already have; see What is an SBOM?
How IntelliXBOM helps
IntelliXBOM manages SBOMs and CBOMs in one inventory, in CycloneDX and SPDX, and correlates components and cryptographic assets with vulnerabilities, end-of-life data and business services. It validates both against required-field policies such as CERT-In's and maps the results to framework controls with timestamped evidence.
Frequently asked questions
What is the difference between an SBOM and a CBOM?
An SBOM lists software components such as libraries and packages. A CBOM lists cryptographic assets, including algorithms, keys, protocols and certificates, and how they relate to those components.
Can one file contain both an SBOM and a CBOM?
CycloneDX supports software components and cryptographic assets in the same specification, so a single BOM can describe both and link them. Many organisations still manage them as separate documents for different owners.
Do I need a CBOM for post-quantum readiness?
Yes, in practice. Migration planning depends on knowing where quantum-vulnerable algorithms and key sizes are used, which an SBOM cannot show.
Sources
- Executive Order 14028, Improving the Nation's Cybersecurity (May 2021)Federal Registerwww.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity
- Cryptography Bill of Materials (CBOM)OWASP CycloneDXcyclonedx.org/capabilities/cbom/
- CycloneDX v1.6 Released, Cryptographic Bill of Materials and AttestationsOWASP CycloneDXcyclonedx.org/news/cyclonedx-v1.6-released/
- CycloneDX v1.7 ReleasedOWASP CycloneDXcyclonedx.org/news/cyclonedx-v1.7-released/
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- NIST Releases First 3 Finalized Post-Quantum Encryption Standards (13 August 2024)NISTwww.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
- NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (November 2024)NISTnvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.