How to Create a CBOM (Cryptographic Bill of Materials)

Most organizations cannot answer a deceptively simple question: Where, exactly, is cryptography running in our environment, and what algorithms is it using?

That gap used to be a hygiene problem. Now it is a strategic risk. With the arrival of practical post-quantum standards and a wave of government deadlines, the encryption that protects your data, your certificates, and your software signing pipelines has a shelf life. You cannot replace what you cannot see, and the encryption sprawl in a typical enterprise, spread across applications, libraries, firmware, network appliances, and cloud services, has been accumulating quietly for two decades.

A Cryptographic Bill of Materials, or CBOM, is how you finally make that sprawl visible. This guide explains what a CBOM is, why it has suddenly become a board-level concern, and how to actually build one, from defining scope to running discovery tooling to keeping the inventory alive over time.

What a CBOM Actually Is

A CBOM is a structured, machine-readable inventory of every cryptographic asset in your environment and the relationships between them. Think of it as the cryptographic layer of your software supply chain: where an SBOM (Software Bill of Materials) tells you which components and dependencies make up an application, a CBOM tells you which cryptographic algorithms, keys, certificates, and protocols those components rely on.

In practice, the dominant format is an extension of the CycloneDX standard. CycloneDX added a cryptographic asset model that lets you describe four broad categories of crypto in a single JSON document:

• Algorithms such as RSA, AES, ECDSA, SHA-256, or TLS cipher suites, along with their parameters (key length, mode of operation, curve).
• Keys and related material, including public and private keys, their size in bits, format such as PEM, and whether they are protected in hardware.
• Certificates, their issuers, validity windows, and the algorithms that sign them.
• Protocols such as TLS, SSH, or IPsec, and the specific configurations and cipher suites your systems negotiate.

Crucially, a CBOM also captures dependencies. A TLS session depends on a cipher suite, which depends on a key-exchange algorithm and a signature algorithm, which in turn depend on a particular library implementation. When you can trace those chains, you can answer questions that are otherwise nearly impossible, like “which production services would break if we disabled RSA-2048?”

Why CBOMs Moved from Nice-to-Have to Mandatory

For years, cryptographic inventory was something organizations meant to get around to. Three forces have collapsed that timeline.

The post-quantum standards are real and final. In August 2024, NIST published the first finalized post-quantum cryptography standards: FIPS 203, 204, and 205. FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) handles quantum-resistant key establishment and is positioned to replace RSA and ECDH. FIPS 204 (ML-DSA, from Dilithium) and FIPS 205 (SLH-DSA, from SPHINCS+) cover digital signatures, replacing ECDSA and RSA signing. The eight-year competition is over. The question for enterprises is no longer whether to migrate, but how quickly and efficiently.

The deadlines have teeth. The NSA’s CNSA 2.0 suite lays out a staged migration that runs through the early 2030s. Software and firmware signing is expected to support and prefer post-quantum algorithms by 2025, one of the earliest milestones in the suite, with exclusive use required by 2030. Networking equipment follows the same exclusive-use deadline of 2030, while operating systems, custom applications, and cloud services move to exclusive use by 2033. Separately, starting January 1, 2027, any new NSS acquisition must support CNSA 2.0 algorithms by default.

By 2035, full quantum resistance is required across U.S. National Security Systems in line with National Security Memorandum NSM-10. Even organizations outside the federal supply chain tend to inherit these timelines through vendors, regulators, and customers.

“Harvest now, decrypt later” makes the clock retroactive. Adversaries are already capturing encrypted traffic and stored data today, betting they can decrypt it once a cryptographically relevant quantum computer exists. Any data with a confidentiality lifetime stretching into the 2030s – health records, financial data, state secrets, long-lived intellectual property – is effectively exposed right now if it travels over quantum-vulnerable encryption. That reframes migration as something with urgency in the present tense, not a far-off project.

A CBOM is the foundation for responding to all three. It is the first concrete step in measuring the scale and scope of a post-quantum migration, and it doubles as an early-warning system for any future cryptographic break, the next Heartbleed, the next deprecated hash, the next compromised certificate authority.

