up:: Migration Architecture MOC

Cryptographic Bill of Materials (CBOM)

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic algorithm, key, certificate, protocol configuration, and cryptographic dependency in an organization’s systems and products. It’s the cryptographic counterpart to a software bill of materials (SBOM): where an SBOM catalogs software components, a CBOM catalogs cryptographic ones. It’s the foundational deliverable of a post-quantum migration, because until an organization knows which of its systems use which cryptography, it can’t know what’s quantum-vulnerable, what’s already safe, what a vendor controls, or where to begin.

The short version:

• A CBOM answers the question a migration can’t start without: where does our cryptography actually live, and what is it?
• It’s granular. Not “we use RSA,” but “RSA-2048, protecting the TLS certificate key on application X, managed in this HSM, guarding this data class.”
• Every entry carries an evidence grade: verified (proven from a technical artifact) or documented (asserted but unverified). A CBOM built on documentation alone is unreliable.
• U.S. federal policy mandates it: OMB M-23-02 requires agencies to inventory their cryptography, and it’s a foundational step toward the 2035 deadline.
• The hardest part is completeness. The typical first-pass CBOM misses much of the estate, especially the cryptography inside vendor products.

Think of it as the parts list and wiring diagram for a building’s locks. Before you can re-key a large building, you need to know every door, what kind of lock each one has, who installed it, who holds the master, and which rooms it protects. A CBOM is that document for an organization’s cryptography, and almost no one has one until a migration forces the question.

What is a CBOM?

A CBOM is a discovery-and-inventory artifact that enumerates the cryptographic assets across an environment so they can be assessed and migrated. It’s a specialized extension of the SBOM concept: some SBOM formats, notably CycloneDX (from version 1.6), include a native CBOM schema, which makes the inventory machine-readable and consumable by vulnerability-management and governance platforms. The point of formalizing it as a bill of materials rather than a loose spreadsheet is that cryptography is a supply chain, an algorithm sits inside a library, inside an application, inside a system, protecting a data class, and a bill of materials is the structure built to trace exactly those dependencies.

Why does a post-quantum migration need a CBOM?

Because the migration replaces specific algorithms across an entire enterprise, and the scope of that replacement is unknown without an inventory. Organizations that try to migrate without a CBOM consistently discover new vulnerable systems all the way through the project, systems that were never in scope, unknown to the security team, or assumed to be someone else’s job. Three concrete reasons it’s the first deliverable:

• Finding it comes first. Migrations stall first on visibility, and the CBOM is the artifact that creates it.
• The risk models require it as input. Mosca’s theorem can’t be applied without knowing what systems exist and who controls them, because the migration-time variable can’t be estimated blind. HNDL exposure can’t be scoped without knowing which data class each algorithm protects.
• Regulation demands it (see below). For federal agencies the inventory is not optional.

What does a CBOM contain?

A CBOM is granular by design, one entry per cryptographic asset, with enough context to assess and prioritize it. A well-structured entry captures fields along these lines:

Field	What it records
Algorithm	The exact algorithm and parameters (RSA-2048, ECDSA P-256, AES-256), at parameter-set granularity
Purpose	Key establishment, signature, encryption, integrity, or hashing
System	The application, service, or device that uses it
Layer	Where in the stack: transport, application, firmware, at-rest, or PKI
Control boundary	Customer-managed, vendor-configurable, vendor-opaque, or hardcoded
Vendor	For vendor-controlled surfaces
Data class	The sensitivity of the data it protects (drives HNDL exposure)
Threat classification	Quantum-vulnerable (HNDL / Non-HNDL) or quantum-safe
Evidence grade	Verified or documented (see below)
Last verified	The date the entry was last confirmed

