Cryptographic Bill of Materials: The Foundation of PQC Readiness

Every PQC migration project eventually runs into the same wall: no one can produce a complete list of what cryptographic algorithms the organisation actually uses. Not what the procurement documents say. Not what the vendor specs claim. What is running right now, in production, across the full technology estate. Without that list, every migration decision is approximate at best and wrong at worst.

A Cryptographic Bill of Materials is the structured answer to that problem. It gives organisations a machine-readable record of every cryptographic asset: algorithm, mode, key size, implementation library, certificate type, and deprecation status. The CycloneDX 1.6 specification, published in April 2024, provides an interoperable schema for generating and consuming this data. Tooling now exists to automate significant portions of the discovery work. And the EU Cyber Resilience Act has made cryptographic asset management a compliance obligation, not just a planning best practice.

This article explains what a CBOM captures, how it differs from a conventional Software Bill of Materials, what the CycloneDX 1.6 schema looks like in practice, and how to build a CBOM programme that actually drives migration decisions.

What a CBOM Is and Why the Terminology Matters

A Software Bill of Materials lists the components in a software product: libraries, packages, versions, licences, and dependency relationships. The NTIA Minimum Elements for a Software Bill of Materials, published in July 2021, defines the baseline fields: supplier name, component name, version, component hash, unique identifiers, dependency relationships, and SBOM author with timestamp. This is a useful inventory of what is installed.

A CBOM extends the SBOM to capture what those installed components are doing cryptographically. A library dependency entry in an SBOM might record that OpenSSL 3.1.4 is present. A CBOM records which algorithms OpenSSL is invoking, in which modes, with which key sizes, and whether those configurations are deprecated under current standards. The CycloneDX BOM Specification version 1.6 explicitly frames the cryptographic extension as a layer on top of the SBOM concept, not a replacement for it.

The distinction matters because the same library can simultaneously contain compliant and non-compliant cryptographic operations. OpenSSL 3.1.4 might be running TLS 1.3 sessions using AES-256-GCM, legacy TLS 1.2 sessions using AES-128-CBC, and certificate validation using RSA-2048 signatures. An SBOM records one entry for OpenSSL. A CBOM records three distinct cryptographic asset entries with different risk profiles and different migration priorities.

CBOM as a PQC Prerequisite

NIST IR 8547, the Initial Public Draft published in November 2024, frames cryptographic discovery as the first phase of any post-quantum transition. The document explicitly requires organisations to inventory cryptographic implementations before planning migration. This is not a procedural nicety. An organisation that begins PQC migration without an inventory will either over-migrate (replacing algorithms that do not need replacing first) or under-migrate (missing quantum-vulnerable assets in legacy systems, embedded firmware, or third-party middleware).

The scale of the problem is the reason the standard requires this step. Cryptographic assets are distributed across application code, middleware, database connectors, authentication infrastructure, hardware security modules, certificate stores, VPN endpoints, and embedded firmware. No manual survey catches all of them. Automated CBOM generation is the only approach that scales to enterprise complexity.

The CycloneDX 1.6 Cryptographic Asset Schema

CycloneDX 1.6 was published in April 2024. It extended the existing BOM standard with a dedicated cryptographic asset type. Understanding the key schema fields is necessary for evaluating CBOM tooling and for commissioning a CBOM programme.

Core Schema Fields

The CycloneDX 1.6 cryptographic asset schema captures the following fields, each of which is relevant to PQC migration planning:

  • algorithm: The cryptographic algorithm identifier (AES, RSA, ECDH, ML-KEM, ML-DSA, and so on). This maps to algorithm names; additional context fields specify the associated standard.
  • mode: Operation mode where applicable. Values include CBC, GCM, CCM, ECB, CFB, OFB, CTR. GCM is the preferred mode for authenticated encryption; CBC without a message authentication code is considered weak.
  • keySize: Key length in bits. The field enables automated flagging of undersized keys: 1024-bit RSA, 128-bit AES where 256 is required, or 1184 bytes for an ML-KEM-768 encapsulation key.
  • padding: Padding scheme. PKCS#1v1.5 for RSA encryption is considered legacy; OAEP and PSS are the current recommendations. PKCS#1v1.5 for RSA signature and encryption is specifically deprecated under NIST guidance.
  • certificateType: TLS, SSH, code signing, document signing, S/MIME, timestamping. This field identifies the certificate's use context, which determines migration priority and the relevant standards body.
  • primitiveType: Identifies whether the asset is a cipher, hash, digital signature, key-derivation function, MAC, KEM, or asymmetric key establishment primitive.

NIST IR 8547 Deprecation Status Integration

The highest-value use case for CBOM tooling is automated deprecation scoring. NIST IR 8547 IPD defines a timeline for deprecating classical cryptographic algorithms, covering RSA, DSA, ECDSA, DH, ECDH, and AES variants with defined sunset dates. By annotating each CBOM entry with its NIST IR 8547 status (approved, deprecated by a specific date, or disallowed), a CBOM system converts a static inventory into a risk-prioritised migration backlog.

