What Is a Cryptographic Bill of Materials?
A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset deployed across an organization's technology estate. Each CBOM entry records what cryptographic algorithm is in use, where it is deployed, what data it protects, how sensitive that data is, and how urgently the asset should be migrated to post-quantum cryptography. The CBOM functions as the primary planning artifact for post-quantum migration programs and as an ongoing operational record for cryptographic governance.
The concept of a CBOM extends the Software Bill of Materials (SBOM) model a structured inventory of software components and their dependencies to cover cryptographic specifically. Where an SBOM answers 'what software is running here?', a CBOM answers 'what cryptography is running here, and how should it be migrated?' OMB M-23-02 requires U.S. federal agencies to develop and maintain cryptographic inventories that functionally serve as CBOMs, even though the specific term is used variably across guidance documents.
“Agencies shall maintain a current inventory of their information systems that use cryptographic systems or software and prioritize the transition of those systems to post-quantum cryptographic standards.”
CBOM vs. SBOM: Understanding the Relationship
A Software Bill of Materials (SBOM) lists software components and their dependencies, primarily to support vulnerability management and supply chain security. CBOMs extend this concept to cryptographic operations specifically. An SBOM entry for a Node.js application might note that it depends on the 'node:crypto' module and the 'openssl' package; the corresponding CBOM entry would specify which algorithms that dependency uses (e.g., ECDSA P-256 for TLS client authentication), in what context, and with what migration urgency.
CBOMs and SBOMs are complementary rather than overlapping. SBOM tooling identifies software components that perform cryptographic operations; CBOM tooling characterizes those operations cryptographically and maps them to data sensitivity and migration urgency. The CBOM requires SBOM data as input you need to know which software components are present before you can determine which cryptographic operations they perform but the CBOM adds layers of analysis that SBOM tooling alone does not provide. Emerging standards in the CycloneDX and SPDX SBOM ecosystems are adding CBOM-compatible cryptographic asset extensions.
Why CBOMs Are Essential for PQC Migration
PQC migration without a CBOM is like patching vulnerabilities without a CVE list: the scope is unknown, prioritization is arbitrary, and completion cannot be verified. A CBOM converts migration from an open-ended organizational effort into a bounded, plannable, trackable program. Every CBOM entry is a migration work item; completion means every entry has been migrated and verified. Without the CBOM, 'completion' has no definition.
The NIST NCCoE PQC migration project explicitly identifies cryptographic inventory as the starting point for the migration framework. NIST SP 1800-38 on migrating to post-quantum cryptography is organized around the assumption that organizations first build a comprehensive inventory, then risk-assess it, then plan migration. NSA's CNSA 2.0 requirements for National Security Systems cannot be tracked for compliance without knowing which systems use which algorithms a CBOM is the record that makes compliance monitoring possible.
What a CBOM Captures
A CBOM entry captures several categories of information. Asset identification includes a unique identifier, the asset type (TLS endpoint, code signing certificate, library dependency, HSM key, firmware component), and the location (hostname, service name, code repository, hardware identifier). Algorithm information includes the specific cryptographic algorithm and parameters (e.g., ECDSA with P-256), the algorithm's role (key exchange, authentication, encryption, hashing), and the algorithm's quantum vulnerability status.
Context information captures why the asset exists and what it protects: the system or application that uses it, the type of data it protects, the data sensitivity classification, and the required confidentiality lifetime of that data. Migration information tracks the current migration status (not started, in progress, completed), the target post-quantum algorithm, the migration owner, and the planned migration date. Together, these fields support both the risk-based prioritization needed for planning and the compliance tracking needed for governance.
CBOM Schema and Data Model
A minimal CBOM schema includes these required fields per entry: assetId (unique string identifier), assetType (enumerated: TLS_ENDPOINT, CERTIFICATE, CODE_SIGNING_KEY, LIBRARY, FIRMWARE_KEY, HSM_KEY, API_AUTH_KEY, OTHER), algorithm (algorithm identifier string), role (KEY_EXCHANGE, SIGNATURE, SYMMETRIC_ENCRYPTION, HASH), location (host/service/repository/hardware identifier), dataSensitivity (LOW, MEDIUM, HIGH, CRITICAL), confidentialityLifetimeYears (integer or 'PERMANENT'), systemCriticality (LOW, MEDIUM, HIGH, CRITICAL), migrationStatus (NOT_STARTED, PLANNED, IN_PROGRESS, COMPLETED).
Extended fields add migration planning information: targetAlgorithm (the post-quantum algorithm planned for migration), migrationPhase (the roadmap phase this entry belongs to), migrationOwner (team or individual responsible), plannedMigrationDate (target date), regulatoryScope (array of applicable regulatory frameworks), and notes (free-text field for context not captured in structured fields). The CBOM should be stored in a format that supports both human review and automated processing JSON and YAML are common choices for structured storage.
Cryptographic Asset Types in a CBOM
TLS endpoints are the most common CBOM asset type in enterprise environments. Each TLS endpoint is characterized by its key exchange algorithm (e.g., ECDHE-P256), authentication algorithm (e.g., RSA-2048 certificate), and the data sensitivity of traffic it carries. Certificate assets represent each X.509 certificate by its signature algorithm, key type and size, issuing CA, validity period, and deployment locations. Code signing key assets document the signing algorithm and key type used for each code signing identity.
Library and dependency assets represent cryptographic libraries and packages included in application software. Each library may contribute multiple cryptographic operations, and each should be recorded separately in the CBOM. HSM key assets record key types and algorithm identifiers for all keys stored in hardware security modules, including both the key generation algorithm and the usage algorithm (signing, encryption, key agreement). Firmware key assets document the cryptographic verification keys embedded in device firmware or hardware, which are often the hardest assets to migrate.
Building a CBOM Through Discovery
CBOM construction begins with automated discovery across all asset categories. Network scanning tools identify TLS cipher suites and key exchange algorithms at all network-accessible endpoints. Certificate management platforms provide X.509 certificate inventories with algorithm metadata. Static analysis tools scan source code repositories and binary packages for cryptographic API usage and algorithm configurations. Dependency scanners enumerate third-party library dependencies and their cryptographic capabilities.
Automated discovery is necessary but not sufficient. Manual review supplements automated findings by capturing cryptographic context not visible to automated tools: which data flows through each encrypted channel, what the sensitivity and retention requirements of that data are, which systems are operationally critical, and which are subject to specific regulatory requirements. The CBOM is assembled by merging automated discovery output with manually collected context into a unified structured record for each identified cryptographic asset.
Automated CBOM Generation
Automated CBOM generation tools are available for several asset categories. Network-level tools (testssl.sh, SSLyze, TLS Observatory) can generate structured output listing TLS endpoint characteristics suitable for CBOM ingestion. Certificate lifecycle management platforms (DigiCert, Venafi, Keyfactor, HashiCorp Vault) maintain certificate inventories that can export to CBOM-compatible formats. Software composition analysis (SCA) tools (Sonatype, Snyk, Dependabot) identify library dependencies, and emerging quantum-aware SCA tools map those dependencies to their cryptographic operations.
The IETF is developing specifications for machine-readable CBOM formats within the broader SBOM ecosystem. NIST NCCoE's PQC migration project includes tool evaluations that assess cryptographic discovery and CBOM generation capabilities. Organizations should not wait for CBOM tooling to fully mature before beginning inventory work a structured spreadsheet or database built from automated discovery output and manual review provides the functional equivalent for migration planning, and can be migrated to a standardized format when tooling stabilizes.
CBOM Governance and Ownership
A CBOM is only useful if it is accurate and current. Governance requires assigning ownership for each CBOM entry the team responsible for migrating the asset and establishing a process for maintaining accuracy as systems change. Without ownership, migration work items have no accountable party. Without currency, the CBOM diverges from reality as systems are deployed, updated, or decommissioned, and migration planning becomes disconnected from the actual technology estate.
CBOM governance should be integrated into existing IT governance processes: change management reviews should check whether proposed system changes affect CBOM entries, new system deployments should automatically trigger CBOM entry creation, and periodic review cycles should validate that the CBOM reflects current reality. The CBOM owner at the organizational level typically the CISO or a designated PQC program manager is responsible for the completeness and accuracy of the overall CBOM and for reporting migration progress against the roadmap.
Keeping the CBOM Current
The CBOM is a living record that must be maintained continuously, not built once and archived. System changes that affect CBOM accuracy include: TLS certificate renewals that change the algorithm or certificate authority, library updates that change the cryptographic algorithms used by application code, new service deployments that add cryptographic endpoints, system decommissioning that removes assets from scope, and vendor migrations that change the cryptographic characteristics of SaaS or cloud services.
Integrating CBOM maintenance into CI/CD pipelines provides automated detection of algorithm changes in application code code review checks can flag new cryptographic API calls for CBOM review. Certificate lifecycle management automation can update CBOM certificate entries on renewal. Network monitoring can alert when TLS cipher suite configurations change at production endpoints. These automated maintenance mechanisms reduce the manual burden of keeping the CBOM current while improving accuracy through continuous rather than periodic verification.
CBOM as Migration Roadmap Input
The prioritized CBOM is the direct input to migration roadmap planning. Each CBOM entry is transformed into a migration work item with an associated priority score (derived from data sensitivity, confidentiality lifetime, system criticality, and regulatory context), target algorithm, and estimated migration effort. The work items are organized into migration phases by priority score, with dependencies between entries determining sequencing within phases.
Tracking migration progress against the CBOM provides the status reporting needed for both internal governance and regulatory compliance. OMB M-23-02 requires federal agencies to report on migration progress; a well-maintained CBOM provides the data for that reporting automatically. CNSA 2.0 compliance tracking for National Security Systems similarly requires knowing which systems have migrated to CNSA 2.0 algorithms the CBOM's migrationStatus and targetAlgorithm fields provide exactly this information.
CBOM Standards and Emerging Specifications
CBOM standardization is an active area of development. The CycloneDX SBOM standard has added a cryptographic asset component type (CryptographicProperties) that captures algorithm identifiers, key sizes, and other cryptographic metadata. The IETF PQUIP working group has produced drafts addressing how cryptographic inventories should be structured and maintained as part of protocol agility guidance. NIST's NCCoE PQC migration project is developing reference CBOM schemas and tool guidance as part of its SP 1800-38 practice guide series.
Organizations do not need to wait for standards to finalize before building CBOMs. The functional requirements of a CBOM unique asset identifiers, algorithm characterization, data sensitivity annotation, migration status tracking are well-understood. A CBOM built in a locally defined schema today can be converted to an emerging standard schema when tooling and standards stabilize. The risk of beginning with a non-standard schema is low; the risk of not building a CBOM at all, due to waiting for standards, is substantial.
References
- [1]
- [2]
- [3]NSANSA CNSA 2.0(2022)Commercial National Security Algorithm Suite 2.0
- [4]OMBOMB M-23-02(2022)Memorandum on Migrating to Post-Quantum Cryptography
- [5]CISACISA/NSA/NIST Joint Guidance(2023)Quantum-Readiness: Migration to Post-Quantum Cryptography
- [6]IETFIETF PQUIP WG(2022)Post-Quantum Use In Protocols Working Group
Related Guides
Complete Guide to Post-Quantum Cryptography
A comprehensive reference covering why classical public-key cryptography is being replaced, the NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA), the harvest-now decrypt-later threat, and how to plan and execute a cryptographic migration program.
What Is Harvest Now Decrypt Later?
Harvest-now, decrypt-later (HNDL) is the most immediate cryptographic risk requiring action before quantum computers exist at scale. This guide explains how HNDL attacks work, what data is most exposed, and why cryptographic migration cannot wait.
ML-KEM Explained
ML-KEM (NIST FIPS 203) is the primary post-quantum key encapsulation mechanism, replacing RSA and ECDH in TLS, VPNs, and SSH. This guide explains how it works, its parameter sets, hybrid deployment, and migration from ECDH.