Before You Start: Get the Scope Right

One of the most common reasons CBOM initiatives lose momentum is attempting to cover too much too early. The discovery phase is typically the most resource-intensive part of the work, so decisions you make about scope determine whether you ship something useful in weeks or get lost for a year.

Start by deciding what “done” means for your first iteration. Two reasonable framings:

• The breadth-first approach aims for a shallow inventory across the entire estate, every system, but only the cryptography that is easy to detect. This is good for executive reporting and for sizing the overall problem.
• The depth-first approach picks the systems that matter most: anything handling long-lived sensitive data, anything subject to CNSA 2.0, your code-signing and PKI infrastructure, your most business-critical applications, and inventories them thoroughly, including the messy embedded and firmware-level cryptography. This is usually the better starting point because it produces an actionable migration plan rather than a wall of data.

Whichever you choose, write it down and get sponsorship for it. A CBOM is a cross-functional effort that touches application teams, infrastructure, security, and often procurement. Treat the scope statement as the contract that keeps everyone aligned.

How to Create a CBOM, Step by Step

Step 1: Inventory what you already know

You likely already have a strong starting point embedded in existing enterprise systems. IT asset management databases, configuration management databases (CMDBs), certificate management platforms, and especially any SBOMs you already generate are all sources of cryptographic signal. A CBOM is explicitly designed to build on an SBOM; the SBOM tells you which libraries are present, and the CBOM adds what those libraries actually do cryptographically. Pull these inventories together before you scan anything. It saves effort and prevents blind spots.

Step 2: Discover cryptographic assets across the environment

This step forms the core of CBOM creation. The objective is to identify every instance where cryptography is implemented, configured, or implicitly relied upon. Because no single technique provides full visibility, discovery typically requires multiple complementary approaches:

• Source-code and binary analysis identify cryptography baked into applications, API calls into cryptographic libraries, hardcoded algorithm choices, and key generation routines. Static analysis remains the most reliable method for uncovering cryptography in systems you directly control.
• Network and protocol scanning observes what is actually negotiated in transit, such as TLS versions, cipher suites, SSH configurations, and VPN tunnels. This catches the gap between what a config file claims and what a service really does.
• Certificate and key discovery focuses on your PKI, TLS endpoints, keystores, and HSMs to enumerate certificates, their signing algorithms, key sizes, and expiry dates.
• Configuration and firmware inspection targets the cryptography embedded in network appliances, IoT and OT devices, and platform settings, often the hardest to reach and the most likely to be quantum-vulnerable for years.

The output of each technique should normalize to the same CBOM schema so you end up with one inventory, not five isolated reports.

Step 3: Use automated tooling rather than spreadsheets

Manual discovery does not scale, and a CBOM maintained by hand becomes outdated the moment you save the file. Several open and commercial tools generate CycloneDX-format CBOM outputs directly.

A representative open-source workflow uses CodeQL-based scanners or tools to analyze a codebase and emit a cbom.json. The general pattern looks like:

• Install the CodeQL CLI and clone the CodeQL query repository.
• Install the CBOM generation tool (for example, via pip).
• Create a CodeQL database for the target project.
• Run the tool against that database; it produces a cbom.json in the project directory describing the cryptographic assets it found.

You then merge the per-project outputs, enrich them with the network and certificate discovery from Step 2, and consolidate everything into a single enterprise CBOM. The exact commands matter less than the principle: discovery should be repeatable and automated so it can run in CI/CD and on a schedule.

This is also the point where a purpose-built platform outpaces a stitched-together toolchain. The open-source scanners are very good at finding cryptography in code you own, but each one sees only a single slice of the estate, and someone still has to merge, deduplicate, and keep the results current as systems change.

Encryption Consulting’s CBOM Secure is built to close exactly that gap: it automatically discovers, inventories, and continuously monitors every key, certificate, algorithm, and cryptographic library across application source code, cloud, and on-premises infrastructure from a single deployment.

