CBOM Cryptographic Bill of Materials for Sovereign PQC Readiness

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic primitive, key size, certificate and protocol in use across an organisation’s infrastructure stack. It extends the Software Bill of Materials (SBOM) concept, which catalogues software components and dependencies, by adding a dedicated layer that captures the specific cryptographic properties of each component: which algorithm encrypts data at rest, which certificate authority signs authentication tokens, and whether any of those choices are vulnerable to a cryptographically relevant quantum computer.

For European government bodies and regulated-sector organisations that are evaluating sovereign infrastructure alternatives, a CBOM is not an optional audit artefact. It is the prerequisite for every post-quantum migration plan, every NIS-2 or DORA compliance demonstration, and every credible response to the deadlines set by the EU PQC Transition Roadmap.

From SBOM to CBOM: What the Extension Actually Covers

A standard SBOM tells you that your system runs OpenSSL 3.1.4 or that a Java dependency includes Bouncy Castle 1.77. A CBOM tells you that those libraries are negotiating RSA-2048 key exchange, signing with ECDSA P-256, and that a firmware component in your network appliance still hardcodes SHA-1. That distinction matters because quantum computers capable of running Shor’s algorithm would break RSA and elliptic-curve discrete-log schemes regardless of key size, while symmetric algorithms like AES-256 retain acceptable security under Grover’s algorithm with doubled effective key length.

The CycloneDX CBOM schema, maintained by the OWASP Foundation, formalises this extension. It introduces dedicated component types for cryptographic assets, algorithm specifications, certificates and related key material, all within the broader CycloneDX ecosystem that many organisations already use for SBOM generation. A CycloneDX CBOM document can be ingested by vulnerability management platforms, shared with regulators as a compliance artefact, and version-controlled alongside code in a repository.

Generating an Initial CBOM Without Manual Code Review

Automated scanning is the only practical starting point for complex on-premises environments that may include thousands of services, legacy appliances, and interdependent firmware stacks.

Several complementary approaches can produce a first-pass CBOM within weeks:

• Binary and library scanning: Tools such as IBM’s open-source cbomkit perform static analysis of compiled binaries and library files to identify algorithm usage, generating output that conforms to the CycloneDX CBOM schema without requiring source code access.
• Network traffic analysis: Passive TLS inspection identifies the cipher suites and certificate properties negotiated in live traffic, surfacing legacy configurations such as TLS 1.0 or RSA key exchange that static analysis might miss in appliances where firmware is inaccessible.
• CISA PQC Product Category List alignment: Under Executive Order 14306, CISA published a categorised list of product types (network equipment, identity and access management, encryption gateways, and others) with guidance on assessing each category for quantum vulnerability. Mapping your asset inventory against this list provides a structured triage framework even before scanning tools have completed a full sweep.
• NIST IR 8547 as the deprecation reference: NIST IR 8547, released as an initial public draft in 2024, provides the definitive timeline for deprecating classical public-key schemes. It designates all RSA, elliptic-curve and finite-field Diffie-Hellman variants for transition, giving scanning outputs a normative benchmark against which to classify findings as critical, high or lower priority.

RFC 9958, titled “Post-Quantum Cryptography for Engineers,” provides protocol-level implementation guidance that complements scanning output by explaining how hybrid schemes combining classical and post-quantum algorithms should be structured during the transition period, helping engineers interpret CBOM findings in the context of practical deployment choices.

Maintaining a CBOM Across the Infrastructure Lifecycle

An initial CBOM becomes unreliable within months if not integrated into operational processes. Three mechanisms sustain accuracy over time.

First, the CBOM pipeline should hook into the CI/CD process. Every container build or package update triggers a CBOM diff that flags newly introduced cryptographic dependencies. Tools that already produce SBOMs as part of a build process can be extended with CycloneDX CBOM plugins at minimal additional cost.

Second, firmware and hardware refresh cycles must include a CBOM review gate. Network appliances, HSMs and smart-card readers often contain hardcoded cryptographic implementations that are only exposed during vendor update documentation review. A CBOM maintenance policy should require vendors to supply updated cryptographic property disclosures alongside firmware changelogs.

Third, certificate expiry tracking and key rotation schedules should be embedded within the CBOM data model. The CycloneDX schema supports validity periods and issuer metadata, meaning a properly maintained CBOM can serve simultaneously as a certificate lifecycle management input and a compliance evidence document.

The CBOM and the EU PQC Transition Roadmap

The relationship between a CBOM and European regulatory timelines is direct and consequential.

The European Commission Recommendation on Post-Quantum Cryptography, issued on 11 April 2024, states that Member States should elaborate national post-quantum transition plans no later than the end of 2026 and complete migration of high-risk systems and critical infrastructure by 2030. This recommendation applies to public sector bodies and extends in practice to regulated sectors including finance, healthcare and telecommunications through sector-specific supervisory expectations under NIS-2 and DORA.

“Member States should elaborate national post-quantum transition plans no later than end of 2026 and complete migration of high-risk systems and critical infrastructures by 2030.” — European Commission, Commission Recommendation on Post-Quantum Cryptography, 11 April 2024

A credible transition plan requires a baseline inventory. An organisation that cannot demonstrate, with documented evidence, which of its systems use quantum-vulnerable cryptography cannot produce a realistic migration timeline, cannot prioritise investment, and cannot report progress to a competent authority. The CBOM is that baseline inventory.

The CBOM as Primary Audit Evidence Under NIS-2 and DORA

A CBOM produces the kind of evidence that NIS-2 and DORA auditors are increasingly expecting, even though neither regulation names the artefact explicitly.

