Rethinking the CBOM

The certificate nobody had mapped

On December 6, 2018, mobile networks in eleven countries failed within the same few hours. In the United Kingdom, roughly 32 million O2 subscribers lost 4G data and text messaging for most of a working day, and SoftBank customers in Japan lost service too. The cause was an expired software certificate inside an Ericsson network element. O2 later sought £100 million in compensation from the vendor.

No attacker was involved and no vulnerability was exploited. A cryptographic object reached its expiry date inside infrastructure that nobody had mapped closely enough to know the date was coming.

The pattern repeats often enough to be a category rather than an anecdote. In 2017, an expired certificate on a traffic inspection device at Equifax left that device unable to decrypt and examine outbound traffic, and attackers moved personal data out of the network for 76 days before anyone noticed. The congressional investigation that followed found hundreds of expired certificates across the organization, dozens of them on business-critical domains, and concluded that a certificate management process with defined ownership would have kept the inspection device running when the intrusion began. In February 2020, an unrenewed authentication certificate took Microsoft Teams offline for hours. Microsoft ships a monitoring product designed to catch exactly that condition.

Keyfactor’s 2024 PKI and Digital Trust Report puts a number on the underlying condition: a majority of surveyed organizations, 53 percent, still could not say how many keys and certificates they hold. The same report found that certificate-caused outages arrive at a rate of about three every 24 months for the average organization.

Cryptography is an infrastructure layer that behaves like a feature, and almost no organization holds an accurate, current map of where it operates, what it protects, and what stops working when it changes.

That gap is what the Cryptographic Bill of Materials was invented to close. It is also the reason so many CBOM programs produce a document and then stop.

What a CBOM is, in one minute

A Software Bill of Materials, or SBOM, is the ingredients list for a piece of software: the components it contains and the dependencies between them. A Cryptographic Bill of Materials, or CBOM, is the ingredients list for the security assumptions that software depends on. It records cryptographic assets such as algorithms, protocols, certificates, keys and libraries, along with the relationships that turn “this exists somewhere” into “this is used here, by this thing, for this purpose.”

The specification most people mean when they say CBOM is OWASP CycloneDX, a machine-readable bill-of-materials format. CBOM entered CycloneDX in version 1.6, released in April 2024, based on work contributed by IBM Research. CycloneDX itself was ratified as ECMA-424 in June 2024, which is what turns a community format into something a procurement team can reference in a contract. A later revision added a cryptography registry that standardises how algorithm families are named, so that two tools scanning the same system produce comparable output.

Machine readability is the point. Cryptography is buried inside components, and structured data is the only way a tool can reason across thousands of systems. That distinction separates a slide deck about cryptography from an engineering artefact that can drive migration sequencing, audit evidence and vendor requirements.

And then the word “inventory” does its damage. People hear inventory and think census. CBOM programs die when completeness becomes the pass condition.

Why inventory everything stalls

Enterprises are good at counting things. Servers, applications, endpoints, licences, controls. Cryptography looks like it belongs on that list, so the instruction becomes: enumerate the algorithms, count the certificates, publish the register.

Cryptography resists that treatment for three reasons, and each one is structural rather than a matter of effort.

Cryptography is often a runtime outcome, not an installed component. Developers rarely call RSA or ECDH directly. They consume cryptography through protocols such as TLS and IPsec, and through certificates, keys and tokens issued elsewhere. As crypto-agility spreads, the algorithm in use gets negotiated per session or set at deployment rather than written into source code. Your posture therefore changes when a TLS policy changes, when a load balancer is upgraded, when a service mesh rolls out stricter defaults, or when a software-as-a-service provider updates its stack without telling you. A complete inventory of code tells you what is possible, not what happened at 09:14 this morning.

Implementation is not usage. CycloneDX models this explicitly, and the distinction sounds academic right up to the moment it produces a wrong migration plan. A library can implement an algorithm that nothing in your application ever calls. A platform can ship cryptographic capability that your deployment never enables. The specification separates a component that provides cryptographic capability from one that uses it, and it warns directly that the presence of an implementation does not imply the implementation is in use. A CBOM that cannot make that distinction generates false alarms in one direction and false confidence in the other.