What makes it well-suited to this work is that it does not treat each finding as an isolated line item; it models cryptographic assets as a relationship graph, linking certificates to their private keys and tracing how secrets are consumed across services. That is precisely the dependency view that Steps 2 and 4 are otherwise trying to reconstruct manually.

In practice, that means the discovery techniques described above arrive pre-integrated rather than assembled after the fact. A Source Code Visualizer maps cryptographic API usage and library dependencies across the codebase, surfacing deprecated algorithms, hardcoded secrets, and embedded credentials before code ships. Cloud discovery extends coverage across AWS, Azure, and GCP, as well as HashiCorp Vault, HSMs, and on-premises infrastructure, feeding results directly into a unified inventory.

Each asset is then scored for compliance risk and post-quantum exposure, which is the work Step 5 calls for. For most organizations, standing this up is faster, more complete, and far more durable than maintaining the equivalent out of individual scanners and spreadsheets, which is why a continuous platform, rather than a one-time scan, is the approach worth aiming for.

Step 4: Build a CBOM that is actually useful

A CBOM is only as valuable as the metadata it captures. For each asset, aim to record at minimum:

• The algorithm and its parameters, not just “RSA” but “RSA-2048” or “ECDSA P-256.”
• For keys: size in bits, format, and whether the key is hardware-protected.
• For certificates: issuer, validity period, and signing algorithm.
• For protocols: supported versions and the specific cipher suites in play.
• The location and owning system, so the inventory ties back to something a human can act on.
• Known vulnerabilities or deprecation status, linking weak crypto to the assets that use it.

The dependency relationships matter as much as the assets themselves. A CBOM becomes significantly more powerful when it can express that a service depends on a protocol, which depends on a cipher suite, which in turn depends on a specific cryptographic algorithm. This relationship mapping is what enables meaningful impact analysis.

Step 5: Assess risk and prioritize

Once the CBOM is populated, it should be analyzed through a risk lens that incorporates cryptographic and quantum readiness considerations. The first step is to identify quantum-vulnerable algorithms, including RSA, elliptic-curve cryptography (ECDH, ECDSA), Diffie-Hellman key exchange, and legacy or weak symmetric constructions where applicable.

Prioritization should not be purely cryptographic. Instead, it should combine multiple factors:

• Sensitivity and expected confidentiality lifetime of protected data
• Regulatory and compliance exposure (e.g., CNSA 2.0 alignment requirements)
• External exposure of the system or service
• Complexity and operational cost of migration
• Dependency depth across systems and services

This is where a CBOM becomes operationally valuable: it transforms a broad mandate such as “be quantum-ready” into a structured, prioritized remediation backlog with clear technical justification.

Step 6: Treat the CBOM as a living system, not a static report

Cryptography changes constantly, new services ship, certificates rotate, libraries update. A CBOM generated once and filed away is worse than useless because it creates false confidence. Wire CBOM generation into your build pipelines and run periodic estate-wide scans, so the inventory reflects reality. Tie it into change management so new cryptographic assets are captured as they are introduced.

The objective is to maintain a continuously updated source of truth that reflects the current cryptographic state of the enterprise. This enables organizations to respond quickly when algorithms are deprecated, vulnerabilities emerge, or migration deadlines accelerate.

Common Pitfalls to Avoid

Several challenges consistently undermine CBOM initiatives:

• Teams over-index on code scanning alone and miss the cryptography living in network configurations, appliances, and third-party services. Discovery has to be multi-layered.
• Organizations treat the CBOM as a security-team-only deliverable, when the people who must act on it are application owners and infrastructure engineers. Build the inventory with remediation owners in the room.
• Some chase completeness over usefulness, spending months cataloging every SHA-256 checksum while the actually-dangerous RSA key exchanges sit unaddressed. Prioritize by risk, not by what is easy to count.
• Treating the inventory as a one-time exercise. Cryptographic assets evolve continuously as applications change, certificates are renewed, and infrastructure is updated. Without automated discovery and regular refreshes, a CBOM quickly loses accuracy and value.

CBOM and Crypto-Agility: The Bigger Picture

