CBOM : what a cryptographic bill of materials is, and why you will be asked for one

A cryptographic bill of materials (CBOM) is a structured inventory of every cryptographic asset a system depends on: certificates, keys, algorithms, protocols, libraries, and the relationships between them. It does for cryptography what a software bill of materials (SBOM) did for open-source components. And for the same reason, regulators, auditors and customers are starting to ask for it.

This article explains what a CBOM contains, which standard defines it, who is going to ask you for one and when, and how to produce it without starting a new inventory project.

What is a cryptographic bill of materials?

A CBOM is a machine-readable document that lists the cryptographic assets in a defined scope and how they connect. The scope can be one application, one product you ship, or an entire estate. Where a certificate inventory answers "what certificates do we have", a CBOM answers a harder question: "what cryptography does this system rely on, and what breaks if one piece of it is no longer acceptable?"

The term was formalised by IBM Research in 2023 and adopted into the OWASP CycloneDX specification the same year. Since then it has moved from a research idea to a line item in procurement questionnaires and regulatory guidance.

Three properties separate a real CBOM from a spreadsheet export:

• It is structured. Each asset has a type, properties and identifiers, in a schema a machine can validate.

• It records dependencies. A TLS endpoint depends on a certificate, which depends on a key, which lives in an HSM, which uses a specific algorithm. The graph is the point.

• It is dated and scoped. A CBOM describes a system at a moment in time, for a declared perimeter. It can be regenerated and compared.

What a CBOM contains

CycloneDX defines a cryptographic-asset component type with four sub-types. In practice a complete CBOM covers the following.

Around those assets, a useful CBOM also records the providers (OpenSSL 3.x, BouncyCastle, an HSM firmware version), the consumers (the application, container or workflow that uses each asset), and the dependency edges between them. Without the edges you have an inventory. With them you have a bill of materials.

The CycloneDX standard, and what is still moving

CycloneDX 1.6, published by OWASP in 2024, is the reference format. It added cryptographic assets as a first-class component type, with JSON and XML serialisations and a published schema. Most tooling that claims CBOM support today means "CycloneDX 1.6 output".

What is settled

• The four asset types above and their property sets.

• Dependency modelling between crypto assets and the software components that use them.

• Algorithm identifiers based on IANA and NIST names, plus a nistQuantumSecurityLevel field for post-quantum classification.

What is still in progress

• Regulatory references. NIS2 implementing acts and DORA technical standards ask for cryptographic inventories and policies but do not yet name CycloneDX. Expect the format to be referenced by guidance rather than mandated by law in the near term.

• Interoperability. SPDX 3.0 is adding cryptographic profiles. Both formats will coexist for a while, as they did for SBOM.

• Attestation. Who signs a CBOM, and how a recipient verifies it, is being worked out. Today a signed export from a governed inventory is the practical answer.

The takeaway: the format is stable enough to adopt now. What will change is who demands it and in which procedure, not what it looks like.

Who is going to ask you for a CBOM, and when

Four groups, on four different timelines.

1. Regulators and auditors

NIS2 (in force since October 2024) requires essential and important entities to have a documented cryptography policy and to demonstrate control over the cryptography they use. DORA (applying since January 2025) goes further for financial entities: Article 6 and the RTS on ICT risk management ask for an inventory of cryptographic controls, reviewed and kept current. PCI-DSS 4.0 requirement 12.3.3, mandatory since March 2025, is the most explicit: a documented, reviewed inventory of all cryptographic cipher suites and protocols in use.

None of these texts say "CBOM". All of them describe one. An auditor who has seen the term will ask for it by name; one who has not will ask for the same thing in three separate questions.

2. Your customers' procurement teams

If you ship software or a connected product, expect the CBOM request to arrive the same way SBOM requests did: a line in a security questionnaire, then a contractual clause. US federal buyers already require SBOMs under Executive Order 14028; cryptographic inventories follow from the same memo's post-quantum provisions (OMB M-23-02). EU buyers under the Cyber Resilience Act will have a comparable lever from 2027.

