What Is a CBOM (Cryptographic Bill of Materials)? A Practitioner's Guide for Security Architects

NIST finalized FIPS 203, FIPS 204, and FIPS 205 in August 2024.^{[NIST FIPS Publications]} Security architects now have approved post-quantum algorithms to migrate to. What most organizations lack is the foundational inventory that makes migration possible: a systematic record of every cryptographic asset in production. Without that record, migration planning is guesswork. A Cryptographic Bill of Materials (CBOM) is how you build it.

What a CBOM Actually Contains

A CBOM is a structured inventory of cryptographic assets within a software system. According to the CycloneDX CBOM specification - currently the closest thing to a machine-readable standard for this data type - a complete CBOM documents cryptographic algorithms, key lengths, key material references, digital certificates, cryptographic libraries, protocols, and inter-component dependencies.^{[CycloneDX CBOM Specification]} Each of these components carries distinct risk characteristics: an RSA-2048 key used in a TLS handshake represents a different remediation priority than an AES-256 symmetric key used for data-at-rest encryption.

The IBM Research team that formalized early CBOM concepts frames the inventory around three questions: what cryptographic primitives are present, how they are configured, and how components depend on each other.^{[IBM Research: Cryptographic Bill of Materials]} That dependency dimension is where CBOMs add the most value beyond a simple algorithm list - a single vulnerable library may be consumed transitively by dozens of services, none of which are visible through manual inspection.

CBOM vs. SBOM: Related But Not Interchangeable

Executive Order 14028 normalized Software Bill of Materials (SBOM) requirements for federal software suppliers, establishing machine-readable component inventories as an expected artifact of secure software development.^{[CISA SBOM Resources]} A CBOM is the logical cryptographic layer on top of that foundation - and the two share tooling infrastructure. CycloneDX introduced cryptographic assets as a formal component type in version 1.4, making it the current de facto schema for machine-readable CBOMs.^{[CycloneDX CBOM Specification]}

The distinction matters operationally. An SBOM tells you which libraries a system uses. A CBOM tells you which cryptographic algorithms those libraries implement, at what key lengths, and in which configurations. A system can have a complete, accurate SBOM and still give a security architect no usable information about its quantum-risk exposure. Conversely, teams that have already invested in SBOM tooling compatible with CycloneDX can extend that investment to produce CBOMs with incremental - not duplicative - effort.

Static CBOM vs. Dynamic Cryptographic Inventory: Know the Difference

Vendor marketing frequently conflates two distinct concepts. A static CBOM captures what is baked into software: algorithms declared in source code, libraries linked at build time, certificates bundled with an application. This is discoverable through static analysis and is the proper scope of a CBOM artifact.^{[IBM Research: Cryptographic Bill of Materials]} A dynamic or operational cryptographic inventory captures runtime behavior: which cipher suites are actually negotiated in TLS sessions, which keys are in active rotation, which certificates are near expiry across an enterprise fleet.

Both are valuable. Neither substitutes for the other. Security architects who conflate them end up with inventories that are either incomplete (static-only, missing runtime configuration drift) or unmanageably broad (operational-only, lacking the software-component provenance needed for remediation planning). A credible CBOM program defines its scope explicitly and treats static and dynamic inventories as complementary layers, not competing approaches. For teams already thinking through crypto-agility as an architectural capability, the CBOM is what populates the asset register that agility mechanisms act on.

Why CBOM Is the Prerequisite for PQC Migration

The sequencing logic is straightforward: you cannot prioritize migration of assets you have not inventoried, and you cannot quantify risk exposure on a timeline you cannot map to specific systems. NIST's finalized post-quantum standards - ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205) - define the destination.^{[NIST FIPS Publications]} A CBOM defines the starting point: every instance of RSA, ECDH, and ECDSA that must be replaced or augmented.

This is not a theoretical concern. Harvest Now, Decrypt Later (HNDL) attacks involve adversaries exfiltrating encrypted data today with the intent to decrypt it when quantum capability matures. Every undocumented cryptographic asset is an unquantified liability on that timeline. Teams working through the operational implications of HNDL attacks consistently arrive at the same conclusion: without a CBOM, there is no defensible answer to which systems carry the highest exposure. Risk-tiering requires data, and the CBOM is where that data lives.

There is also a compliance trajectory argument. No regulatory body - not NIST, CISA, ENISA, or ETSI - mandates a CBOM as of publication. This is a material fact, not a footnote. However, CISA's SBOM resources explicitly frame software component transparency as an evolving expectation,^{[CISA SBOM Resources]} and NIST IR 8547 addresses migration planning considerations that are practically impossible to execute without cryptographic asset visibility.^{[NIST IR 8547]} Organizations that build CBOM capability now are positioned ahead of the likely compliance curve, not scrambling to meet a retroactive requirement.

The Standards and Tooling Landscape as of 2026

