TL;DR
An SBOM lists what software is made of: components, versions, licenses, known vulnerabilities. A CBOM lists what protects it: algorithms, keys, certificates, protocols.
Executive Order 14028 made SBOMs mandatory for federal software in 2021. PCI DSS 4.0 requirement 12.3.3 made a cryptographic inventory mandatory for payment environments as of March 31, 2025. Different laws, different documents, same underlying instinct: know what you are running.
CBOM is not a separate standard invented to compete with SBOM. It is an extension of CycloneDX, the same format many SBOMs already use, added in version 1.6.
NIST finalized its first post-quantum cryptography standards in August 2024, and NIST IR 8547 sets 2030 as the year RSA and similar algorithms get deprecated, with full disallowance by 2035. A CBOM is the tool that tells you where RSA is still running.
Most mature software supply chain security programs end up generating both documents, not choosing one.
Many organizations could describe their organization's approach to open source risk in one sentence: "We know what's in the building. We just don't know what's guarding the doors."
They have a SBOM. Their teams could produce, on request, a full list of every software component, every version, every license, in any application the company shipped. What these CISOs could not produce, when a regulator or an auditor or her own board asked, was a list of which of those components were still using RSA-1024, which certificates were six weeks from expiry, or which service was quietly negotiating TLS 1.0 because nobody had gotten around to fixing it.
That gap is not a failure of an organization’s SBOM, but a gap the SBOM was never built to close. Software composition analysis tells you what your software is made of, not what protects it. That is a different question, and it needs a different document: a cryptographic bill of materials, or CBOM.
CBOM vs SBOM: What Each One Actually Answers
The cleanest way to separate them is by the question each one answers.
SBOM answers the question "what software components are in this application, and are any of them known to be vulnerable?" A software bill of materials lists packages, libraries, frameworks, and their versions, structured so a vulnerability management tool can cross-reference it against databases of known vulnerabilities. It gives breadth: the full software supply chain, every transitive dependency, the entire application architecture in one document.
A CBOM answers a narrower and, for a specific set of risks, more urgent question: "what cryptography does this application use, and is any of it weak?" A cryptographic bill of materials catalogs encryption algorithms, key lengths, cipher suites, protocol versions, digital certificates, and cryptographic libraries, along with where each one is used and by what.
Neither document replaces the other because they were built to answer different questions. An SBOM tells you a library is a known-vulnerable version, while a CBOM tells you that library is still using RSA-2048 for key exchange three years after the deprecation clock started. Those are both real risks, and only one of them shows up in a component list.
Cryptographic Assets and the Cryptographic Bill of Materials CBOM Format
A CBOM is a structured inventory. It includes encryption algorithms like AES and RSA, tagged with key lengths and modes of operation. CBOMs include protocols such as TLS, SSH, and IPsec, with the specific version negotiated. CBOMs track digital certificates with issuer, subject, and expiry dates, which is often the single most operationally useful line item in the entire document, since certificate expiry causes more production outages than almost any other cryptographic failure. A CBOM catalogs cryptographic libraries like OpenSSL, BouncyCastle, and libsodium, and distinguishes between a library that implements an algorithm and an application that merely uses it, since TLS 1.3 might use ECDH internally in a way no application developer ever configured directly.
This is CBOM data in practice: algorithms, protocols, certificates, and key material metadata, linked to the component that invokes each one and the runtime environment it runs in. That relationship data turns a list into an inventory. Knowing that a specific payment microservice uses RSA-2048 for key exchange, in a container image that ships weekly, tells you exactly where to start.
One Standard, Two Documents: The Cryptography Bill Format Underneath Both
A CBOM is not a rival format competing with SBOM; it is an extension of the same one.
CycloneDX, maintained under OWASP, has been the leading machine-readable format for SBOM data for years, alongside SPDX. In 2024, CycloneDX 1.6 added native support for cryptographic assets, developed originally by IBM Research and folded into the core specification rather than shipped as a separate schema. That means a CBOM extends CycloneDX rather than replacing it: the same tooling, the same parsers, the same registries that already handle a software bill of materials can read cryptographic components once a generator populates them.
This is why most development teams use SBOMs and CBOMs together rather than treating them as a choice. Generation is often the same pipeline: run a CycloneDX generator in CI/CD, and depending on configuration it surfaces software dependencies, or dependencies plus cryptographic components, from the same scan. Rebuild both on every release, because a dependency that was safe last week can ship a new vulnerable version this week, and a cipher suite that was compliant last quarter can fall out of compliance the moment a regulator updates guidance.
Why Crypto Teams Are Treating This as Its Own Cybersecurity Bill
Crypto teams have needed this for a decade and mostly didn't have it, because nothing forced the question until three things converged.
First, NIST finalized post-quantum cryptography standards in August 2024: FIPS 203, 204, and 205, covering key encapsulation and digital signatures built on math believed to resist quantum attack. Second, NIST IR 8547 marks RSA deprecation after 2030, with disallowance after 2035, which converts "quantum computers might be a problem someday" into a scheduling problem with a date on it. Third, procurement and regulatory pressure caught up: Gartner has projected that 60 percent of organizations building or procuring critical infrastructure software will mandate and standardize SBOMs by 2025, up from less than 20 percent in 2022, following the pattern set by Executive Order 14028, which made SBOMs mandatory for federal software procurement back in 2021.
None of that mandate language mentions cryptography specifically. But the effect is the same: you cannot plan a post- quantum cryptography migration against an estate you cannot see. CBOMs are essential for planning post-quantum cryptography migrations for exactly the reason the CISO in the opening ran into: her SBOM told her what software existed. It could not tell her which of that software was quietly relying on an algorithm with a 2030 expiration date.
This is where crypto owners, often a distinct function from the application security team that owns the SBOM, get an inventory built for their actual job. CBOMs provide a risk-centric inventory of cryptographic assets rather than a general-purpose component list repurposed for a task it wasn't designed for.
Post-Quantum Cryptography Migration and Crypto Agility
CBOMs help identify quantum-vulnerable algorithms before 2030 deadlines, which is the single highest-value use case right now. Asymmetric algorithms including RSA and ECC-based key exchange are the ones Shor's algorithm threatens; a CBOM tells you precisely where they live, down to the container image and the code path. Without that inventory, a post quantum migration defaults to guessing, which in practice means re-encrypting everything, at enormous cost, on a timeline that misses the actual risk.
CBOMs enable organizations to plan migrations to quantum-safe cryptography by sequencing the work correctly. Not every quantum-vulnerable algorithm carries equal risk. A CBOM paired with data-sensitivity context lets a crypto team prioritize remediation on the paths protecting the most sensitive, longest-lived data, rather than working through services alphabetically. That prioritization is precisely what harvest now, decrypt later demands: an adversary recording encrypted traffic today for decryption once a cryptographically relevant quantum computer exists cares about data longevity, not about which team happens to own the affected service.
CBOMs reveal cryptographic weaknesses in software components beyond the quantum threat entirely: deprecated algorithms still in production, key lengths below current guidance, expired or soon-to-expire certificates, and cipher suites that were reasonable five years ago and are not now. This is ordinary cryptographic hygiene that a component-focused SBOM was never positioned to catch, because a library can be fully patched against every known CVE and still be configured to negotiate a cipher suite nobody would choose today.
Container Images, PCI DSS, and Where the Two Documents Get Audited
Regulation is where the theoretical distinction turns into an audit finding, and container images are where CBOM generation actually happens in most modern pipelines. Open source tooling like IBM's CBOMkit-theia scans container images and directories directly, rather than requiring source access, which matters because a container image is often the only artifact a security team can reliably get their hands on for a third-party or vendor-supplied component.
CBOMs support compliance with cryptographic standards like PCI DSS 4.0. Requirement 12.3.3 requires organizations to maintain a current inventory of cryptographic cipher suites and protocols in use, including purpose and location, reviewed at least every 12 months, and became fully mandatory on March 31, 2025. That is, functionally, a legal requirement to maintain something very close to a CBOM. An SBOM alone does not satisfy it, because 12.3.3 asks about cryptography specifically, not about software components generally.
The same pattern shows up wherever cryptographic risk is regulated directly: critical infrastructure operators facing sector-specific post-quantum guidance, medical devices where cryptographic failure has safety implications, and sectors where a regulator has started asking about post-quantum readiness on a supervisory timeline rather than waiting for a breach.
SBOMs facilitate regulatory compliance and software vendor vetting in the broader sense: license compliance, provenance, and a defensible answer to "what did you ship us." Executive Order 14028 made that answer mandatory for federal software in May 2021, and NTIA's minimum elements report is still the baseline definition of what a compliant SBOM has to contain. The two documents satisfy adjacent but distinct compliance obligations, and increasingly, a single regulatory framework asks for evidence that only one of them can actually provide.
Pairing SBOMs and CBOMs With VEX
One more piece completes the picture, and it is worth naming even briefly: Vulnerability Exploitability eXchange, or VEX.
An SBOM and a CBOM both tell you what exists, but neither tells you whether a listed vulnerability or weak algorithm is actually exploitable in your specific deployment, given your configuration and compensating controls. Pairing SBOMs and CBOMs with VEX closes that gap: VEX carries the assessment of whether a known issue applies to this instance, which is what lets a security team prioritize remediation instead of triaging every theoretical weakness a scanner surfaced.
Generate all three from the same pipeline where possible. A CI/CD job that produces an SBOM, a CBOM, and VEX statements on every build, using SPDX or CycloneDX formats consistently, gives a crypto team and an application security team the same underlying data, structured for the two different questions each of them actually has to answer.
Final Thoughts
An SBOM and a CBOM are not competing standards. They are the same idea, structured inventory over machine-readable formats, aimed at two different blind spots. One tells you what your software is built from, white the other tells you what is protecting it, and increasingly, what is not.
The gap the CISO in the opening described is closing, mostly because regulation is forcing it closed faster than voluntary adoption would have. PCI DSS 4.0 made it mandatory for payment environments. The 2030 and 2035 deprecation dates in NIST IR 8547 are making it mandatory in practice for anyone planning a post-quantum cryptography migration, whether or not a regulator asks first.
Knowing where your cryptography lives is the starting point. A CBOM tells you which paths in your environment carry quantum-vulnerable algorithms, but it does not tell you which of those paths an attacker could actually reach, or how far they could travel once inside. That is a network question, and it is the one a cryptographic inventory alone cannot answer.
See which of your workload communication paths are reachable today with a free Workload Attack Path Assessment, and read how a coverage-first approach to post-quantum readiness works in What Post Quantum Protection Requires on a Real Network.
