Cryptographic Bill of Materials (CBOM): What It Is and the Tools to Build One
What a CBOM is, what it inventories, why it matters before the 2030 quantum deadlines, and the tools that generate one.
- A CBOM is a machine-readable inventory of all the cryptography in your software — algorithms, keys, certificates, protocols, and the libraries behind them.
- It is built on CycloneDX (ECMA-424), the same standard as the SBOM, so it fits the tooling you already use.
- NIST deprecates RSA and elliptic-curve cryptography after 2030 and disallows them after 2035 — every migration starts with this inventory.
- Tools range from the open-source IBM CBOMkit to full platforms that tie the CBOM to break-year estimates and compliance evidence.
If you ran a scan across your codebase today and someone asked "which parts of this use RSA?", could you answer in minutes? For almost every organization, the honest answer is no. A Cryptographic Bill of Materials is what changes that.
A CBOM is a machine-readable inventory of every cryptographic asset in a piece of software — the algorithms it uses, the keys and certificates it relies on, the protocols it speaks, and the libraries that implement them. If a software bill of materials tells you which components you ship, a CBOM tells you which cryptography those components depend on.
What is a CBOM, exactly?
A CBOM is a structured document. It lists the cryptography used by an application, its dependencies, its containers, and its infrastructure. A tool produces it by scanning your source code, binaries, and configuration. Every cryptographic usage it finds becomes a separate entry you can search and act on.
The format is not something you have to invent. CBOM is part of CycloneDX — the OWASP-backed Bill of Materials standard — which added native cryptographic support in version 1.6 and is now published as ECMA-424. Because a CBOM is just a CycloneDX document with cryptography fields, it slots straight into the tooling, pipelines, and registries that already handle your SBOMs.
A CBOM is to your cryptography what an SBOM is to your dependencies: a complete, machine-readable inventory you can query, diff, and act on. Same standard, different question.
What goes inside a CBOM?
Think of it in four buckets. Each entry carries enough detail for a scanner to judge risk on its own:
- Algorithms — the math in use: encryption (AES, RSA), hashing (SHA-256, SHA-1), and signatures (ECDSA, ML-DSA), down to key size, mode, and curve.
- Keys and certificates — symmetric keys, public/private pairs, and X.509 certificates, with their length, format, and where they live.
- Protocols — the higher-level stuff like TLS, SSH, or IKE, and the cipher suites they negotiate.
- Libraries and providers — the implementation behind it all (OpenSSL, BoringSSL, a JCA provider, an HSM). A weakness often lives in the implementation, not just the algorithm.
Here is the part that makes a CBOM more than a spreadsheet: a modern one records a NIST quantum-security level for each asset. That single field turns a flat list into a priority queue — a scanner can grade how quantum-vulnerable an application is and tell you what to fix first.
Why this matters now: the 2030 and 2035 deadlines
The pressure is not hypothetical, and the dates are already on the calendar. In NIST IR 8547 — the roadmap for moving to post-quantum cryptography — NIST set retirement dates for the public-key algorithms that protect almost all software today.
| Algorithm family | After 2030 | After 2035 |
|---|---|---|
| RSA (all key sizes) | Deprecated | Disallowed |
| ECDH / ECDSA | Deprecated | Disallowed |
| Finite-field DH, DSA | Deprecated | Disallowed |
"Deprecated" means: don't use it for new systems after 2030. "Disallowed" means: don't use it at all after 2035 — not even in legacy systems, where you lose the option to accept the risk. The NSA's CNSA 2.0 runs a parallel schedule for national security systems, requiring ML-KEM-1024 and ML-DSA-87 (from FIPS 203 and FIPS 204), with new systems expected to move from 2025.
RSA-2048 and ECC P-256 — about 112 bits of classical security — are first in line. They sit under most of the TLS, code signing, and VPNs running in production right now.
There is also a quieter problem: "harvest now, decrypt later." An attacker can capture your encrypted traffic today and decrypt it the day a capable quantum computer arrives. For anything with a long shelf life — health records, state secrets, signing keys — the clock effectively started years ago.
CBOM vs SBOM: how they fit together
These two are partners, not rivals. An SBOM answers "what components are in this software?" A CBOM answers "what cryptography does this software use?" A single component in your SBOM — say, a TLS library — can contribute dozens of entries to your CBOM. Since both use CycloneDX, most teams generate and store them side by side.
| SBOM | CBOM | |
|---|---|---|
| Question it answers | Which components do I ship? | Which cryptography do I use? |
| Main driver | Vulnerability + license management | Post-quantum migration, crypto-agility |
| Standard | CycloneDX / SPDX | CycloneDX 1.6+ (ECMA-424) |
| Key fields | Components, versions, hashes, licenses | Algorithms, keys, certs, protocols, quantum level |
CBOM tools: how to actually generate one
A handful of tools can produce a CycloneDX CBOM today. They mostly differ on three things: what they scan (source, binaries, containers, cloud), whether they only inventory or also act on the results, and how much platform sits around the CBOM itself.
| Tool | Scans | Output | Best for |
|---|---|---|---|
| IBM CBOMkit (open source) | Source code, git repos, container images | CycloneDX CBOM + viewer | Trying a free, standards-pure generator |
| Checkmarx / Keyfactor / Sectigo | Code or certificate estate, by vendor | CBOM + PKI / certificate tooling | Anchoring PQC work in certificate lifecycle |
| O3 Security | Code, dependencies, containers, and cloud | CBOM with break-year estimates, migration paths, and compliance evidence | Tying the CBOM to the rest of your supply chain |
If you just want to see what a CBOM looks like, the open-source IBM CBOMkit is the fastest way to generate one. If the goal is an enterprise migration — not just "where does RSA live" but "when does each asset break, and how do I replace it with evidence a regulator will accept" — that is where a platform approach pays off. O3 discovers cryptography across code, dependencies, containers, and cloud, forecasts when each asset becomes quantum-vulnerable, and produces the evidence required for the EU Cyber Resilience Act, EO 14028, and NSA CNSA 2.0.
“You cannot migrate cryptography you cannot see. The CBOM is how you see it.”
How to start: a four-step plan
You don't need a year-long program to begin. You need the first step done well.
- Inventory. Generate a CBOM across code, dependencies, containers, and cloud. Every NIST and NSA roadmap starts here — you can't prioritize what you haven't enumerated.
- Prioritize. Rank assets by quantum exposure and data lifetime. Long-lived secrets and anything externally exposed go first.
- Build crypto-agility. Where you can, hide cryptography behind interfaces so algorithms swap without rewriting the app. That's the difference between a one-line change and a multi-quarter project.
- Migrate and evidence. Replace deprecated algorithms with FIPS 203/204/205 equivalents, and keep the CBOM current as the living record auditors will ask for.
The bottom line
A CBOM is the foundation of post-quantum readiness and crypto-agility. The standard is settled, the deadlines are set, and the tools to build one exist today. Whether you start with an open-source generator or a platform that ties the CBOM to the rest of your stack, the first move is the same: build the inventory now, while you still have a decade to act on it.