The two fields organizations most often omit are data class (without it, HNDL risk can’t be assessed) and control boundary (without it, the migration timeline can’t be estimated, because vendor-controlled surfaces move on a schedule you don’t own). Modern practice adds a provenance trace to each field, a derived_from record pointing at the exact source configuration directive, file, and line, so a reviewer can confirm the entry reflects the system’s real configured behavior rather than a transformation artifact.

Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).

How is a CBOM produced?

Through four discovery methods, almost always combined, because no single one sees the whole estate:

• Active scanning. Network scanning, TLS handshake inspection, certificate enumeration, and SSH key scanning identify cryptographic configurations in live traffic and certificate stores. Tools include sslyze and testssl.sh.
• Static analysis. Code and binary analysis surface cryptographic library calls, hardcoded parameters, and key-management patterns that never appear in a live handshake.
• Configuration review. Examining server configs, application settings, infrastructure-as-code, and cloud platform settings reveals the algorithm and parameter choices as actually configured.
• Vendor inquiry. Structured questionnaires document the cryptography inside third-party products. The results are documented evidence, not verified, and they’re essential for the vendor-controlled surfaces that make up much of the footprint.

An important methodological point for the transport layer: a defensible TLS inventory should source from the configuration files of each termination point, not from network-handshake observation alone. A configuration-level extraction (parse each technology’s config grammar, normalize into a common schema, then compare against a quantum-readiness policy that decomposes each cipher suite into its constituent algorithms) captures what a server permits, which handshake scanning misses.

Source: Balaji et al., arXiv:2605.17955.

What counts as good evidence in a CBOM?

Not all entries are equally trustworthy, so every one is graded by evidence type:

• Verified evidence (high confidence): a technical artifact that independently proves the implementation exists and behaves as described, a TLS handshake capture showing the negotiated cipher suite, a certificate export showing the algorithm and key size, HSM audit logs, packet captures.
• Documented evidence (lower confidence): a record that asserts an implementation without proving it, an architecture diagram, vendor documentation, a configuration standard, a self-reported inventory. Documented evidence can be wrong, because systems don’t always run the way the documentation claims.

A CBOM built primarily on documented evidence is incomplete for migration planning. High-risk systems need verified evidence, and documented-only entries should be flagged and scheduled for confirmation. A frequent first task on an estate that “already has a CBOM” is re-verifying prior documented findings.

Why do network scanners produce a weaker CBOM?

Because a network scanner observes only what a server negotiates under the conditions it’s probed, and misses several classes of evidence that matter for quantum readiness:

1. Permitted-but-uninvoked fallbacks. A 2026 corpus study of real-world TLS configurations found that 21.8% of TLS-enabled contexts permitted TLS 1.0 or 1.1 as configured even though most would negotiate 1.2 or 1.3 in practice.
2. Weak certificate references that pass only permissive clients. The same study found 53.3% carried leaf-only certificate references that pass permissive clients but can fail strict ones.
3. Declared-but-unexercised key material. HSM-backed key references that a config declares but no probed handshake ever exercises.
4. Per-handshake-invisible policy. Session policies set in configuration that a single external probe never reveals.

The result is an inventory whose findings survive every observed handshake while still permitting a downgrade against a sophisticated adversary. The fix is layered evidence: configuration-level extraction as the primary layer, handshake observation as a runtime cross-check.

Source: Balaji et al., arXiv:2605.17955.

How does a CBOM connect to the quantum risk models?

The CBOM is the data the risk models run on. It turns an abstract threat into a scored, prioritized picture of a specific estate:

• HNDL: the entries protecting long-lived sensitive data are the primary harvesting targets, and the CBOM’s data-class field is what identifies them.
• Non-HNDL and PKI collapse: the entries for signing keys, CA infrastructure, and authentication tokens are the trust attack surface, and the CBOM maps them to the systems that rely on them.
• Mosca’s theorem: the CBOM supplies both variables, the data-class field gives the secrecy lifetime, and the control-boundary and complexity fields give the migration time.
• Blast radius: the CBOM’s dependency mapping is what lets you tell a trust anchor protecting ten thousand downstream systems from one protecting ten.

