Cryptographic Bill of Materials (CBOM): The Key to secure your Software Supply Chain

Quick answer: A Cryptographic Bill of Materials (CBOM) is a structured inventory of every algorithm, key, certificate, protocol, and cryptographic library your software and infrastructure use, built on the OWASP CycloneDX standard. It matters because you cannot migrate off quantum-vulnerable cryptography or prove compliance without knowing where it lives. Start by scanning your code, certificates, and runtime environments to build a baseline.

Supply chain attacks are diverse, and they hit corporate organizations and government entities alike. Commercial software and open-source packages are both targets, which makes clear visibility into every software and cryptographic asset across your development and deployment pipelines a baseline requirement, not a nice-to-have. 

In 2020, the SolarWinds supply chain attack compromised thousands of organizations and multiple U.S. government agencies after attackers injected a backdoor known as SUNBURST into the Orion IT update tool. In February 2021, security researcher Alex Birsan breached Microsoft, Tesla, Uber, and Apple using a technique called dependency confusion, tricking internal build systems into pulling malicious public packages instead of trusted internal ones. 

In response, the U.S. government issued Executive Order 14028, “Improving the Nation’s Cybersecurity,” in May 2021, requiring software vendors selling to federal agencies to provide a Software Bill of Materials (SBOM). An SBOM is a machine-readable list of every module, library, and third-party dependency in a piece of software, along with metadata like license and version, so a defender can quickly identify and patch components affected by a supply chain attack. 

NIST subsequently recommended extending SBOM practice with a Cryptography Bill of Materials (CBOM) as part of its guidance for post-quantum cryptography (PQC) migration, most notably in the National Institute of Standards and Technology (NIST) National Cybersecurity Center of Excellence’s SP 1800-38 practice guide. That recommendation has since been formalized: CBOM is now a native part of the OWASP CycloneDX Bill of Materials standard, which added cryptographic asset support in version 1.6 and is published as the ECMA-424 standard.

Key Takeaways

• A CBOM is a structured inventory of algorithms, keys, certificates, protocols, and cryptographic libraries, standardized under OWASP CycloneDX (now published as ECMA-424).
• Unlike an SBOM, which lists software components, a CBOM lists the cryptography those components actually use, making it the starting point for post-quantum migration planning.
• NIST’s draft IR 8547 timeline proposes deprecating RSA, ECDSA, ECDH, and finite-field Diffie-Hellman after 2030 and disallowing them after 2035, a timeline now backed for federal systems by Executive Order 14412 and OMB Memorandum M-26-15.
• A complete CBOM program goes beyond a one-time scan: it classifies assets by risk, applies access controls to keys, governs the cryptographic lifecycle, and maps findings to compliance frameworks like PCI DSS and GDPR.
• CBOM tooling has real limitations, including blind spots for configuration-driven cryptography and legacy binaries, so treat it as a continuous practice rather than a single audit.

What Is a Cryptographic Bill of Materials (CBOM)? 

A Cryptographic Bill of Materials (CBOM) is a machine-readable inventory that catalogs every cryptographic asset in a system: algorithms and their parameters (key sizes, modes), keys, digital certificates, cryptographic libraries, and the protocols that use them. CBOM is formalized as an extension of the OWASP CycloneDX standard, the same full-stack Bill of Materials format used for SBOM, SaaSBOM, and hardware BOM. Where an SBOM tells you which software components and versions you run, a CBOM tells you which cryptography those components actually use, information an SBOM alone does not capture.

CBOM vs. SBOM: What’s the Difference?

An SBOM inventories software components: libraries, dependencies, and their versions and licenses. A CBOM inventories the cryptography inside and around those components. The two are complementary, and NIST’s own PQC migration guidance treats CBOM as an extension of SBOM practice rather than a replacement for it.

Aspect	SBOM	CBOM
Tracks	Software components, versions, licenses	Algorithms, key sizes, certificates, protocols
Primary driver	Executive Order 14028 (2021), supply chain risk	Post-quantum migration, NIST PQC guidance
Standard format	CycloneDX, SPDX	CycloneDX cryptography extension (ECMA-424)
Answers	“What software am I running?”	“What cryptography is that software using, and is it quantum-safe?”