Large parts of the estate are contractually opaque. Appliances, telecom network elements, embedded controllers, managed security platforms and vendor software all contain cryptography you have no right to inspect. This is not a tooling problem you can solve with a better scanner.

Programs that insist on completeness anyway tend to arrive at one of two outcomes. The first is a detailed, static register that was already wrong on the day it was published. The second is continuous discovery work that never converts into prioritisation or migration sequencing. Both feel productive until someone asks the CBOM a real question, such as which systems migrate first, or whether a legacy cipher suite can be disabled without breaking a revenue path.

What the policy actually asks for

The most useful correction to the completeness instinct is to read what governments actually require, rather than what people assume they require.

OMB Memorandum M-23-02, issued on November 18, 2022, directs United States federal agencies to produce a prioritized inventory of cryptographic systems. It scopes that inventory to High Value Assets, meaning systems whose loss would seriously damage the agency mission, and to systems the agency judges particularly exposed to a cryptographically relevant quantum computer, or CRQC, which is a quantum computer capable of breaking today’s public-key algorithms. It defines cryptographic systems functionally, in terms of key creation and exchange, encrypted connections and digital signatures. It set a first submission date of May 4, 2023 and an annual cadence thereafter, running to 2035.

Prioritized. Scoped to impact. Repeating. Not “enumerate everything by the end of the quarter.”

The 2024 report on post-quantum cryptography from the Office of the National Cyber Director (ONCD) goes further and says the quiet part in a policy document. Automated cryptographic inventory tools are improving and can accelerate the work, but they may not identify every instance of public-key cryptography, because a tool rarely has visibility across an entire network and rarely supports every system on it. Manual inventory work therefore remains a requirement, and the process is described as iterative and ongoing, needing sustained investment as systems are patched, updated and refreshed. The same report projects $7.1 billion in 2024 dollars for United States government migration between 2025 and 2035, which is a useful reminder that inventory quality determines spending quality.

CISA, the NSA and NIST published a joint factsheet in August 2023 with a section on preparing a cryptographic inventory. It tells organizations to run discovery across network protocols, end-user systems, servers, and code and dependencies in the build pipeline. It also warns that discovery tools will not find cryptography embedded inside products.

The Post-Quantum Cryptography Coalition (PQCC), led by MITRE, published a migration roadmap in 2025 that pushes the same realism from the execution side. Prioritise assets by sensitivity and lifespan. Document architectural designs, protocols and interfaces for the assets that carry weight. And then the instruction most enterprise programs skip because it is uncomfortable in a steering committee: document what you do not know. Work from the financial sector’s FS-ISAC group names the specific blind spots to expect, including offline keys, keys held in file structures no network scanner can reach, and keys in formats nothing recognises.

The European picture

The European Union arrived at the same operating model by a different route. The Coordinated Implementation Roadmap for the transition to post-quantum cryptography, published on June 23, 2025, sets three dates: Member States begin the transition and establish cryptographic inventories by the end of 2026, high-risk systems are protected by the end of 2030, and the transition completes by the end of 2035. The roadmap names CBOM directly as a standardised format for holding that inventory, which is among the first policy-level endorsements of the specification by name.

Around it sit obligations that already bite. NIS2 has applied since October 2024 and requires cryptographic policies that account for the state of the art, which is crypto-agility written in regulatory language. DORA has applied to financial entities since January 2025 and requires cryptographic controls with documented governance. On the defence side, the NSA’s CNSA 2.0 suite sets 2035 as the completion date for national security systems, and no organization can demonstrate compliance without knowing what it has deployed.

Read across all of it and one instruction is consistent. Build a capability that improves. Do not attempt a perfect snapshot and then stop.

A trust map, not a census