Who requires a CBOM?

Cryptographic inventory has moved from best practice to mandate, especially in the U.S. federal space:

• OMB M-23-02 requires U.S. federal agencies to produce and maintain a cryptographic inventory and to report it as part of the quantum-migration program.
• NSM-10 (National Security Memorandum 10) establishes the 2035 transition deadline and treats the inventory as a foundational step.
• NIST IR 8547 frames CBOM production as a prerequisite for migration planning.
• CNSA 2.0 implies inventory for national-security systems through its migration requirements.

What makes a CBOM good or bad?

A high-quality CBOM covers all system types (perimeter TLS plus internal services, APIs, databases, firmware, and cloud services), distinguishes verified from documented evidence, includes vendor-controlled surfaces with their roadmap status, records a data class and control boundary for every entry, is machine-readable (CycloneDX), and has a review cadence. A low-quality one is built on self-reported evidence, covers only perimeter-facing systems, omits vendor surfaces, lacks data classification, and is produced once and never updated. The single most common failure is treating the CBOM as a static snapshot: an inventory produced once is out of date within about six months, so it has to be a living document.

What tools produce a CBOM?

CBOM tooling is immature but growing. Static-analysis and generation tools (such as IBM’s CryptoGraph) and runtime analyzers exist, CISA provides federal submission tooling, and CycloneDX 1.6+ is the emerging machine-readable standard format. In practice most production CBOMs still combine scanners like sslyze, custom scripts, and manual review, because no current tool provides complete coverage automatically. Human analysis and vendor inquiry remain essential, which is part of why a thorough inventory is real work rather than a one-click scan.

Common misconceptions

• “We already have a CBOM, our asset inventory.” An asset inventory lists systems; a CBOM enumerates the cryptography inside them. They’re different artifacts, and conflating them is the most common starting error.
• “A scan will produce it.” A network scan is one evidence layer, and a weak one on its own. A defensible CBOM layers configuration-level extraction, static analysis, and vendor inquiry on top.
• “We finished it.” If it covered only internally-managed systems, the vendor-controlled surfaces, often much of the footprint, are still missing. And a finished CBOM goes stale within months without maintenance.
• “Documented evidence is good enough.” Documentation asserts; it doesn’t prove. High-risk entries need verification, because systems don’t always run as documented.

Questions people ask

What’s the difference between a CBOM and an SBOM? An SBOM inventories software components; a CBOM inventories cryptographic ones (algorithms, keys, certificates, protocol configs). A CBOM is effectively a cryptography-focused specialization, and CycloneDX 1.6+ can express both.

Is a CBOM legally required? For U.S. federal agencies, yes: OMB M-23-02 mandates a cryptographic inventory. For everyone else it’s strongly recommended and increasingly expected, and it often arrives through vendor and procurement requirements even where no law names you directly.

How complete does a CBOM have to be to start? Not fully complete. Starting with the crown-jewel and highest-risk systems is more effective than trying to inventory everything at once, which is a common way to never ship. Completeness grows in phases.

Why do so many CBOMs miss vendor cryptography? Because vendor-controlled systems are invisible to internal scans and require external inquiry, so a first pass that only surveys internally-managed systems leaves much of the footprint uncounted. See Vendor-Controlled Crypto Surfaces.

How often does a CBOM need updating? Treat it as living. A practical cadence is quarterly review for high-risk systems and annually for low-risk ones, because algorithm changes, new systems, and vendor updates make a static snapshot stale within roughly six months.

What format should a CBOM be in? Machine-readable, so it integrates with vulnerability-management and governance tooling. CycloneDX 1.6+ is the emerging standard, and its CBOM schema is designed for exactly this.

---

Everything here is the map, given freely. When your team needs its cryptographic inventory built, verified, and turned into a prioritized migration picture against your actual estate, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.