What is a CBOM?
A CBOM — cryptographic bill of materials — is a machine-readable list of the cryptography your systems use: the algorithms and their parameters, keys, certificates and protocols, and which component uses each. It is the inventory a post-quantum migration starts from, and the standard format for it is CycloneDX 1.6.
Checked against the sources on 27 October 2026.
What goes in one
- Algorithms, with the detail that decides whether they are safe: RSA-2048 or RSA-4096, P-256 or ML-DSA-65, AES-128 or AES-256, SHA-1 or SHA-384.
- Keys — their type, size and where they live.
- Certificates — subject, issuer, signature algorithm, validity.
- Protocols — TLS and SSH versions and the cipher suites actually in use.
- Relationships — which application, library or device uses or implements each of the above. This is what turns a list into a migration plan: it says what has to change for RSA to go.
The format: CycloneDX 1.6
OWASP added the CBOM to CycloneDX in version 1.6, released in April 2024, from work contributed by IBM Research. It describes cryptographic assets as components in their own right, with dependency links saying which software uses or implements them. Because it is the same format family as a software bill of materials, a CBOM can sit in the same document as an SBOM, or alongside it, and the same tools can read both.
CBOM and SBOM
An SBOM lists the software components in a product — packages and versions. A CBOM lists the cryptography. The two overlap (a library version tells you which algorithms it supports), but an SBOM alone cannot tell you that a service was configured to negotiate TLS 1.0, or that a developer generated a 1024-bit RSA key in your own code.
Why you are being asked for one
OMB M-26-15, the June 2026 memorandum directing US federal agencies' post-quantum migration, makes an automated, continuously updated cryptographic inventory the foundation of every agency plan. It names the tools — software composition analysis of SBOMs, static and dynamic code analysis, and network scanners — and says their data should populate a central CBOM giving a real-time view of the agency's cryptographic posture. Outside government the reason is the same: it answers the first question of any migration — where is the RSA?
How to build one
No single tool sees all of it. Each source finds what the others miss:
| Source | Finds | Cannot see |
|---|---|---|
| Source code | The cryptographic calls your developers wrote, with file and line | How the software is configured once deployed |
| Dependencies (SBOM) | Libraries and versions, and which have no post-quantum release | Which of a library's algorithms are actually used |
| Network | What servers and devices actually negotiate, and the certificates they present | Code that has not shipped yet, and traffic it never observed |
What makes a CBOM trustworthy
- It says what it did not examine. A clean result from a scan that could not read half your languages is not a clean estate. A useful CBOM states its coverage.
- It does not hide accepted risk. A waived finding is still cryptography in use; leaving it out makes the inventory flatter than reality.
- It is current. A one-off inventory starts going stale with the next deployment. Build it from tools that run continuously.
Next: a post-quantum migration roadmap, which starts from this inventory.