Here is the position we teach at Quantum Academy, and it decides everything downstream.

Attempting a complete CBOM is like attempting to inventory every pipe, valve and gasket in a city’s water system. It can be done on paper, given years of surveying basements, alleys, undocumented renovations and privately owned plumbing that happens to connect to public mains. Even then the survey misses the emergency bypasses added during an outage and the unlabelled fixes that kept a hospital supplied at three in the morning.

What a utility actually operates from is a hydraulic map. It shows where the mains run, where pressure concentrates, which districts depend on which reservoir, and which valves must not be closed without a shutdown plan. It is smaller than the census and far more useful, because it answers the questions that arise under pressure.

The first version of a CBOM should be that map, and the objects on it are these.

Trust anchors. Root certificate authorities, internal public key infrastructure (PKI, the system that issues and validates your certificates), cloud key management services and hardware security modules (KMS and HSM, the platforms that generate, store and control access to keys), code and firmware signing infrastructure, identity providers, and hardware roots of trust.

Termination points. Where TLS or IPsec ends. Where traffic is decrypted for inspection and re-encrypted. Where a tunnel you describe as end-to-end is in fact terminated by an intermediary you do not operate.

Interfaces and flows. What crosses which boundary, what protects it in transit and at rest, and which team controls the setting.

Ownership and change control. Who can rotate a key, upgrade a library, change a cipher policy, approve an outage window, or open a change request with a vendor.

That is an architecture exercise, not a code-scanning exercise. Code scanning supplies evidence. Architecture supplies scope and sequence. Work in telecommunications has already demonstrated the pattern at scale: rather than treating a radio access network as one undifferentiated block of cryptography, teams decompose it by component, plane and interface, then record cryptographic mechanisms in that context. The result is traceable because the architecture is traceable. Every enterprise is an arrangement of components and interfaces, so the same move works outside telecom.

Three imperfect pictures

A working CBOM is triangulated rather than authored. You take three partial views of reality and overlay them until the intersections become facts you can act on.

People, interviewed for boundaries

Ask an application team which algorithms they use and you will usually get a guess, a library name, or an answer that holds true in one environment. Layered platforms and negotiated protocols make that guess unavoidable from inside a delivery team.

Ask boundary questions instead, and you get architecture:

• Where does TLS terminate, and why there? The ingress controller, the load balancer, the service mesh, an appliance?
• Which integrations use mutual TLS, meaning both sides present certificates, and who issues and rotates them?
• Where do private keys live, and can they be exported? An HSM, a cloud KMS, a filesystem, a secret store, a vendor-managed vault you cannot open?
• What stops working if the issuing certificate authority is rotated? Which systems pin certificates or embed a public key in firmware?

These read as operational questions. They are actually the fastest route to a CBOM, because they locate the choke points where a post-quantum migration, or even a routine cipher policy change, either passes quietly or breaks a dependency chain.

Paper, already in the building

Most organizations already hold a partial CBOM under other names. Configuration and infrastructure inventories describe what exists. Application portfolio records describe what the business believes exists, which is often a different list. Business impact assessments describe what hurts when it stops. Network diagrams and segmentation models describe where the trust boundaries were meant to be. PKI documentation and certificate inventories describe the identity spine. Vendor solution designs describe the inside of the black box, or at least the part the vendor will put in writing.

Individually, none of these is a CBOM. Together they answer the founding questions: what exists, who owns it, what does it touch. The PQCC roadmap says to start from information already available and only then decide what additional discovery is needed.

Treat these documents as the first draft of the index, then use discovery tooling to confirm, enrich and contradict them. The contradictions are the valuable output. A diagram that says one thing while the network negotiates another is a finding, and usually an important one.

Packets, instrumented where it changes the plan

NIST’s National Cybersecurity Center of Excellence (NCCoE) runs a migration project with dozens of participating organizations, and its cryptographic discovery volume, SP 1800-38B, treats discovery as a structured engineering activity with a test plan, use cases and a reference architecture. It identifies CBOMs as a way to report cryptography use in a standard form. The same testing showed that no single product finds every instance of vulnerable cryptography, which is why a multi-tool approach is the baseline rather than a luxury.

