What is a CBOM? The CycloneDX 1.6 Cryptographic Bill of Materials, explained

A practical guide — with a concrete example — for security and GRC teams.

You almost certainly know what an SBOM is: a software bill of materials listing the components and dependencies in an application. A CBOM — Cryptographic Bill of Materials — does the same thing for cryptography. It is a structured, machine-readable inventory of every cryptographic asset in a system: algorithms, keys, certificates, and the protocols that use them.

Why a dedicated standard for cryptography?

Cryptography is uniquely fragile to change. A single weak hash (MD5, SHA-1) or a quantum-vulnerable signature (RSA, ECDSA) can undermine an entire trust chain — and it is rarely visible from a normal SBOM. The CycloneDX project answered this with a first-class cryptographic asset model, stabilised in CycloneDX 1.6. It lets you express cryptography as proper components with their own properties, rather than burying it in free text.

What a CBOM captures

• Algorithm — family, primitive (e.g. RSA, ECDSA, AES, SHA-2), mode and padding.
• Key material — size, curve, and intended use.
• Certificates — issuer, validity, signature algorithm.
• Protocols — e.g. the cipher suites negotiated on a live TLS endpoint.
• Provenance — the file, line or endpoint where each asset was found.

A concrete (simplified) example

Here is what a single quantum-vulnerable RSA key looks like as a CycloneDX 1.6 crypto component:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "name": "rsa-2048",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "pke",
          "parameterSetIdentifier": "2048",
          "executionEnvironment": "software-plain-ram",
          "cryptoFunctions": ["keygen", "sign", "verify"],
          "nistQuantumSecurityLevel": 0
        }
      }
    }
  ]
}

Note nistQuantumSecurityLevel: 0 — that is the machine-readable flag a GRC tool needs to say “this is not quantum-safe.” Multiply this across thousands of assets and you have an inventory you can query, score and report on.

Because the CBOM is an open standard, your inventory and your evidence outlive any single tool or vendor.

Where the CBOM fits

A CBOM is the foundation for everything downstream: quantum-risk scoring, harvest-now-decrypt-later exposure analysis, and a prioritised migration roadmap to the post-quantum standards (FIPS 203/204/205). It is also the artefact auditors and regulators increasingly expect under DORA, NIS2 and the EU Cyber Resilience Act.

How do you generate one?

You do not write a CBOM by hand. The practical path is automated discovery: scan your code, parse your certificates, handshake your TLS endpoints, then export a validated CycloneDX 1.6 CBOM. That is exactly what CRYPTAGION produces — alongside a board-ready PDF and a migration roadmap.

← All resources · Home