What Should a CBOM Inventory Include? 

A complete CBOM augments a standard SBOM inventory (operating system, web/application servers, SSL/TLS libraries such as OpenSSL, configuration, and log management tools) with the specific cryptographic detail those components rely on. In practice, that means capturing six categories of asset.

Category	Examples	Why it matters
Algorithms	RSA, ECDSA, AES, SHA-2/SHA-3	Identifies which algorithms are quantum-vulnerable versus quantum-safe
Keys	Key size, type, storage location	Flags undersized or improperly stored key material
Certificates	X.509 certificates, expiry dates	Surfaces expiring or weakly-signed certificates before they cause an outage
Protocols	TLS/SSL versions, SSH, VPN configurations	Reveals deprecated protocol versions still in production
Libraries and modules	OpenSSL, BoringSSL, language-native crypto libraries	Ties known CVEs directly to the systems that use them
Hardware	HSMs, IoT and embedded devices	Extends visibility past software into the hardware that anchors trust

Building a Cryptographic Governance Framework Around Your CBOM

A CBOM is only as useful as the governance program built on top of it. Once you can see every algorithm, key, and certificate in your environment, the next step is deciding what to do about each one: how to classify it, whether to encrypt or tokenize the data behind it, who can access it, how its lifecycle is managed, how you recover if it fails, how you monitor it going forward, and how it maps to the compliance frameworks you answer to.

Classify Cryptographic Assets by Risk

Not every entry in a CBOM carries the same urgency. Classification means scoring each algorithm and key against its quantum-vulnerability status and the sensitivity or retention period of the data it protects, so you can prioritize migration instead of treating a 5,000-line inventory as a flat to-do list.

Algorithm or key type	NIST IR 8547 draft status	Recommended action
RSA-2048, ECC P-256 (~112-bit security)	Proposed deprecated after 2030	Plan migration now; prioritize data with a long confidentiality lifetime
RSA-3072, ECC P-384 (higher-strength variants)	Proposed disallowed after 2035	Migrate before 2035; higher key sizes buy time, not exemption
ML-KEM (FIPS 203), ML-DSA (FIPS 204), SLH-DSA (FIPS 205)	Finalized NIST standards, August 2024	Target algorithms for new deployments and migration
AES-256, SHA-2, SHA-3	Not on IR 8547’s public-key deprecation schedule	No forced migration; keep verifying key management practices

NIST IR 8547 remains an initial public draft as of mid-2026, so treat these dates as the direction of travel rather than a finalized rule. That said, Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” signed June 22, 2026, and OMB Memorandum M-26-15, issued June 24, 2026, already convert IR 8547’s 2030 horizon into a binding five-phase migration timeline for federal high-value assets and high-impact systems, with agency migration plans due in October 2026. The order even defines a new “PQC migration lead” role explicitly responsible for agency-wide cryptographic inventory management, which is exactly what a CBOM exists to support.

Choose Between Encryption and Tokenization

Your CBOM tells you where sensitive data intersects a given algorithm, which is exactly the information you need to choose the right control. Use encryption when the application needs to recover the original value or when data moves across systems you do not fully control. Use tokenization when you want to remove sensitive values (payment card numbers are the classic case) from a system entirely and reduce that system’s compliance scope, since a token has no mathematical relationship to the original value and cannot be reversed without the separate vault that issued it.

Enforce Access Controls on Keys and Certificates

Every key and certificate your CBOM surfaces needs an owner and an access policy. That means role separation between the people who request keys and the people who approve or issue them, storage in a hardware security module rather than flat files or source code, and scheduled credential rotation instead of keys that live unchanged for years. A CBOM without access governance just documents the problem; it does not fix it.

Govern the Cryptographic Asset Lifecycle

Each entry in a CBOM moves through a lifecycle: issuance, rotation, renewal, revocation, and retirement. Governance means defining who triggers each stage and how it’s recorded, so an expiring certificate or an algorithm slated for deprecation gets scheduled work instead of showing up as an outage.

Plan Recovery Before You Need It