A CBOM is not the end goal; it is the enabler of crypto-agility, the organizational capability to change cryptographic algorithms quickly and safely without re-architecting everything around them. The reason quantum migration feels daunting is that most systems were built with cryptography hardcoded deep in their assumptions.

Visibility from a CBOM is the precondition for fixing that: once you know where every algorithm lives and what depends on it, you can begin abstracting crypto behind interfaces, adopting hybrid schemes that combine classical and post-quantum algorithms during transition, and swapping out the underlying cryptographic building blocks as standards evolve.

In other words, the CBOM you build for the quantum migration is the same asset that will protect you from the next cryptographic surprise, whatever it turns out to be. That is what makes it a durable investment rather than a compliance checkbox.

How Encryption Consulting Can Help

Building a CBOM is achievable, but doing it well across a large, heterogeneous environment, and then turning it into an executed post-quantum migration, is where most organizations want a partner. Encryption Consulting provides an end-to-end post-quantum cryptography program designed exactly for that journey, from CBOM through assessment to implementation.

CBOM and cryptographic discovery. Encryption Consulting helps organizations discover and inventory every cryptographic asset across the enterprise, certificates, algorithms, protocols, and keys, and assemble them into a CBOM that supports compliance, risk management, and a smooth path to post-quantum cryptography. The discovery combines code, network, certificate, and configuration analysis so the inventory reflects what is actually running, not just what documentation claims.

PQC assessment. With the inventory in hand, the team evaluates your current cryptographic environment, scans for quantum-vulnerable assets, and produces risk assessments that rank exposure by data sensitivity, regulatory pressure, and migration complexity. This is the bridge between “we have a list” and “we have a plan.”

Strategy and roadmap. Encryption Consulting delivers a structured, multi-phase roadmap where each phase is operationally defined and compliance-aligned, so a PQC strategy translates into execution rather than a slide deck of recommendations. That includes tactical and strategic mitigation approaches such as hybrid cryptography, balanced against your timelines, budget, and resource constraints, and aligned to mandates like CNSA 2.0 and the relevant federal directives.

Implementation and ongoing management. Finally, the team supports the actual migration, re-architecting toward crypto-agility, deploying post-quantum and hybrid algorithms, modernizing PKI and code-signing pipelines, and standing up the processes that keep the CBOM current as your environment evolves. Because the engagement spans the full lifecycle, you are not left to operationalize a strategy alone.

If your organization is staring at the 2027-2035 deadlines and wondering where to start, the honest answer is: start with visibility. A CBOM is the first and most important step, and it is the natural on-ramp to everything that follows.

Frequently Asked Questions

• What is the difference between a CBOM and an SBOM?

An SBOM inventories the software components and dependencies in an application. A CBOM inventories the cryptographic assets, algorithms, keys, certificates, and protocols, and their relationships. A CBOM is typically built as an extension of an SBOM using the CycloneDX standard.

• Do I need a CBOM if I’m not a government contractor?

Very likely, yes. Even outside federal mandates, post-quantum requirements flow down through vendors, auditors, cyber-insurance, and customers. And “harvest now, decrypt later” attacks put any long-lived sensitive data at risk today, regardless of sector.

• How long does it take to build a CBOM?

A scoped, depth-first CBOM of your most critical systems can take weeks. A complete enterprise-wide inventory is a larger program, which is why prioritizing high-risk systems first is the recommended approach.

• Which cryptographic algorithms are quantum-vulnerable?

Public-key algorithms are most at risk: RSA, Diffie-Hellman, and elliptic-curve schemes (ECDH, ECDSA). Symmetric algorithms like AES are more resilient but benefit from larger key sizes. The NIST replacements are ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).

• Is a CBOM a one-time project?

No. Cryptography changes continuously, so a CBOM must be regenerated automatically through CI/CD and periodic scans to stay accurate. A stale CBOM creates false confidence.

Sources and further reading

• NIST Standardized PQC Algorithms
• Quantum-Proof with CNSA 2.0
• Building Your CBOM for Stronger Digital Security
• Cryptographic Discovery & Inventory (CBOM Secure)
• Post-Quantum Cryptographic Advisory Services