All insights
·Post-Quantum Readiness·IQCDL

How to Build a CBOM (Cryptographic Bill of Materials): A Step-by-Step Guide

A CBOM is the inventory that makes post-quantum migration possible. Here's how to build one — the sources, the tooling, the four categories to capture, and the pitfalls that stall most programs.


How to Build a CBOM (Cryptographic Bill of Materials): A Step-by-Step Guide

Every post-quantum migration plan runs into the same wall on day one: you cannot migrate cryptography you cannot see. The Cryptographic Bill of Materials — the CBOM — is how you make it visible. It is the single most important, and most often skipped, deliverable of a quantum-readiness program.

This guide covers what a CBOM is, how it differs from an SBOM, and a repeatable process to build one.

What a CBOM is (and how it differs from an SBOM)

A CBOM is a structured, machine-readable inventory of every cryptographic asset in your environment — algorithms, keys, certificates, libraries and protocols — and the relationships between them. Where an SBOM (Software Bill of Materials) tells you which components make up an application, a CBOM tells you which cryptography those components rely on. A CBOM is explicitly designed to build on an SBOM: the dominant format is an extension of the CycloneDX standard.

The point of the exercise is decision-ready data: which systems use quantum-vulnerable public-key crypto (RSA, ECC, Diffie-Hellman), where, and how urgently each must move to a NIST PQC standard (FIPS 203 ML-KEM, FIPS 204 ML-DSA, FIPS 205 SLH-DSA).

The five steps

1. Start with the inventories you already have

Don't scan first. Pull together IT asset databases, the CMDB, certificate-management platforms, and — most importantly — any SBOMs you already generate. These are all cryptographic signal you own before touching a scanner.

2. Discover what those inventories miss

Now find cryptography that isn't in an asset list. Effective discovery is layered:

  • Source-code and binary analysis for algorithms and libraries baked into applications.
  • Network and traffic analysis for TLS versions and cipher suites actually negotiated in production.
  • Configuration scanning for appliances, load balancers, VPNs and third-party services.

The objective is to identify every place cryptography is implemented, configured, or implicitly relied upon.

3. Capture four categories for every finding

A robust CBOM records:

  • Algorithms — type and key length/parameters (e.g., RSA-2048, ECDSA P-256, AES-256).
  • Libraries / modules — name and version (e.g., OpenSSL 3.x).
  • Key & certificate material — certificate chains, key types, expiry.
  • Protocols & usage — TLS/SSL versions, cipher suites, where each is used.

4. Use the right tools and standard

Emit the inventory as CycloneDX CBOM so it's portable and machine-readable. Tooling ranges from the open-source IBM CBOMkit to commercial platforms that tie the CBOM to "break-year" estimates and compliance evidence. Standardizing the output now is what lets you automate re-scans later.

5. Make it continuous, not a one-off

Wire CBOM generation into your build pipelines and run periodic estate-wide scans, and tie it into change management so new cryptographic assets are captured as they appear. A CBOM that's regenerated on every build is an asset; a CBOM in a spreadsheet from last quarter is already wrong.

Prioritize by risk, not by what's easy to count

Two failure modes sink most first attempts:

  • Code-scanning tunnel vision — teams scan source and miss the cryptography living in network configs, appliances and third-party services.
  • Completeness over usefulness — spending months cataloging every SHA-256 checksum while the actually-dangerous RSA key exchanges sit unaddressed.

Rank findings with Mosca's Theorem: the assets protecting data with the longest secrecy lifetime (X) are the ones to migrate first, because they're most exposed to "harvest now, decrypt later." A CBOM's value is not the row count — it's that it lets you sequence remediation by real risk.

Where the CBOM fits in the bigger plan

The CBOM is the "Assess" output that feeds "Plan" and "Implement." Once you can see your cryptography, you can build a phased, crypto-agile migration roadmap — starting with hybrid PQC pilots on your highest-risk systems. Building and using a CBOM is a core competency in the hands-on IQCDL Practitioner Level; the strategy that surrounds it is covered in the Foundation Level for security leaders.

Not sure where your organization stands? The free IQCDL readiness assessment returns an AI-tailored risk profile in two minutes.

FAQ

What is a CBOM? A Cryptographic Bill of Materials — a machine-readable inventory of every cryptographic algorithm, key, certificate, library and protocol in your environment, and where each is used. It extends the SBOM concept to cryptography.

What format should a CBOM use? The dominant standard is an extension of CycloneDX, which keeps the inventory portable and machine-readable and lets you automate regeneration in CI/CD.

Why is a CBOM needed for post-quantum migration? Because you cannot migrate cryptography you cannot see. The CBOM tells you which systems use quantum-vulnerable public-key algorithms so you can prioritize and sequence the move to NIST PQC standards.

What's the most common mistake when building a CBOM? Relying on source-code scanning alone and missing cryptography in network configurations, appliances and third-party services — and chasing completeness instead of prioritizing the high-risk RSA/ECC key exchanges first.