Cryptographic Bill of Materials (CBOM): Where Quantum Migration Starts

What is a cryptographic bill of materials?

A cryptographic bill of materials (CBOM) is a complete, structured inventory of all the cryptography an organization uses: every algorithm, key, certificate, protocol, and library, and where each one lives. Modeled on the software bill of materials (SBOM) concept that transformed software supply-chain security, a CBOM answers a question most enterprises currently cannot: where exactly are we using RSA, ECC, and other quantum-vulnerable cryptography?

Without that answer, quantum migration is guesswork. You cannot replace what you cannot find, and you certainly cannot prove to a regulator that you have finished. This is why building a CBOM is the practical first step of any serious post-quantum program, and why organizations that skip it stall almost immediately.

Why can't enterprises answer "what cryptography do we run?"

Because cryptography is everywhere and almost entirely invisible. It is embedded deep in applications, hardcoded into legacy systems written years ago, buried inside third-party libraries and dependencies, spread across dozens of cloud services, baked into device firmware, and issued through certificate authorities that have grown organically over time. No single team owns all of it. Most of it was configured once and forgotten. Much of it predates anyone currently responsible for it.

This sprawl is the real reason the quantum transition is hard: harder, for most enterprises, than the cryptography itself. The algorithms you migrate to (ML-KEM and ML-DSA) are standardized and available. The genuine difficulty is locating the thousands of places the old algorithms are quietly used across a large, layered, decades-old estate. A CBOM is how you turn that invisible sprawl into a map.

What should a CBOM capture?

An actionable CBOM records far more than a list of algorithm names. To drive real decisions, each cryptographic asset needs context. Algorithm and key size identifies quantum-vulnerable cryptography. Location and system tells you what to change and where. Certificate and key lifecycle reveals expiry, ownership, and rotation. Data sensitivity and lifespan drives migration priority. And dependencies show what breaks if you change it.

The single most valuable enrichment is linking each cryptographic asset to the sensitivity and lifespan of the data it protects. That is what turns a flat inventory into a prioritized plan, the same inputs the Mosca inequality uses to decide urgency. A CBOM that knows an RSA key protects a database of records requiring 25-year confidentiality tells you something a bare algorithm list never could.

How does a CBOM drive the migration?

Once you can see your cryptography, migration stops being a scramble and becomes a managed program. You prioritize the highest-risk, longest-lived assets first. You migrate them to post-quantum algorithms (typically in hybrid mode) and you track progress against the inventory, so "how far along are we?" has a real answer. Each remediated asset is checked off against a known total rather than an unknown one.

A CBOM also becomes the evidence base for compliance. Increasingly, regulators and auditors want to see that an organization understands its cryptographic risk and is actively managing it. A maintained CBOM is exactly that proof, a demonstrable record of what you run and how you are remediating it, which matters more as quantum-related mandates and expectations tighten across sectors.

Why can't a CBOM be a one-time document?

Because cryptography changes constantly. New systems are deployed, certificates are issued and rotated, libraries are updated, cloud services spin up, and vendors change their implementations. A CBOM produced once and filed away is stale within weeks: an inventory of a moment that no longer exists. The value comes from keeping it current, so it reflects your actual, live cryptographic posture rather than a historical snapshot.

This is why leading enterprises treat the CBOM as a continuous capability, not a project deliverable. Automated, ongoing discovery keeps it accurate; manual inventory simply cannot keep pace with a real enterprise's rate of change. A live CBOM becomes the foundation on which cryptographic governance (including but not limited to the quantum transition) is built.

Where should an enterprise start building a CBOM?

Begin where risk concentrates rather than trying to boil the ocean: internet-facing systems, long-lived data stores, PKI and certificate authorities, and critical machine identities. Automate discovery wherever possible, because manual inventory does not scale and goes stale immediately. Then connect the results to a governance process that actually owns remediation, so the inventory drives action rather than gathering dust. The goal is a continuously updated, prioritized view that turns "we should migrate someday" into "here is exactly what we are migrating, in what order, and why": the difference between hoping you are quantum-ready and knowing it.