So the posture is narrow on purpose. Run automated discovery where you have coverage and permission. Treat a clean result as unknown rather than safe. Concentrate manual effort where a finding would change the migration plan: high value assets, internet-facing boundaries, partner connections, identity roots, and long-lived sensitive data flows.

The Minimum Viable CBOM

SBOM learned this lesson first. The NTIA published minimum elements for an SBOM in July 2021, establishing a small set of required fields and machine-readability expectations, on the reasoning that transparency initiatives only scale when there is an adoptable floor. CISA revised those minimum elements in 2025. CBOM needs the same discipline, and the CycloneDX object model already supports it, because it can express assets, properties and dependencies without demanding an encyclopaedia.

Four layers, in this order.

Layer A. The index

System-level and ownership-level facts, for every system in scope.

Business owner. Technical owner and operator. Environment scope, whether on-premises, cloud, software-as-a-service or hybrid. Criticality rating drawn from the business impact assessment. Data types held, and how long that data must stay confidential. Trust dependencies, meaning the PKI, identity provider, KMS or gateway the system relies on.

This layer contains almost no cryptographic detail, and it is the one that converts CBOM from a specialist curiosity into a portfolio a program office can govern. It matches how OMB frames the requirement: prioritized, scoped, tied to impact and to how long protection must hold.

Layer B. The crypto surface map

Interfaces and trust boundaries, for the systems that reached the top of Layer A.

For each system, record the interfaces where cryptography does real work: application programming interface ingress, partner links, service-to-service calls, administrative access paths, replication and backup flows. Record where encryption terminates, where traffic is inspected, where it is re-encrypted, and which team owns each of those controls.

This is where a vague statement becomes an actionable one. “The application uses TLS” supports no decision. “TLS terminates at the edge, traffic is decrypted for inspection by a network appliance and re-encrypted onward, and the cipher policy belongs to the platform team rather than the application team” tells you who to call, what to test, and what the change window looks like.

Layer C. Evidence

Cryptographic detail, gathered only where you intend to act.

Public-key mechanisms in use, with key establishment and digital signatures as the two pressure points for post-quantum work. Certificate properties: algorithm, key size, expiry, issuer. Libraries and versions. Key lifecycle practice, covering generation, storage, rotation, backup and escrow.

Apply the provides-versus-uses distinction throughout this layer. Recording that a library supports an algorithm, without recording whether anything calls it, produces a register that generates work without reducing risk.

Layer D. Known unknowns

The layer that protects the program’s credibility.

Write down the blind spots by name: vendors who will not disclose, unmanaged endpoints, offline keys, key stores you cannot reach, formats nothing parses, systems where you hold neither the contractual right nor the technical means to look inside.

A CBOM that records its own uncertainty can be improved on a schedule. A CBOM that projects certainty becomes a liability the first time a leadership team treats it as complete during planning, procurement or a risk acceptance decision.

What to map first

Once completeness stops being the goal, prioritisation becomes the discipline that makes the work finite. The PQCC rule is short enough to remember: prioritise by sensitivity and by lifespan. Four categories tend to rise to the top in practice.

Identity and trust anchors. PKI, signing infrastructure, authentication. These are multiplicative dependencies. Rotating a root certificate authority affects every system that trusts it, and the count is almost always higher than the diagram suggests.

Externally exposed encrypted interfaces. Customer-facing services and partner links, because an adversary chooses when and how to interact with them, and because regulators look there first.

Long-retention sensitive data. This is the harvest-now-decrypt-later problem: an adversary records encrypted traffic today and decrypts it years later, once a capable quantum computer exists. The relevant arithmetic is a subtraction. If data must stay confidential for twenty years and your migration will take a decade, the deadline has already passed.

