What a CBOM is
A cryptographic bill of materials is a machine-readable inventory of the cryptography in a system: the algorithms, the keys and certificates that use them, the protocols that negotiate them, and the components that implement them. It is to cryptography what an SBOM is to open-source dependencies — a list of what is actually inside, in a form a machine can compare against a policy.
The important word is actually. Most organizations can produce a policy that says AES-256 and TLS 1.3 are approved. Far fewer can produce a list of the algorithms running in production this week, including the ones introduced by a vendor SDK, a container base image, or a firmware blob.
Why it matters now
Two things changed the status of the CBOM from good practice to procurement artifact. First, post-quantum migration made the question urgent: you cannot sequence a multi-year migration against an inventory you do not have. Second, the federal government wrote it down.
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. When it lands, a CBOM becomes something a supplier is expected to hand over rather than something a security team builds for itself.
The planning consequence
What it contains
A useful CBOM answers seven questions about every cryptographic asset. If a field does not help answer one of them, it is probably noise.
| Group | Fields | Why it earns its place |
|---|---|---|
| Identity | bom-ref, name, owning service, environment | Makes the asset addressable and attributable. |
| Algorithm | Primitive, parameter set, mode, padding | Tells you exactly what is in use, not a family label. |
| Usage | Key establishment, signature, AEAD, hash | Determines which deadline applies. |
| Location | Library, module, service, host | Tells an engineer where to change it. |
| Lifecycle | Created, expires, rotation cadence | Surfaces expiry risk and migration windows. |
| Risk | Quantum-vulnerable, deprecation date, data lifespan | Turns inventory into a priority order. |
| Evidence | FIPS module, certificate, validation status | Supports procurement and audit claims. |
The risk group is where most first attempts are weakest. Knowing an asset uses RSA-2048 is an inventory fact. Knowing that it protects records with a fifteen-year retention requirement is what makes it urgent.
An illustrative excerpt
CycloneDX is the most widely implemented open schema, and version 1.6 added cryptographic asset types. The excerpt below is deliberately short — a real document has hundreds of entries and a version history.
{
"bomFormat": "CycloneDX",
"specVersion": "1.6",
"version": 12,
"components": [
{
"type": "cryptographic-asset",
"bom-ref": "svc:edge-tls",
"name": "edge-tls",
"cryptoProperties": {
"assetType": "protocol",
"protocolProperties": {
"type": "tls",
"version": "1.3",
"cipherSuites": [
{ "name": "TLS_AES_256_GCM_SHA384" }
]
}
}
},
{
"type": "cryptographic-asset",
"bom-ref": "key:payments-api/rsa-2048",
"name": "payments-api transport key",
"cryptoProperties": {
"assetType": "related-crypto-material",
"relatedCryptoMaterialProperties": {
"type": "private-key",
"algorithmRef": "alg:rsa-2048"
}
}
}
]
}Note what the excerpt does not show: the risk classification, the owner, and the data-lifespan tag. Those are the fields that turn a technical inventory into a decision tool, and they are usually carried as properties on the component or in a companion record.
How to build one
Building a CBOM is less about schema design than about coverage and ownership. Four steps, in order:
- Scope the estate, not the tool. Cloud accounts, data center, endpoints, build pipelines, and — if you have them — OT networks. Inherited cryptography is the point of the exercise.
- Normalize early. Decide on one schema on day one. A proprietary format makes the artifact impossible to exchange, which defeats the purpose.
- Assign an owner to every asset. An unowned finding is a finding nobody fixes. If ownership cannot be resolved, that is itself a finding for the governance workstream.
- Version and diff. A CBOM is only valuable as a series. The diff between two runs is what shows drift, progress, and regressions.
Five common mistakes
- Treating it as a one-time deliverable. A CBOM decays the moment a new service ships. It has to be regenerated on change, not annually.
- Listing only the cryptography you chose. The most dangerous entries are the ones a vendor chose for you.
- Skipping data lifespan. Without it, every asset looks equally urgent, which means nothing is prioritized.
- Building a private format. If an assessor or customer cannot parse it, it is not evidence.
- Publishing it without a plan. A CBOM makes gaps legible, including to people who can ask why they are still open. Pair it with a roadmap.
Sources and further reading