A CBOM identifies which keys and certificate authorities are load-bearing for your business, which is precisely the list you need for disaster recovery planning. That means key escrow and backup procedures for encryption keys, a documented recovery path for a compromised or unavailable certificate authority, and periodic recovery testing, not just a backup that has never been restored.

Monitor Continuously, Not Just at Audit Time

A CBOM generated once a year is stale the day a new dependency ships. Continuous monitoring means re-scanning on every build or deployment, alerting on certificate expiry before it causes downtime, and flagging drift whenever new code introduces an algorithm or key size that falls outside your approved baseline.

Map Findings to Compliance Requirements

A current CBOM is direct evidence for the cryptography-related controls in PCI DSS, HIPAA, GDPR, and ISO/IEC 27001 Annex A, and it’s rapidly becoming relevant to EU-specific obligations too: the EU Cyber Resilience Act and DORA both increase the pressure for verifiable, full-stack visibility into the cryptography embedded in products and financial-sector systems. Mapping each CBOM entry to the specific control it satisfies turns an inventory spreadsheet into audit evidence.

How to Build a CBOM: A Four-Step Process

Building a CBOM is an iterative process, not a single scan. These four steps cover discovery through automation.

1. Discover the cryptographic entities:

   Identify cryptographic entities across your system: third-party applications (databases, configuration management, and automation tools), source code, data at rest (configuration files, digital certificates, passwords, and keys), data in motion (SSL/TLS protocols and VPN configurations), and hardware (HSMs and IoT devices).

2. Generate and maintain the inventory:

   Decide when to generate inventory at each stage of development and deployment. Each stage should augment the one before it, preserving the link between where a component was introduced and where it’s used, so you can trace and remediate vulnerabilities. Different stakeholders need different scope: a product team typically cares about source code, dependencies, and application configuration, while IT operations needs a wider view spanning software, PKI, SaaS, network, data, and hardware.

3. Audit and review regularly:

   Schedule regular audits to confirm cryptographic entities still align with current security standards, and to catch anything that’s drifted: vulnerable key sizes, weak algorithms, certificates due for renewal or revocation.

4. Automate and integrate into CI/CD:

   Manual, point-in-time scans don’t scale past a handful of repositories. Open-source tooling built on the CycloneDX CBOM schema, along with commercial scanners, can extract cryptographic metadata from source code, containers, and infrastructure-as-code templates automatically. Wiring CBOM generation into your CI/CD pipeline turns it from an annual audit exercise into a live, versioned artifact.

How Does CBOM Improve Your Security Posture? 

A CBOM gives your organization detailed insight into the cryptographic assets tied to every commercial and open-source component you run, which improves your security posture in three concrete ways. First, it strengthens crypto-agility: you can take proactive steps against supply chain attacks and respond faster when one occurs, because you already know which components are affected. Second, it reduces the operational and financial fallout of a breach; without a CBOM, identifying every exposed asset after an incident is slow and manual, and that delay is expensive. Third, an up-to-date CBOM inventory directly supports alignment with regulatory frameworks such as NIST guidance, ISO 27001, and GDPR.

Because a CBOM gives you a granular view of your cryptographic assets, it’s also the planning input for migrating from quantum-vulnerable algorithms like RSA, DSA, ECDSA, and ECDH to the NIST-standardized post-quantum algorithms: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), all finalized in August 2024. You cannot sequence a migration you cannot see, and a CBOM is what makes that sequencing possible.

What Are the Limitations of a CBOM? 

A CBOM is a necessary tool, not a complete solution, and it’s worth going in with clear eyes about where it falls short.

• Naming ambiguity: different scanning tools can report the same algorithm under different names or parameter groupings, which complicates cross-tool comparison.
• Configuration-driven cryptography: cipher suites and algorithm choices selected at runtime, or through configuration rather than code, are harder to detect through static analysis alone.
• Provision versus consumption: a CBOM needs to distinguish a component that implements cryptography from one that merely calls another library’s implementation, and that distinction isn’t always obvious from source code.
• Coverage gaps: compiled binaries, firmware, and legacy systems without source access are harder to scan than modern, source-available applications.
• The snapshot problem: a CBOM is only accurate as of the moment it was generated. Without continuous scanning, it goes stale as fast as your next deployment.

