How to Create a Cryptographic Bill of Materials: A Step-by-Step Build Guide (2026)

Key Takeaways

• A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every algorithm, key, certificate, and protocol in your environment, mapped to the code and infrastructure that actually uses it.
• Executive Order 14412, signed June 22, 2026, is the first US federal directive to name the CBOM specifically, with agency inventory obligations starting within 90 days and contractor deadlines tied to December 31, 2030.
• No single scan produces a complete CBOM. Code analysis, certificate and key store audits, network protocol capture, and SBOM correlation all catch different assets, and none of them catch everything alone.
• CycloneDX 1.6, now standardized as ECMA-424, is the format regulators, auditors, and tooling vendors have converged on. Build against it from the start instead of inventing a custom schema you’ll have to migrate off later.
• Generating the inventory is the easy half. Assigning an owner to every asset and feeding the CBOM into CI/CD as a policy gate is where most first attempts stall out.
• A CBOM is a living system, not an audit deliverable you file once a year. Certificates rotate, libraries update, and new services ship every week in any estate with more than a handful of applications.

Ask a security leader for a list of open-source libraries in production and most can produce one in an afternoon. Ask the same person where RSA-2048 is running today, and what breaks if it has to come out, and the room goes quiet. That gap used to be a research problem for cryptographers. As of this year it’s a compliance problem with a filing deadline. A Cryptographic Bill of Materials closes that gap. It’s the cryptographic equivalent of a Software Bill of Materials (SBOM): instead of listing which open-source packages and versions make up an application, it lists which algorithms, key lengths, certificate chains, and protocol versions that application actually relies on, and where. The idea isn’t new. What’s new is that three separate forces landed on the same 18 months: the NIST post-quantum standards went final, PCI DSS 4.0’s cryptographic inventory requirements became mandatory, and a June 2026 executive order put a federal clock on the whole exercise.

Building a CBOM by hand, in a spreadsheet, is how most organizations still do this — and it’s also why most first attempts are wrong within a month. Cryptography doesn’t live in one place. It’s baked into TLS configs, buried in a decade-old Java library nobody has touched since a contractor left, sitting in an HSM that predates the current security team, and quietly negotiated by a load balancer that was never in scope for the last three audits. This guide walks through what actually goes into a CBOM, the discovery methods you need to run in parallel to find all of it, and the steps to turn scattered findings into a single inventory that survives contact with an auditor or a QSA.

Key Definitions

• CBOM (Cryptographic Bill of Materials): A structured inventory of cryptographic assets — algorithms, keys, certificates, protocols — and their dependency relationships to the software and infrastructure components that use them.
• SBOM (Software Bill of Materials): An inventory of the software components and libraries that make up an application. A CBOM builds on an SBOM by describing what those components do cryptographically, not just which components exist.
• CycloneDX: The OWASP-backed bill-of-materials standard, now published as ECMA-424, that added native cryptographic asset modeling in version 1.6. It’s the dominant format for both SBOMs and CBOMs.
• Cryptographic agility: The ability to swap out an algorithm, key size, or protocol without a multi-year re-architecture. A CBOM is the prerequisite for measuring it you can’t manage what you haven’t inventoried.
• Harvest-now-decrypt-later (HNDL): The risk that adversaries are recording encrypted traffic today so they can decrypt it once a cryptographically relevant quantum computer exists. It’s why long-confidentiality data gets prioritized in a CBOM even before any quantum computer is built.
• CNSA 2.0: The NSA’s Commercial National Security Algorithm Suite, which sets a staged migration schedule for national security systems to quantum-safe algorithms including ML-KEM and ML-DSA, running from 2027 through 2035.

What exactly goes in a CBOM?

A CBOM captures four categories of cryptographic asset and the relationships between them: algorithms (RSA, AES, ECDSA, SHA-256, TLS cipher suites), keys and key material, certificates, and the protocols that carry them (TLS versions, SSH configurations, IPsec parameters). Each entry gets tied back to the component, service, or host that implements or invokes it, which is the part most spreadsheet-based inventories skip entirely.

That relationship mapping is the whole point. A list of “we use RSA somewhere” tells an auditor nothing actionable. A CBOM entry that says this specific service, running this specific library version, on this specific host, uses RSA-2048 for key establishment — and that host handles payment card data is the difference between a finding you can remediate and a finding you can only acknowledge. CycloneDX models this as a dependency graph, the same “uses” and “implements” relationships it already uses for software components, which is deliberate: it lets a CBOM sit next to your existing SBOM tooling instead of requiring a parallel toolchain.

One distinction trips up a lot of first-time builders: the difference between a component that provides cryptography and one that merely consumes it. A TLS library provides cryptographic primitives. An application that calls that library to encrypt a database connection consumes them. Both need an entry, but conflating the two is one of the most common sources of duplicate or misleading CBOM entries, and it’s worth deciding your convention before discovery starts, not after you’ve generated ten thousand rows you now have to reconcile.

