Cryptography Bill of Materials (CBOM): Why Every Encryption Ecosystem Needs One - and Fast

By Chuck Brooks and Georgianna Shea

We’ve learned the hard way that knowing what’s in your software supply chain matters. The Software Bill of Materials (SBOM) progressed from a niche best practice to government regulation  codified under Executive Order 14028)  and an operational necessity because it gives enterprises the visibility they need to discover, evaluate, and remediate risk before an exploit becomes a catastrophe.

Today, SBOMs are embedded in procurement expectations, federal acquisition language, and emerging regulatory practice. Hardware Bills of Materials (HBOMs) are increasingly referenced in supply chain risk management for critical infrastructure and defense systems. Both are moving toward structured formats, interoperability standards, and compliance reporting.

Cryptography now sits in the same position that software components occupied five years ago. SBOMs gained urgency when it became clear that unknown dependencies were the attack surface; the Log4Shell vulnerability in late 2021 exposed how invisible components could cascade into enterprise-wide exposure. 

Cryptography faces an analogous reckoning: algorithms and keys embedded invisibly across systems, with no inventory, no ownership, and no migration plan. The difference is that the cryptographic threat horizon , quantum-capable adversaries, are less forgiving than a software patch cycle. You cannot hot-fix a compromised algorithm after Q-Day arrives.

Enterprises must inventory and manage their cryptographic assets with the same rigor applied to code, hardware, and data. Enter the Cryptography Bill of Materials (CBOM): an organized inventory of every cryptographic algorithm, implementation, key, certificate, random-number generator, and crypto-service provider utilized across an organization's systems.

In many enterprises, cryptographic usage is fragmented, undocumented, and operationally opaque. When boards are told that systems are "encrypted," that statement is often directionally true but operationally shallow. Encrypted with what? Where? For how long? Managed by whom? Rotated how? Replaced when?

Unlike SBOMs and HBOMs, CBOMs currently carry no formal regulatory requirement, no mandated schema, no federal minimum data elements, no standard reporting format. That absence should not be mistaken for irrelevance. It creates space for enterprises to act ahead of mandate rather than scramble to comply after one.

A CBOM can stand alone as an operational risk-management instrument, or augment existing SBOM and HBOM practices, extending component transparency into the trust layer those components rely on. SBOMs tell you what software is present. HBOMs tell you what hardware is embedded. A CBOM tells you what assumptions secure both.

If SBOMs map the parts, CBOMs map the trust.

Why CBOMs Are Urgent Now: AI and Quantum Are Changing the Calculus

Two concurrent developments raise the stakes for cryptographic visibility.

First, artificial intelligence is transforming both  offense and defense. AI-driven tools accelerate code discovery, automate vulnerability research, and can rapidly detect weak or misconfigured cryptographic primitives across complex environments. That capability is available to adversaries as much as defenders  making the ability to swiftly discover and characterize your own cryptographic assets essential before someone else does it for you.

Second, quantum computing is no longer theoretical. The prospect of cryptanalytically relevant quantum computers and what practitioners call "Q-Day" forces organizations to plan migration strategies now. Widely used public-key algorithms (RSA, ECC) are vulnerable to future quantum attacks, and long-lived data encrypted today could be decrypted later under a harvest-now, decrypt-later strategy: adversaries collect ciphertext today and break it when quantum capability matures. The timeline remains uncertain. The risk does not.

Without a CBOM, migration planning becomes guesswork. Leaders cannot answer basic operational questions:

• Which systems depend on quantum-vulnerable public-key algorithms?
• Which keys or certificates are long-lived?
• Which data sets require confidentiality for decades?
• Which implementations are embedded in hardware or vendor firmware and cannot be easily replaced?

Inventory does not solve the problem. It makes the problem measurable, and measurable problems can be prioritized, resourced, and tracked to resolution.

What a Useful CBOM Contains

A well-constructed CBOM is more than a checklist. It is a machine-readable, continuously updated data model that relates cryptographic objects to system ownership, risk classification, and lifecycle metadata. At minimum it should capture:

