What a CBOM Is — and Why an SBOM Won’t Answer the Quantum Question

Every post-quantum cryptography (PQC) roadmap opens with the same instruction: build an inventory of your cryptography. That is where most programs stall. The algorithms slated for replacement, including RSA and elliptic-curve cryptography (ECC) for key exchange and signatures and legacy primitives such as SHA-1, MD5, and DES, are rarely documented in one place. The hardest ones to find sit inside third-party and closed-source software, where nobody on the security team owns the data.

Here’s what a CBOM comprises — and why it’s necessary to go beyond the SBOM in the PQC era.

[ Learn more: Accelerate PQC Migration: How to Leverage CBOMs ]

What a CBOM Is

A cryptography bill of materials (CBOM) is a machine-readable inventory of the cryptographic assets in a piece of software and their relationships to the components that provideuse them. The concept came out of IBM Research and was standardized in OWASP CycloneDX 1.6, released in April 2024 and ratified two months later as Ecma International’s ECMA-424 standard. CycloneDX 1.7, released in October 2025, added standardized lists of algorithm families and elliptic curves to make PQC readiness assessments more consistent.

CycloneDX defines the asset types a CBOM records: algorithms, certificates, protocols, and related cryptographic material such as private, public, and secret keys. Each entry can carry the details a migration team needs, including algorithm parameters, key sizes, and protocol versions. Just as important, a CBOM maps dependencies, recording which component provides an algorithm and which parts of the software depend rely on it. That mapping turns a list of algorithm names into an inventory that shows where outdated algorithms like RSA lives and what would break if it changed, noted Michael Osborne, CTO of IBM Quantum Safe.

“CBOM is the first open standard to describe an organization’s cryptographic assets inventory, and their dependencies, giving organizations deeper visibility.”
—Michael Osborne

Why an SBOM Won’t Answer the Quantum Question

A software bill of materials (SBOM) lists the components and dependencies that make up an application. It is the right tool for tracking a vulnerable library version, a license obligation, or a component’s origin. But as ReversingLabs’ guidance on going beyond the SBOM puts it, an SBOM on its own “is merely a list of ingredients.” 

Software is more than the components executing on your machine — there are cloud services, API calls, AI models, and cryptographic assets that protect login credentials, data, and all manner of communications that enable software components to work together to deliver value.  A quick look at SBOM standards from CycloneDX, SPDX, or CISANIST’s minimum elements shows none of that information, necessitating an extended family of BOMs that includes inventories of machine learning models (ML-BOMs), software services (SaaSBOMs) and cryptographic elements (CBOM).

Quantum exposure depends on how those ingredients are used. An SBOM entry showing that an application ships a particular OpenSSL version confirms that a cryptographic library is present. It says nothing about which of the library’s many algorithms the application calls, what key sizes it uses, whether a certificate with an RSA key is bundled in the package, or whether a developer bypassed the library and rolled their own cryptography. Two applications with identical SBOM entries can carry very different quantum risksrisk.

That is why a CBOM works best as a companion to an SBOM rather than a replacement for it. CycloneDX lets cryptographic assets sit inside an SBOM as another component type or live in a separate, linked document with its own access controls. Either way, each cryptographic asset traces back to the software component that provides it. Where the cryptography hides

Much of the cryptography that matters for PQC was never written by the organization running it. It is compiled into commercial applications, statically linked libraries, firmware, container images, and vendor SDKs, where there is no source code to scan and no manifest describing what’s inside. Each common tool sees a slice of the picture: source code analysis sees what developers wrote, dependency scanners see what package managers declared, and certificate management tools see the certificates they issued. None of them sees all of the cryptography in the software that shipped.

Federal guidance acknowledges the gap. The 2023 quantum-readiness factsheet from CISA, the NSA, and NIST recommends automated discovery across network protocols, applications, and development pipelines, while cautioning that discovery tools may not find cryptography embedded inside products. For that, it tells organizations to ask their technology vendors. Vendor attestations help, but they rest on trust rather than evidence, and questionnaires rarely come back with the detail a migration plan requires.