3. Your own post-quantum migration

The migration to post-quantum cryptography cannot be planned without knowing where RSA and ECC sit today and what depends on them. ANSSI, BSI and NIST all recommend a cryptographic inventory as step one. The CBOM is that inventory in a form you can diff every quarter to show progress against the 2030 to 2035 horizon.

4. Incident response

When an algorithm is broken, a CA is compromised or a library CVE lands, the first question is "where do we use it?" Teams with a CBOM answer in minutes. Teams without one start a discovery project under pressure. Heartbleed and the SHA-1 deprecation were both dress rehearsals for this.

In short, a CBOM is the document every crypto-related regulation describes without naming. Producing one on demand is cheaper than producing three partial answers under audit.

CBOM vs SBOM vs certificate inventory

The three are often confused. They overlap, but each answers a different question.

A certificate inventory is a subset of a CBOM. An SBOM is a sibling: the two can be emitted in the same CycloneDX document, and a mature pipeline does exactly that.

How to generate a CBOM from your existing inventory

The common mistake is to treat the CBOM as a new discovery project. It is not. Most organisations already hold 80% of the data across five or six tools. The work is collection, merging and export, not discovery.

Step 1. Declare the scope

A CBOM without a declared perimeter cannot be audited. Start with one business system or one product, name what is in and out, and record it. Blind spots you declare are evidence. Blind spots you hide are findings.

Step 2. Pull from the sources you already run

Each source covers part of the picture. Together they cover most of it.

Step 3. Merge into one record per asset

The same certificate will appear in the CLM, on three hosts in the scanner, and in the CMDB under two names. A CBOM needs one record with every sighting attached, not four rows. This deduplication step is where most manual attempts stall, and where tooling pays for itself.

Step 4. Add the dependency edges

Link each key to its certificate, each certificate to the endpoints that serve it, each endpoint to the application and business service it supports, and each algorithm to everything that uses it. This is what lets you answer "what breaks if we retire RSA-2048 here" before you do it.

Step 5. Grade and classify

Tag every algorithm with its status against your policy and against the references you are held to: ANSSI RGS, NIST SP 800-131A, the PQC classification. A CBOM that carries the grading is immediately useful to an auditor. One that does not hands them homework.

Step 6. Export in CycloneDX 1.6, signed and dated

Emit JSON, validate against the schema, sign it, archive it. Regenerate on a schedule so that the next request is an export, not a project. A minimal component entry looks like this:

{
  "type": "cryptographic-asset",
  "name": "RSA-2048",
  "bom-ref": "crypto/algorithm/rsa-2048",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "pke",
      "parameterSetIdentifier": "2048",
      "nistQuantumSecurityLevel": 0,
      "cryptoFunctions": ["keygen", "encrypt", "decrypt", "sign", "verify"]
    },
    "oid": "1.2.840.113549.1.1.1"
  }
}

Dependencies are declared separately, referencing the bom-ref values, so the graph travels with the document.

Five mistakes that make a CBOM useless to an auditor

1. No declared scope. "Everything we found" is not a perimeter. State what was in scope and what was not.

2. A one-off snapshot. A CBOM from eighteen months ago proves what you knew then. Regulators expect it kept current.

3. Assets without owners. A finding with no owner cannot be remediated. Attach an owner to every consumer.

4. No grading. Listing SHA-1 without saying it fails your policy shifts the analysis onto the reader.

5. Dropping what cannot be classified. Unknown algorithms and unreachable systems belong in the document, marked as unresolved. Silence looks like concealment.

Where Evertrust CPM fits

Evertrust CPM produces the CBOM as a by-product of what it already does: it reads the sources above through read-only connectors, merges duplicates into one governed record per asset, maps dependencies from key to application, grades every asset against your policy and the frameworks you are held to, and exports signed, dated reports per framework. The CycloneDX export is one of those reports.

The difference from a discovery tool is what comes after the list: ranking what to fix first, routing it to the team that owns the asset, verifying the fix is live, and keeping every past export so "what did you declare last year" has a two-click answer.