RSA and ECDSA are targeted for deprecation under NIST IR 8547 for most uses, with sunset dates in the 2030 to 2035 range depending on key size and use context. An RSA-2048 TLS certificate discovered in a CBOM entry can be automatically flagged with a migration deadline rather than sitting as an unscored entry in a spreadsheet. The exact dates in the IPD are subject to revision in the final publication, so CBOM tooling should be built to update deprecation status as the standard matures.

How CBOM Differs from a Plain SBOM in Practice

An SBOM entry records name, version, supplier, hash, and licence. It does not record what the library does cryptographically or whether any invocation uses a vulnerable configuration. A CBOM entry records the algorithm invocation, the configuration parameters, the execution context, the providing library and version, and the deprecation status of that configuration. The SBOM is an inventory manifest. The CBOM is a functional map.

A payment processing application might produce a CBOM with 47 cryptographic asset entries across 6 SBOM components. The SBOM tells a security team what is installed. The CBOM tells them what is being used and whether any of it is quantum-vulnerable.

Not every CBOM entry will require migration. AES-256-GCM is considered quantum-resistant for bulk encryption: Grover's algorithm halves the effective key length, leaving 128 bits of security, which is considered acceptable. RSA, ECDSA, ECDH, and DH for key establishment and signatures are quantum-vulnerable to Shor's algorithm and will be flagged by any CBOM analysis tool with NIST IR 8547 integration. The CBOM makes that distinction explicit for every algorithm invocation in the estate.

Tooling for CBOM Emission

Three tools are relevant for organisations building a CBOM programme today:

  • cdxgen (github.com/CycloneDX/cdxgen): An open-source CLI tool that analyses application codebases, build files, and package manifests to emit CycloneDX BOMs including the cryptographic extension. It supports multiple language ecosystems including Java, Python, JavaScript, Go, and .NET. Cryptographic asset support has been added progressively from version 8.x.
  • Syft (github.com/anchore/syft): An SBOM generation tool from Anchore, primarily focused on container image and filesystem analysis. Syft has added cryptographic asset scanning capability in recent versions for file-based cryptographic detection.
  • Snyk OSS scanning: Snyk's dependency scanning pipeline identifies cryptographic library versions and flags known-vulnerable configurations. Integration with CBOM emission is available through Snyk's SBOM export feature and partner integrations.

Tool coverage is not yet complete. Static analysis discovers algorithms present in code; it cannot always determine which algorithms are invoked at runtime, particularly in dynamically configured systems where algorithm selection is determined by configuration files or environment variables. That limitation is documented in CBOM tooling guidance and acknowledged by tool maintainers. It means CBOM output from static tools should be treated as a starting inventory, not a complete one, and supplemented by runtime analysis where feasible. For more detail on discovery tool coverage, see Automated Cryptographic Discovery Tools for PQC.

Regulatory and Compliance Context

Two EU regulatory frameworks create explicit obligations that CBOM programmes directly address.

EU Cyber Resilience Act

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers of products with digital elements to maintain security documentation including the software composition of their products. Annex I Part II point (1) requires manufacturers to identify and document components including security-relevant components. The CRA does not use the term CBOM, but the cryptographic component documentation obligation aligns directly with what a CycloneDX 1.6 CBOM captures. An organisation maintaining a current CBOM for its products is well-positioned to demonstrate CRA compliance for the cryptographic asset documentation requirement.

NIS2 and Sector-Specific Obligations

NIS2 Directive (EU) 2022/2555, Article 21(2)(h) requires entities to implement appropriate cryptographic and encryption policies. A CBOM provides the evidence base for demonstrating that cryptographic selections are documented and reviewed against current standards. Article 21(2)(d) addresses supply chain security, which includes understanding the cryptographic posture of third-party components and software dependencies. That is precisely the use case for CBOM in a supplier assessment context: an organisation that can provide a CycloneDX CBOM for its products gives its customers the data they need to assess supply chain cryptographic risk. See the related analysis at SBOM and Post-Quantum Readiness for how SBOM and CBOM obligations interact.

Building a CBOM Programme: Practical Starting Points

The first question is where to start, not how to achieve complete coverage immediately. Begin with systems handling long-lived sensitive data, where the Harvest Now Decrypt Later risk is most acute. Extend to systems in regulated sectors and public-facing TLS endpoints. Prioritise by data sensitivity and the retention period of the data being protected.

Integrate CBOM generation into your CI/CD pipeline early. Running cdxgen or equivalent tools on each build ensures the cryptographic inventory stays current as code changes rather than becoming stale between point-in-time assessments. The goal is a living inventory, not a snapshot taken once and filed.

Build a scoring layer that maps CBOM output to NIST IR 8547 deprecation dates. A simple annotation on each entry with its deprecation status converts an inventory into a risk register. That register becomes the input for migration sequencing decisions. See Cryptographic Inventory for Enterprise PQC for a worked example of how to structure that sequencing.

The most important conceptual boundary to maintain is the separation between inventory and migration. A CBOM tells you what you have. It does not migrate anything. The migration plan is a separate deliverable that uses the CBOM as its input. A CBOM that is never acted on provides no security benefit. Its value is in driving the migration backlog and the sequencing decisions that follow. QSECDEF's advisory programme supports organisations at both the inventory and migration planning stages. Expert Membership provides access to structured guidance for teams commissioning a CBOM programme for the first time.