Legacy islands. Systems where change is slow, vendor-dependent and politically difficult. CISA’s guidance on operational technology, published in 2024, warns that OT systems, meaning the control systems running physical processes, may be the last platforms to reach post-quantum readiness, because patch cycles are long, hardware lifetimes are longer, and change procedures are strict for good safety reasons.

At this point the CBOM stops being an inventory and starts generating a roadmap, which is the test of whether it was built correctly.

Keeping it current

A CBOM you cannot maintain is a historical document. In environments shaped by cloud migration, acquisitions and continuous delivery, it does not decay gradually. It goes wrong quickly and then keeps looking authoritative.

CycloneDX supports a modular structure, so different teams can own different parts under different access rules, and that is the shape maintenance has to take. Stop trying to centralise everything into one register and build a federated model where authoritative sources feed the CBOM directly. Three workflows, running in parallel:

• For software you build, CBOM generation joins release governance and then the build pipeline, in the same way SBOM did.
• For platforms you operate, certificate inventories, TLS policies, service mesh configuration and KMS or HSM records become authoritative feeds rather than periodic surveys.
• For products you buy, procurement and vendor risk management start asking for cryptographic transparency, whether as a CBOM, a published roadmap or a written attestation. You cannot migrate what you cannot influence, and the contract renewal is the moment of maximum influence.

The test is unchanged from the first week. Can the CBOM tell you what stops working if you rotate a given key or authority, and can it tell you where a legacy algorithm is still being negotiated? If not, you have a report rather than an engineering asset.

The state of the tooling

Honesty here saves programs from disappointment. The most mature open-source effort is IBM’s CBOMkit, released through the Linux Foundation, which provides source code scanning, container and directory scanning, a viewer and a compliance check that can be wired into a build pipeline. Its own documentation is candid about the limits: it scans repositories without building them first, which reduces completeness.

Commercial cryptographic discovery products are arriving quickly, and several are capable. The caveat that applies across all of them was put most directly by Keyfactor, whose analysis observes that a CBOM reflects built-in capability rather than configuration, and will not tell you whether an organization is actually using SHA-1 or SHA-256 when a library supports both. Their conclusion is that a CBOM is necessary and not sufficient.

That sits comfortably with the NCCoE test results and with the ONCD report’s warnings. No single tool finds everything. People, paper and packets, applied iteratively, is how a functioning program gets designed.

What architects own

The CBOM ideal, a catalogue of every cryptographic asset everywhere, sounds like responsible governance. In practice it produces an artefact that cannot sequence a migration.

The alternative changes the objective, on four axes. From completeness to decision usefulness. From cryptographic inventory to trust mapping. From a one-time deliverable to a capability with an owner and a budget. From finding everything to finding what carries the most consequence first, and writing down what you could not see.

That’s a harder standard, not a softer one. It requires an architect to make judgements about scope, blast radius and sequence that no scanner will make for them, and to defend those judgements to a steering committee that would prefer a complete-looking spreadsheet. It also happens to describe how cryptography actually exists in modern systems: negotiated, layered, embedded, vendor-mediated and constantly changing.

If you’re building this capability now, three next steps are worth taking in order. Draft a Layer A index for your ten most critical systems, using documents you already hold, and see how many owners you cannot name. Run boundary interviews on the three that came back thinnest. Then start Layer D, because your list of known unknowns will tell you more about your real exposure than the first pass of any discovery tool.

Quantum Academy’s post-quantum training covers cryptographic discovery and inventory design as an architecture discipline, including how to build and maintain a Minimum Viable CBOM, how to sequence migration by sensitivity and lifespan, and how to write vendor requirements that produce usable answers. Current programs and enrollment details are at quantumacademy.com/.

For migration methodology beyond inventory, the framework at pqcframework.org covers the phases that follow discovery. For deeper technical treatment of the CBOM specification itself, see the analysis at PostQuantum.com. If you are weighing this as a career direction rather than a current assignment, QuantumCareers.com maps the roles that cryptographic inventory work leads into.