A Real-World Example: Migrating a Legacy Certificate Authority

Here’s how the pieces above fit together in practice. A CBOM scan of an internal certificate authority surfaces several thousand active certificates still issued with 2048-bit RSA keys. Cross-referencing that finding against the classification table above flags RSA-2048 as proposed for deprecation after 2030 under NIST’s draft IR 8547 timeline, so the security team assigns it a migration priority based on how long each certificate’s protected data needs to stay confidential. Certificates tied to long-lived data (signed firmware, archival records) get scheduled first; short-lived, frequently rotated certificates get scheduled last. The team then uses a PKI-as-a-Service platform to issue hybrid certificates that pair the existing RSA signature with an ML-DSA signature, so relying parties that don’t yet support post-quantum algorithms keep working during the transition. The CBOM is re-scanned after each migration wave to confirm the RSA-2048 count is actually dropping, rather than assuming the plan is on track.

How Could Encryption Consulting Help? 

CBOM Secure is Encryption Consulting’s cryptographic discovery and inventory platform. It scans your environment for algorithms, keys, certificates, and protocols, builds a CycloneDX-based CBOM, and highlights weak or quantum-vulnerable cryptography so your team can prioritize migration with evidence instead of guesswork.

Once your CBOM is built, Encryption Consulting’s PQC Advisory Services turn that inventory into a sequenced migration roadmap: a detailed risk assessment of your on-premises, cloud, and SaaS environments, a strategy and roadmap to mitigate the quantum-vulnerable cryptography the CBOM surfaces, and hands-on support implementing the technologies and processes that get you to a quantum-resistant environment. Backed by ISO/IEC 27001:2022 and SOC 2 certified practices.

For related reading, see how a cryptographic inventory feeds a broader crypto-agility strategy, what buyers should look for in post-quantum ready PKI-as-a-Service, and where CBOM fits on Encryption Consulting’s five-level PQC maturity model.

Conclusion

Identifying and managing your organization’s software and cryptographic assets through SBOM and CBOM respectively is the foundation for defending against software supply chain and cryptographic attacks alike. A CBOM built once and left alone is only marginally better than no CBOM at all; the value comes from pairing it with classification, access controls, lifecycle governance, recovery planning, continuous monitoring, and compliance mapping, then keeping it current as your systems change and the post-quantum migration deadlines get closer.

Frequently Asked Questions

What is the difference between a CBOM and an SBOM?

An SBOM (Software Bill of Materials) lists the software components, libraries, and dependencies in an application, along with metadata like version and license. A CBOM (Cryptographic Bill of Materials) lists the cryptographic assets those components use: algorithms, key sizes, certificates, and protocols. NIST treats CBOM as an extension of SBOM practice specifically for post-quantum cryptography migration planning.

What format should a CBOM use?

The dominant format is OWASP CycloneDX, which added native cryptographic asset support in version 1.6 and is now published as the ECMA-424 standard. Using a standard format rather than a proprietary spreadsheet means your CBOM works with the growing ecosystem of open-source and commercial CycloneDX tooling.

Who is responsible for maintaining a CBOM inside an organization?

Responsibility typically splits by scope: product and application security teams own the CBOM for source code and application dependencies, while IT operations or a dedicated cryptographic governance function owns the broader inventory across PKI, network, cloud, and hardware. Federal agencies are now formalizing this under Executive Order 14412, which created a named PQC migration lead role responsible for agency-wide cryptographic inventory management.

How does a CBOM support post-quantum cryptography migration?

A CBOM identifies exactly where quantum-vulnerable algorithms like RSA and ECDSA are used, which lets you prioritize migration by data sensitivity and retention period instead of migrating systems in an arbitrary order. That prioritization is what makes it possible to meet timelines like NIST’s draft 2030 deprecation and 2035 disallowance dates for classical public-key algorithms.

Can a CBOM be automated, or does it require manual audits?

Both. Automated tooling built on the CycloneDX CBOM schema can extract cryptographic metadata from source code, containers, and infrastructure-as-code templates as part of a CI/CD pipeline, which keeps the inventory current. Periodic manual audits still matter for catching configuration-driven cryptography and legacy systems that automated scanners can’t fully reach.