NIS-2 (Directive 2022/2555) requires essential and important entities to implement technical and organisational measures proportionate to the risks posed to the security of their network and information systems, including policies on cryptographic use. A CBOM demonstrates that an organisation has systematically identified its cryptographic exposure, classified assets by risk (quantum-vulnerable versus compliant), and is executing a remediation roadmap rather than relying on informal assessments.

DORA (Regulation 2022/2554) requires financial entities to maintain an ICT asset register and to test and document the resilience of ICT systems. A CBOM that includes cryptographic asset metadata satisfies the asset register requirement for the cryptography layer and provides the documentary basis for resilience testing that involves encryption failures or certificate revocation scenarios.

“Organisations should not wait for a cryptographically relevant quantum computer to appear before starting their PQC migrations. The time to act is now, beginning with an inventory of cryptographic assets.” — CISA, Post-Quantum Cryptography Initiative

The statistical picture reinforces urgency. According to the IBM Cost of a Data Breach Report 2024, the global average cost of a data breach reached USD 4.88 million in 2024, the highest ever recorded. Meanwhile, an Entrust survey published in 2023 found that approximately 61% of organisations had no formal PQC transition programme in place. These two data points together describe the risk: the financial consequences of cryptographic failure are escalating at exactly the moment when most organisations have not yet started the transition that would prevent it.

CBOM and Crypto-Agility: Rotating Algorithms Without Redesigning Systems

Crypto-agility is the architectural property that allows an organisation to replace a cryptographic primitive across its systems without requiring a ground-up redesign. A live CBOM is what makes crypto-agility operationally feasible rather than theoretically desirable.

In August 2024, NIST finalised three post-quantum standards: FIPS 203 ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), FIPS 204 ML-DSA (Module-Lattice-Based Digital Signature Algorithm) and FIPS 205 SLH-DSA (Stateless Hash-Based Digital Signature Algorithm). Many organisations that began PQC pilots before finalisation used interim hybrid schemes or pre-standardisation candidates. When these standards supersede those interim deployments, the question becomes: which of our systems need to be updated, and in what order?

A CBOM answers that question immediately. Because every service, appliance and dependency is mapped to the specific algorithm it uses, the security team can query the CBOM for all instances of a deprecated primitive, produce a prioritised remediation list ordered by system criticality and data sensitivity, and schedule updates without conducting a new discovery exercise from scratch. Without a CBOM, the same exercise requires weeks of manual investigation each time a standard changes.

NIST IR 8547 formalises the deprecation schedule that drives these rotation decisions. Its timeline designates 2030 as the point by which RSA and elliptic-curve key exchange must be replaced in most contexts, and it identifies specific key sizes and algorithm variants that are deprecated earlier. A CBOM that classifies each finding against the NIST IR 8547 deprecation schedule allows organisations to sequence migration waves by deadline rather than by convenience, which is the prioritisation logic that regulators expect to see documented in a transition plan.

Practical Steps for Sovereign Organisations Starting Today

For a government body or regulated-sector organisation that has not yet begun a CBOM programme, the starting sequence is straightforward. Begin with an automated scan using tools aligned to the CycloneDX CBOM schema and the CISA PQC Product Category List to produce a first-pass inventory. Classify findings against NIST IR 8547 deprecation timelines and assign system criticality ratings drawn from existing risk registers. Integrate the CBOM output into the NIS-2 or DORA ICT asset register. Establish a maintenance cadence that triggers CBOM updates on every firmware release, dependency upgrade and certificate renewal. Finally, use the CBOM as the evidentiary backbone of the EU PQC Transition Roadmap submission that Member States are expected to produce by 2026.

The CBOM is not the destination; it is the instrument of navigation. Without it, the transition to FIPS 203, 204 and 205 becomes a reactive scramble rather than a managed programme, and the audit trail that NIS-2, DORA and the Commission Recommendation require does not exist.

FAQ

Is a CBOM legally required under NIS-2 or DORA?

Neither NIS-2 nor DORA mandates a CBOM by name, but both frameworks require organisations to identify and manage risks to their information systems, including cryptographic controls. A CBOM provides the documented evidence that auditors and competent authorities expect when assessing whether an organisation has systematically inventoried and is actively remediating quantum-vulnerable assets.

What is the difference between a CBOM and a traditional SBOM?

A Software Bill of Materials lists software components and their dependencies. A CBOM goes one layer deeper: it enumerates the specific cryptographic algorithms, key lengths, certificate authorities and protocol versions used by each component. The CycloneDX CBOM schema extends the standard CycloneDX format to capture these cryptographic properties in a machine-readable structure.

Which tools can scan an existing on-premises environment to generate a first CBOM automatically?

IBM’s open-source cbomkit, scanners aligned to the CISA PQC Product Category List under EO 14306, and tools that consume TLS handshake data or binary analysis outputs can all produce an initial CBOM. These tools identify algorithm usage in libraries, firmware and network traffic without requiring line-by-line manual code review, making a first-pass inventory feasible within weeks for most environments.

What does the EU PQC Transition Roadmap require by 2026 and by 2030?

The European Commission Recommendation of 11 April 2024 calls on Member States to elaborate national post-quantum transition plans no later than the end of 2026. High-risk systems and critical infrastructure must complete migration to post-quantum cryptography by 2030. A CBOM is the prerequisite artefact for both milestones: without an inventory, an organisation cannot produce a credible transition plan or demonstrate progress against it.

How does a live CBOM support crypto-agility when a new NIST standard replaces an interim solution?

Crypto-agility means the ability to swap a cryptographic primitive without redesigning surrounding systems. A live CBOM maps every system and dependency to the specific algorithm it uses. When NIST finalises a replacement such as the move from a hybrid classical-PQC scheme to pure ML-KEM under FIPS 203, the CBOM immediately shows which systems are affected, allowing the security team to schedule targeted updates rather than conducting a new discovery exercise from scratch.