What is a CBOM, and why did regulators start asking for it?
A CBOM inventories the cryptographic assets in your software the way an SBOM inventories components: algorithms, key sizes, certificates, and protocol configurations, with evidence of where each lives. Regulators and standards bodies started asking for it because post-quantum migration and crypto-hygiene enforcement are impossible without it.
Every security team can tell you which version of a web framework they run. Almost none can tell you every place their software uses RSA, what key sizes, and in which files. The CBOM exists to close that gap.
The definition
A CBOM, a cryptography bill of materials, is a machine-readable inventory of the cryptographic assets in a piece of software or a system. Where an SBOM lists components and versions, a CBOM lists:
- Algorithms in use: which primitives, modes, and key sizes, and where they are invoked.
- Certificates and keys: X.509 certificates, keystores, SSH keys, their parameters and expiry, never the key material itself.
- Protocol configurations: TLS versions and cipher suites as configured across servers and services.
- Provenance and evidence: where each asset was found and how, so the inventory can be audited rather than believed.
Modern SBOM formats have grown first-class support for this: CycloneDX carries cryptographic properties natively, which means CBOMs travel through the same tooling pipelines as SBOMs.
Why regulators care
Three forces converged to make cryptographic inventory a compliance topic rather than an engineering nicety.
Post-quantum migration is a national project. Government timelines such as the NSA’s CNSA 2.0 set concrete deadlines for moving to quantum-resistant algorithms. You cannot migrate what you cannot enumerate, so inventory is the mandated first step, and that expectation is flowing outward from national security into regulated industry.
Crypto hygiene keeps failing in audits. Expired certificates, deprecated protocols, and weak legacy algorithms cause enough incidents that supervisors want the inventory question answered continuously, not rediscovered during each audit.
BOM thinking proved itself. Once SBOMs demonstrated that machine-readable inventories change what regulators can ask for, extending the model to cryptography was inevitable. India’s CERT-In technical guidelines, for example, describe bills of materials well beyond software alone, cryptography included, and sector frameworks reference them.
What a good CBOM requires
The difference between a useful CBOM and a checkbox one comes down to three properties.
Generated from artifacts, not from memory. The dangerous cryptography is the kind nobody remembers: the algorithm choice inside a vendored library, the config file from a previous ops team, the constant baked into a binary. A real CBOM is produced by analyzing source code, configuration, certificates, and compiled binaries.
Honest about what it could not resolve. Some algorithm choices are made at runtime or hidden in stripped binaries. A trustworthy inventory declares these as known-unknowns instead of silently omitting them. Auditors respond very differently to declared uncertainty than to discovered omission.
Continuously regenerated. Cryptography changes with every dependency bump and infrastructure change. A CBOM produced once for an audit is stale before the report is filed. Generation belongs in the build pipeline, alongside the SBOM.
The QBOM layer
Once a CBOM exists, a quantum-readiness classification can be computed over it: every asset marked quantum-vulnerable or quantum-safe against current NIST standards, aggregated into a posture number an executive can track. Some frameworks call this derived view a QBOM. It is the artifact that turns post-quantum migration from a slogan into a burn-down chart.
Where to start
If your organization has never produced a CBOM, the first one is revealing in the way first SBOMs were five years ago: expect surprises in the certificate estate and the legacy corners. BOMNexa generates CBOMs from real artifacts, classifies every asset for quantum readiness, and declares its known-unknowns, entirely inside your network. The first run on a real codebase takes minutes, and it is usually the most informative security report of the quarter.