• Algorithm and implementation provenance: Library or provider (OpenSSL 3.x, BoringSSL, a TPM vendor), including version and build provenance.
• Key and certificate inventory: Key IDs, type (symmetric/asymmetric), key length, creation date, rotation schedule, owner/contact, storage location (HSM, TPM, software keystore), and certificate chain data.
• Entropy and randomness sources: Source of entropy (OS CSPRNG, hardware TRNG, vendor RNG) and attestation evidence where available.
• Usage context: Which devices, services, APIs, or data flows depend on the primitive; expected data longevity; and exposure profile (internet-facing, internal, offline backup).
• Risk overlay: Migration priority derived from data longevity, regulatory obligations, and national security relevance. This classification is a governance determination layered on top of technical facts - not an intrinsic property of the algorithm itself.
• Third-party crypto services: Cloud KMS providers, HSM vendors, certificate authorities, and any external crypto-as-a-service suppliers, with contract terms, SLAs, and contact points.

Tooling to generate CBOMs is maturing. Open-source options such as the CycloneDX CBOM schema and GitHub-integrated scanners can extract cryptographic metadata from builds, containers, firmware, and infrastructure-as-code templates. For a CBOM to become a regular operational artifact rather than a one-time audit exercise, generation should be integrated into CI/CD pipelines and asset-management systems from the outset.

How CBOMs Support Quantum-Resistant Migration

A CBOM answers the most critical questions for migration planning: where are vulnerable algorithms deployed, how long will the protected data remain sensitive, which keys and certificates are long-lived, and which implementations are difficult or risky to replace?

With that foundation, organizations can apply structured migration practices:

• Prioritize high-value, long-lived data first: Government and classified material, intellectual property, archival records, and internet-facing authentication services warrant immediate attention.
• Begin substitute testing early: NIST finalized its first post-quantum cryptography standards in 2024 (ML-KEM, ML-DSA, SLH-DSA). Identify which systems can begin parallel or hybrid adoption in low-risk environments now, before migration becomes mandatory.
• Protect the key lifecycle: Ensure keys are generated and stored in tamper-resistant hardware (HSMs/TPMs), with documented entropy provenance — details a CBOM records and auditors can verify.
• Monitor and rotate aggressively: A CBOM enables programmatic identification of keys and certificates nearing expiry or stored insecurely, so rotation happens before they become operational liabilities.

Operationalizing a CBOM: Governance and Tooling

CBOM success requires governance alignment, automation, and integration and not just a one-time inventory exercise.

• Governance: Make cryptographic inventory a cross-functional responsibility spanning security engineering, DevOps, legal/compliance, and procurement. Cryptography is a strategic risk — one that boards and CISOs must own, not delegate entirely to engineering teams.
• Automation: Deploy scanners that identify cryptographic usage in binaries, containers, firmware, and IaC templates. Integrate CBOM generation into CI/CD and asset-management workflows so the inventory stays current rather than stale.
• Integration: Link the CBOM to risk scoring, incident response, and vulnerability management systems so that cryptographic weaknesses receive the same triage priority as other exploitable vulnerabilities.
• Third-party accountability: Require suppliers to provide CBOM data or signed attestations for embedded devices, SaaS platforms, and managed services - mirroring how government agencies and major enterprises increasingly demand SBOMs from vendors.

Final Thought: Inventory Is the Foundation of Resilience

We cannot protect what we cannot see. SBOMs demonstrated that transparency into components turns unknown unknowns into manageable risk. In an era where AI accelerates adversary reconnaissance and quantum computing undermines the foundational assumptions of public-key security, a Cryptography Bill of Materials is an operational requirement - not a checkbox.

It gives executives the inventory, context, and programmatic control needed to prioritize migrations, harden implementations, and maintain confidence as the threat landscape shifts beneath them.

To begin: scope a CBOM for your highest-risk services today. Catalog algorithms, key stores, certificates, and RNG provenance. Feed that data into your risk and patching pipelines. Incorporate CBOM generation into your build and procurement workflows. The migration clock is already running and gaining visibility is how you get ahead of it.

Selected Sources & Further Reading

• NIST, Post-Quantum Cryptography Standardization (FIPS 203, 204, 205), 2024.
• CISA / NSA / NIST, Quantum-Readiness: Migration to Post-Quantum Cryptography, 2023.
• CycloneDX, CBOM (Cryptography Bill of Materials) Specification, OWASP.
• Chuck Brooks, SBOMs (as well as HBOMs and CBOMs) as Cybersecurity Facilitators, Forbes.
• Chuck Brooks, SBOMs, HBOMs, and CBOMs - The New Foundation of Cyber Resilience, CyBeats.