1.     Define Scope Before You Scan Anything

Decide what “done” looks like before you run a single tool. Scoping by regulatory driver works better than scoping by business unit: if PCI DSS 4.0 is the trigger, start with everything in the cardholder data environment. If it’s the federal executive order, start with high-value assets and high-impact systems, since those carry the December 2030 deadline. Trying to inventory the entire estate on day one is how these projects die — six months in, with a partial spreadsheet and no clear finish line.

2.     Pull Together What You Already Have

Before you scan anything new, gather the inventories that already exist: CMDBs, certificate management platforms, key management system exports, and any SBOMs already generated for your applications. An SBOM is explicitly meant to be the backbone a CBOM references the SBOM tells you which libraries are present, the CBOM adds what those libraries do cryptographically. Skipping this step means re-discovering things you already knew and burning discovery budget on ground you’ve already covered.

3.     Run Discovery Across Every Layer, Not Just One

This is where most first attempts fall short, because no single technique sees the whole picture. You need several running in parallel:

• Static code analysis — scanning source repositories and binaries for cryptographic library calls, hardcoded algorithm choices, and key generation code.
• Certificate and key store audits — inventorying HSMs, KMS instances, and internal certificate authorities, plus a certificate transparency log query against your own domains. Anything that shows up in CT logs but not in your managed inventory is a certificate nobody’s tracking.
• Network and protocol capture — TLS handshake inspection at load balancers, VPN concentrators, and reverse proxies, to catch cryptography that’s configured at the network layer rather than in application code.
• Container and configuration scanning — checking container images and infrastructure-as-code for cryptographic configuration that never touches a source repository.

The table below is a rough guide to what each layer catches and misses on its own.

None of these is optional if the goal is a defensible inventory. A code scan without a network capture will miss a load balancer terminating TLS 1.0 that nobody wrote a line of code for. A network capture without a code scan will miss a hardcoded DES key sitting in a batch job that never runs during business hours.

4.     Normalize Everything Into CycloneDX

Take the output from every discovery method and merge it into a single CycloneDX CBOM document. Most static analysis tools IBM’s open source CBOMkit-hyperion is the common starting point will output CycloneDX JSON natively. Certificate and network findings usually need manual mapping into the same schema the first time through, since most PKI and NAC tooling wasn’t built with CBOM export in mind. Do this consolidation early and often rather than waiting for full coverage; a partial CBOM you can query beats a complete one still sitting in five separate spreadsheets.

5.     Assign an Owner to Every Asset

An inventory without accountability is a report nobody acts on. Every key, certificate, and flagged algorithm needs an owner a person, a team, or at minimum a service account and an escalation path for when it expires, gets flagged as weak, or turns up in a policy violation. This is the step that gets skipped under deadline pressure, and it’s exactly the step a regulator or QSA will test for. “We have an inventory” and “we have an inventory with named owners, and a remediation SLA” are different answers to the same audit question.

6.     Evaluate Against Policy

Once the CBOM exists, run it against your cryptographic standard: flag deprecated algorithms (RSA and ECC after 2030 under NIST’s guidance), weak cipher suites, expired or soon-to-expire certificates, and anything that fails your organization’s minimum key length. This is also where you separate “quantum-vulnerable and needs a migration plan” from “weak today and needs fixing now”  they’re different problems with different urgency and conflating them is a common way CBOM findings get deprioritized into a backlog nobody revisits.

7.     Make It Continuous

A CBOM generated once and filed away is stale within weeks. Wire discovery into CI/CD so new services get inventoried automatically at build time and add container and network re-scans on a schedule rather than a one-time basis. The organizations that get real value out of a CBOM treat it as a guardrail a build can fail against, not a report a compliance team pulls once a quarter. That’s a bigger lift than the initial build, and it’s also the difference between a CBOM that stays accurate and one that’s wrong by the time the next audit rolls around.

Summary

A CBOM is what happens when “we think we know our cryptography” turns into a structured, queryable answer. The format is settled  CycloneDX, now ECMA-424 — so the hard part isn’t choosing a schema, it’s the discovery work: code, certificates, network traffic, and configuration all have to be scanned in parallel, then merged, owned, and checked against policy. The regulatory pressure driving this — PCI DSS 4.0 now, the federal executive order and CNSA 2.0 close behind isn’t going to loosen. Organizations that treat the CBOM as a one-time deliverable will be redoing this work every audit cycle. The ones that wire it into CI/CD as a living inventory will be answering “where is RSA running” in minutes instead of weeks.

ValueMentor‘s Quantum Business Resilience and Cyber Readiness Services, combine expert cryptographers and cryptographic asset discovery solutions with mapping against applicable regulatory mandates to produce a phased quantum transition and migration roadmap worth a look before handing the work to an already-stretched internal team.

Frequently Asked Questions