CycloneDX v1.4+ is the de facto schema. No competing machine-readable standard for CBOM has reached comparable adoption.^{[CycloneDX CBOM Specification]} IBM's cbomkit is one open-source implementation that generates CycloneDX-compatible CBOM output through static analysis. The Sectigo PKI team notes that certificate inventories represent a particularly well-defined CBOM entry point for organizations already managing a PKI estate, since certificate metadata (algorithm, key length, expiry, issuer chain) is structured and machine-readable by design.^{[Sectigo: CBOM Explainer]}

Two gaps are worth flagging explicitly for architects evaluating tooling. First, no standardized vulnerability scoring model for cryptographic assets exists. CVSS scores address software vulnerabilities, not algorithm deprecation risk - meaning teams must define their own risk-tiering criteria for quantum-vulnerable algorithms until a formal model emerges. Second, interoperability between CBOM tools is immature. An artifact generated by one scanner may not parse cleanly into a downstream GRC platform. Teams should validate the full pipeline - generation, storage, and consumption - before committing to a toolchain. For teams evaluating how ML-KEM (FIPS 203) differs architecturally from its predecessor, the CBOM is what surfaces which systems need that specific migration path versus others.

Building Your First CBOM: A Phased Entry Point

Security architects in complex environments understand that enterprise-wide mandates stall. The operationally effective entry point is a bounded deliverable scoped to a single, well-understood production application.

Phase 1: Single Application Proof of Concept

Select one application with defined boundaries - ideally one that handles sensitive data or sits in a regulated context. Run a static analysis tool compatible with CycloneDX. Document the output: which algorithms appear, at what key lengths, in which libraries, with what dependencies. The goal is not completeness. It is operational familiarity with what the tooling surfaces and what it misses.

Phase 2: Gap Analysis and Scope Extension

Use the proof-of-concept output to define what a program-level CBOM initiative would require. Where did the scanner fail to reach (e.g., dynamically loaded libraries, third-party SDKs, network-layer configurations)? What certificate inventory data is missing? That gap analysis becomes the business case for expanding scope and tooling investment. It also surfaces the dynamic inventory work that a static CBOM alone cannot address.

Phase 3: Risk-Tiered Asset Register

Map inventoried assets to quantum-risk categories: algorithms that NIST has deprecated or plans to deprecate (RSA, ECDH, ECDSA used for key establishment and signatures), algorithms with retained post-quantum security margins (AES-256, SHA-384), and hybrid configurations. This tiering is the direct input to PQC migration sequencing. Without it, migration planning lacks the asset-level specificity needed to prioritize engineering effort.

As a concrete next action: run a cryptographic discovery scan on one production application this sprint using a CycloneDX-compatible tool such as IBM's cbomkit. Treat the output as a diagnostic, not a deliverable - document what it reveals, where the gaps are, and what questions it raises about your broader estate. That artifact is your baseline and your internal business case.

Key Takeaways

• A CBOM documents cryptographic algorithms, key lengths, certificates, libraries, protocols, and inter-component dependencies within a software system - it is the visibility layer PQC migration depends on.
• CycloneDX v1.4+ is the current de facto machine-readable schema for CBOM. No competing standard has reached comparable adoption as of publication.
• No NIST, CISA, ENISA, or ETSI mandate requires a CBOM as of April 2026. This is a material fact. The compliance trajectory is directional, not yet prescriptive.
• Static CBOM (software's built-in cryptographic capabilities) and dynamic cryptographic inventories (runtime configurations and usage patterns) are complementary, not interchangeable. Conflating them creates blind spots.
• No standardized vulnerability scoring model for cryptographic assets exists. Teams must define their own risk-tiering criteria until a formal model emerges.
• The operationally effective entry point is a single application proof-of-concept, not an enterprise-wide program. Build the evidence before scaling the mandate.
• FIPS 203, 204, and 205 define the migration destination. A CBOM defines the starting point - every instance of RSA, ECDH, and ECDSA that must be addressed.

Related Reading

On this site:

• How crypto-agility depends on a complete cryptographic asset inventory
• Why harvest-now-decrypt-later attacks make undocumented cryptographic assets an active liability
• What architects need to know about ML-KEM (FIPS 203) before planning migration

Primary sources:

• CycloneDX CBOM specification - schema definition and component types
• CISA Software Bill of Materials resources and federal guidance
• NIST IR 8547 - post-quantum migration planning considerations

Related Reading

On this site:

• Why every enterprise needs crypto agility before 2030
• Independent PQC vendor evaluation framework
• The practitioner's guide to post-quantum cryptography

Primary sources:

• NIST Post-Quantum Cryptography Project
• CISA Quantum Readiness Resources

This article draws on primary documentation from CycloneDX (cbom specification), CISA (sbom resources), NIST (FIPS publication index and IR 8547), IBM Research, and Sectigo. All claims verified against official sources as of April 2026.