What a cryptographic bill of materials actually contains

An SBOM tells you that a container image contains OpenSSL 3.0.8. It does not tell you that the service terminates TLS with an RSA-2048 key, accepts RSA key transport from clients, signs its audit log with ECDSA P-256, and verifies a vendor firmware blob with SHA-256. Those are four migration problems with four different deadlines, and only one of them is a dependency question.

That is the gap a cryptographic bill of materials closes. An SBOM answers “what is inside this artifact.” A CBOM answers “what cryptography is protecting this data, where does the key live, and when does it expire.”

A CBOM is an inventory of cryptographic assets, not a dependency list

Question	SBOM	CBOM
Which libraries are in this artifact?	Yes	Partially
Which algorithm protects this interface?	Rarely	Yes
Where is the private key stored?	No	Yes
When does this certificate expire?	No	Yes
Is this asset quantum-vulnerable?	No	Yes
Who owns it?	Sometimes	Only if you fill it in

The formats reflect that difference. CycloneDX 1.6 added a cryptographic-asset component type with a cryptoProperties object, whose assetType is one of algorithm, certificate, protocol, or related-crypto-material. That last value is the one teams skip. It covers keys, keystores, and secrets, which is where most of the operational risk sits.

The seven field groups worth insisting on

A CBOM that records only algorithm names is a list. Seven groups make it an inventory you can act on.

Group	Question it answers	Typical content
Identity	What is this and who owns it?	Asset ID, system, environment, owner, bom-ref
Algorithm	What primitive and parameters?	ML-KEM-768, RSA-2048, ECDSA P-256, SHA-256
Usage	What is it doing here?	Key establishment, signature, MAC, KDF, encryption
Location	Where does it live?	Library, service, endpoint, config path, key store
Lifecycle	When does it change?	Created, not-before, not-after, rotation interval
Risk	Why do you care?	Quantum-vulnerable, data lifespan, exposure band
Evidence	How do you know?	Scanner, config excerpt, attestation, timestamp

Two of these are load-bearing. Risk without data lifespan is just a flag: RSA-2048 protecting a ninety-day session log and RSA-2048 protecting thirty-year mortgage records are not the same problem, and a CBOM that scores them equally produces a migration plan nobody trusts. Evidence is what makes the inventory auditable, because a record that cites its scanner and timestamp can survive a review while a hand-edited spreadsheet cannot.

What a record looks like

The excerpt below is illustrative, not normative. CycloneDX field names evolve between versions, so validate anything you emit against the spec version you claim.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [
    {
      "type": "cryptographic-asset",
      "bom-ref": "crypto/edge-tls/key-establishment",
      "name": "edge-tls-key-establishment",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "kem",
          "parameterSetIdentifier": "ML-KEM-768",
          "executionEnvironment": "software-plain-ram",
          "implementationPlatform": "x86_64",
          "certificationLevel": ["none"],
          "cryptoFunctions": ["encapsulate", "decapsulate"]
        }
      }
    }
  ]
}

Note what the record does not contain: an owner, a data classification, or a rotation date. Those come from your configuration management database and your data catalogue, joined on the asset reference. A CBOM is not a system of record for ownership. It is the join key that makes ownership queryable.

The 270-day clock turns this into a procurement artifact

Executive Order 14412, signed June 22, 2026, directs CISA, with NIST, to publish public guidance on the minimum elements of a cryptographic bill of materials within 270 days. That puts the guidance around March 2027.

Until then you are designing; after that you are conforming. The difference in cost is large. A team that has been emitting CycloneDX for a year maps new guidance onto an existing pipeline. A team that starts in March 2027 builds the pipeline, negotiates the schema, and explains the gap to an auditor in the same quarter.

There is a second-order effect worth planning for. Once minimum elements exist, a CBOM becomes something you can request from a supplier. Expect it in security questionnaires, in contract exhibits, and eventually in the FAR flow that Executive Order 14412 sets in motion for covered contractors by December 31, 2030.

Five mistakes that make a CBOM useless

Treating it as a one-off artifact. A CBOM produced by a consulting engagement and delivered as a PDF is a snapshot. Cryptography changes with every deploy, every base image rebuild, and every certificate renewal. Generate it in the pipeline, or accept that it is wrong within a quarter.

Recording only the crypto you chose. Most quantum-vulnerable cryptography is inherited: a transitive dependency, a vendor appliance’s management interface, a Java keystore nobody has opened, a firmware blob inside a device. If your CBOM covers only the ciphers your team configured, it covers the part of the estate you already understood.

Omitting data lifespan. Without a retention or confidentiality requirement attached, every finding looks equally urgent and prioritization collapses into whoever escalated loudest.

Inventing a private format. A bespoke JSON schema that no scanner emits and no auditor reads costs the same to build and delivers none of the interoperability. Extend CycloneDX. Do not fork it.

Publishing without a plan. A complete CBOM is an attacker’s map: versions, endpoints, key store locations, expiry dates. Decide the audience, the distribution path, and the retention period before the first external share, and treat the internal copy as sensitive by default.

Start with one system, then make it continuous

Pick the system with the worst combination of confidentiality lifespan and network reachability. Produce a CBOM for it in a standard format, wire generation into its build, and attach owners and data classifications to the records you find.

Then expand by inheritance rather than ambition. The second system is usually easier because the schema and the join keys already exist. Two systems covered continuously beat an estate-wide survey that is stale before it is finished.

The test of a CBOM is not whether it is complete. It is whether a different engineer, six months from now, can open it and answer which algorithm protects which interface without asking you.