A more reliable baseline comes from analyzing the final software artifact, meaning the compiled binaries and packages that run in production. Reading source code is not the same as knowing what shipped, so a PQC program that starts from source repositories, manifests, or questionnaires starts from a partial picture.

Why the Inventory Comes First

The algorithms organizations will migrate to already exist. In August 2024, NIST finalized its first three post-quantum standards: FIPS 203 (ML-KEM) for key encapsulation, and FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for digital signatures. With the destination defined, the bottleneck has moved to discovery, noted Dustin Moody, mathematician and head of the PQC standardization project at NIST.

“These finalized standards include instructions for incorporating them into products and encryption systems. We encourage system administrators to start integrating them into their systems immediately, because full integration will take time.”
—Dustin Moody

Timelines are taking shape as well. NIST’s draft transition guidance, NIST IR 8547, proposes deprecating widely used RSA and ECC key sizes after 2030 and disallowing quantum-vulnerable algorithms after 2035. The UK’s National Cyber Security Centre (NCSC) asks organizations to complete discovery and an initial migration plan by 2028, finish high-priority migrations by 2031, and complete the transition by 2035. Discovery also has a present-day rationale, because adversaries can collect encrypted data now and store it until a capable quantum computer can decrypt it, a tactic known as “harvest now, decrypt later,” wrote Jen Easterly, former director of CISA.

“It is imperative for all organizations, especially critical infrastructure, to begin preparing now for migration to post-quantum cryptography.”
—Jen Easterly

Many organizations are already moving. A 2025 Utimaco survey of more than 200 organizations in the U.S., the UK, and Germany found that 20% had begun migrating to PQC and another 34% planned to start within one to three years, while 25% reported no migration plans at all. Whichever group an organization falls into, the first milestone is the same: inventory.

What Makes a CBOM Useful

A CBOM is only as valuable as the decisions it informs. On its own, it is a list, and the list pays off only when it feeds a migration plan with business context behind it, wrote former senior director of product management at ReversingLabs, Charlie Jones.

“Value can only be derived from this list when the business has established PQC migration plans for cryptographic inventories that are aligned to broader organizational resilience objectives.”
—Charlie Jones

The first CBOM also has a narrower job than many teams assume. Organizations don’t need to have adopted post-quantum algorithms, or even chosen a replacement library, before generating one. Most software in production doesn’t contain ML-KEM or ML-DSA yet, so what matters at this stage is surfacing the quantum-vulnerable cryptography that is there, such as RSA and ECC, along with deprecated primitives such as SHA-1, MD5, and DES. That list of what has to change is the baseline every later migration decision builds on.

Context matters because a weak algorithm in a CBOM is a finding to assess, not an automatic incident. The sensitivity of the data, the function the algorithm serves, and compensating controls such as an outer TLS layer all shape real exposure. A CBOM that can support that assessment has four properties:

• Complete coverage. It covers software the organization builds and software it buys, including third-party and closed-source products.
• Location mapping. It ties each algorithm, certificate, key, and protocol to the component where it lives.
• A standard format. It exports as CycloneDX JSON, so the inventory imports into asset management and governance, risk, and compliance (GRC) tools and can be shared with auditors, customers, and upstream vendors as evidence toward compliance.
• Repeatability. It is regenerated with each release, so teams can confirm that updated software no longer contains deprecated cryptography before it is deployed.

How to Get Started

ReversingLabs’ PQC migration framework breaks the early work into three steps:

1. Build the inventory. Generate CBOMs for every piece of software the organization builds or buys.
2. Sequence by risk. Prioritize by business impact, then choose a path for each asset: migrate in place to NIST-approved algorithms, re-platform, retire the service, run it to end of life, or accept the risk.
3. Adopt quantum-safe libraries. Open-source projects such as the Open Quantum Safe project’s liboqs give developers tested implementations to build on.

The second and third steps depend on the first, but the first doesn’t wait on them. Teams can generate a baseline CBOM before they have selected a single post-quantum algorithm, because its purpose is to find what is vulnerable today. Risk-based sequencing turns into guesswork without knowing where vulnerable cryptography sits, and new libraries can’t replace algorithms nobody has located. You can’t replace cryptography you can’t find, and for most organizations, the cryptography they most need to find is inside the software they already run.