What is a CBOM? Cryptographic Bill of Materials Explained

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset in an organisation's technology estate — the algorithms, libraries, certificates, keys and protocols that protect your data, along with the dependencies between them.

It answers a deceptively simple question: what cryptography are we actually using, and where?

For organisations preparing for post-quantum cryptography, that question has become foundational. You cannot migrate cryptography you have not inventoried, and you cannot scope a programme against an estate you cannot see.

You may occasionally see the same concept described as a QBOM, or quantum bill of materials. CBOM is the established term and the one the tooling uses.

Key points

• A CBOM narrows the SBOM concept specifically to cryptography — depth on algorithms and keys rather than breadth across all software components.
• CycloneDX is the established format, and being machine-readable is what makes a CBOM operationally useful rather than a document.
• The EU Cyber Resilience Act and post-quantum migration are the two drivers making this urgent rather than aspirational.
• A CBOM is itself a sensitive asset. It maps your cryptographic weak points.

CBOM vs SBOM: what is the difference?

This is the first question most people ask, and the answer is straightforward: an SBOM tells you what software you are running, a CBOM tells you what cryptography that software is actually using.

The clearest illustration is a single example. An SBOM might tell you that your application uses OpenSSL 3.1.4. A CBOM tells you that this instance of OpenSSL is configured to use AES-256-GCM for symmetric encryption, TLS 1.3 for transport, and an RSA-2048 key pair that expires in six months.

• Scope. An SBOM covers all software components, libraries and dependencies. A CBOM covers cryptographic assets only.
• Depth. An SBOM records that a cryptographic library is present. A CBOM records which algorithms, key lengths and protocol versions are configured and in use.
• Purpose. SBOMs support software supply chain security, vulnerability management and licensing. CBOMs support cryptographic governance, post-quantum migration planning and certificate operations.
• Source. SBOMs are typically produced at build time from software composition analysis. CBOMs also require runtime and configuration data, because what a system supports and what it actually uses are different things.

The two are complementary, not competing. An SBOM provides breadth; a CBOM provides depth on the cryptography. For post-quantum readiness specifically, it is the CBOM that matters — an SBOM will not tell you which RSA keys need replacing.

Both are increasingly expected by the same regulatory frameworks. The US Executive Order on Improving the Nation's Cybersecurity and the EU Cyber Resilience Act cemented SBOMs as a compliance expectation, and cryptographic visibility is following the same path.

‍

What a CBOM Should Include

A comprehensive CBOM captures multiple categories of cryptographic information, along with the relationships and dependencies between them. The table below summarises the core components:

Summarising the table

• Certificates are the most visible layer and rarely the most complete. Most organisations find more certificates than their records show, and the gap is made up of supplier-installed certificates, self-signed certificates in development environments, and certificates issued by cloud platform services outside central procurement.
• Algorithms need usage data, not just capability data. A system that supports a weak algorithm but never negotiates it carries less risk than one actively using it. Recording only what is supported inflates the remediation list and obscures the genuine exposure.
• Libraries drive your vulnerability response time. When a flaw is disclosed in OpenSSL or Bouncy Castle, the question is which systems are affected. With a CBOM that is a query. Without one it is a manual exercise measured in days.
• Protocols and hardware determine what can actually change. An HSM that cannot be updated to support post-quantum algorithms, or an appliance locked to an old TLS version, is a replacement rather than a reconfiguration. Identifying those early shapes the whole migration timeline.
• Keys are recorded by metadata only. A CBOM documents key types, lengths, storage locations and rotation policies. It never contains key material.

Algorithms and modes

Symmetric algorithms such as AES, asymmetric algorithms including RSA and elliptic curve variants, hash functions, key derivation functions and the specific modes of operation employed. The CBOM should capture not just which algorithms a system supports, but which are actively configured and in use.

This granularity is essential for identifying deprecated or weak algorithms requiring remediation, and for scoping the transition to post-quantum alternatives.

Cryptographic libraries and modules

Applications rarely implement cryptography directly. They rely on libraries such as OpenSSL, BoringSSL, Bouncy Castle or platform-native APIs. A CBOM should document which libraries are in use, their versions, and which applications depend on them.

This is critical for vulnerability management. When a flaw is discovered in a cryptographic library, organisations need to identify affected systems quickly. Without a CBOM this becomes a time-consuming and error-prone manual exercise that extends the exposure window.

Protocols and versions

Which protocols are in use, including TLS versions, SSH configurations, IPsec profiles and any application-specific cryptographic protocols. Version information matters particularly, as older versions often contain known vulnerabilities or support weak cipher suites.

TLS 1.0 and 1.1 are deprecated and should not be in use, yet many organisations still run systems that support or require them. A CBOM surfaces these for targeted remediation. For more context, see our explanation of digital certificates, SSL/TLS and X.509.

Certificates and trust anchors

Certificates across the environment, including issuing authorities, validity periods, key types and sizes, subject alternative names and key usage attributes.

The scale is the challenge. A single enterprise Windows estate, counting both organisationally deployed certificates and those shipped with operating systems and applications, routinely runs into tens or hundreds of thousands. Manual tracking at that scale is not feasible, which is why discovery has to be automated.

Keys and secrets metadata

A CBOM should never contain actual keys or secrets. It should document metadata: key types, lengths, storage locations, rotation policies and the systems that depend on them.

Storage location matters particularly. Keys protected by hardware security modules present a different risk profile from those in software keystores, and a CBOM should capture the distinction to support accurate risk assessment.

Usage context and dependencies

Most importantly, a CBOM should capture how cryptographic assets relate to business systems. Which applications depend on which certificates? Which services use which algorithms? How do cryptographic dependencies flow through the estate?

This contextual information is what transforms a CBOM from a static inventory into a tool for risk-based decision making, enabling prioritisation by business impact rather than technical severity alone.

CycloneDX and why format matters

CycloneDX has emerged as the leading format for representing CBOMs. It extends the existing SBOM schema with cryptographic asset types, which means the two inventories can coexist in one document and be consumed by the same tooling.

The schema covers algorithms and their parameters, certificates and their properties, protocols and versions, key material metadata, and — critically — the relationships between them. A CycloneDX CBOM can express that a given service depends on a given certificate, which chains to a given issuer, which uses a given algorithm.

Being machine-readable is the point. A CBOM in a spreadsheet is a document, and documents go stale. A CBOM in a structured format can be:

• Generated automatically by discovery tooling rather than assembled by hand.
• Queried when a vulnerability is disclosed, instead of searched.
• Diffed between scans to detect change.
• Fed into vulnerability management, SIEM and governance reporting.
• Exchanged with suppliers and customers as part of supply chain assurance.

Choosing a format early matters because it determines what tooling you can adopt later. Proprietary output from a single discovery tool creates a dependency that is expensive to unwind.

Why CBOMs matter now

The post-quantum imperative

Quantum computing poses a fundamental threat to the algorithms securing most digital systems. When sufficiently powerful quantum computers arrive, they will break widely used public-key cryptography including RSA and elliptic curve algorithms.

This is not a distant concern. The G7 Cyber Expert Group has set 2035 as the target for financial services to complete their transition, and guidance from NIST, NSA and NCSC is clear that planning must begin now.

NIST has finalised the first post-quantum standards, including ML-KEM for key encapsulation and ML-DSA for digital signatures. But adoption cannot begin until organisations understand their current state. For a walkthrough of the standards, see our guide to navigating the NIST PQC roadmap.

Harvest now, decrypt later

The threat is not confined to a future date. Sophisticated adversaries, including nation-state actors, are already collecting encrypted data with the intention of decrypting it once quantum capability exists. Harvest now, decrypt later means data encrypted with vulnerable algorithms today may be exposed in future.

For organisations handling data that retains sensitivity over long periods — government secrets, intellectual property, health records, commercially sensitive information — this presents an immediate risk. A CBOM identifies which systems and data flows are most exposed, enabling targeted protection of the assets that matter.

The EU Cyber Resilience Act

The Cyber Resilience Act is the most concrete regulatory driver for cryptographic visibility, and it applies to any organisation placing products with digital elements on the EU market — including UK manufacturers and software vendors selling into Europe.

The CRA requires manufacturers to identify and document the components in their products, manage vulnerabilities across the support period, and report actively exploited vulnerabilities. In practice that means:

• A bill of materials is mandatory, at minimum covering top-level dependencies. Cryptographic components fall squarely within scope.
• Vulnerability handling must be demonstrable for the product's support lifetime, which requires knowing which cryptographic libraries and versions are embedded.
• Security by design obligations mean weak or deprecated algorithms in shipped products become a compliance problem, not just a technical one.

Obligations phase in through 2026 and 2027. Organisations that already maintain an SBOM will find the cryptographic extension considerably less work than those starting from nothing.

Verify current CRA timelines and applicability against your own position — the phasing has moved before.

Wider regulatory pressure

Expectations around cryptographic management are tightening across multiple frameworks. From NIS2 in Europe to sector-specific requirements in financial services, healthcare and critical national infrastructure, organisations are increasingly required to demonstrate visibility and control over cryptographic assets. A CBOM provides the structured, auditable evidence regulators require.

Operational resilience

Certificate-related outages continue to cause significant disruption. Where an organisation lacks visibility into its certificate estate, expired certificates bring down critical services without warning. We have covered the real cost of expired certificates separately.

A CBOM maintained as part of ongoing governance enables proactive management. Pairing it with certificate lifecycle management turns visibility into automated action.

CBOM and cryptographic inventory

The terms overlap and are often used interchangeably, though there is a distinction worth knowing.

A CBOM, as originally conceived, focuses on the cryptographic capabilities built into software — what algorithms, libraries and protocols a given application supports, typically derived from source code or software composition analysis.

A cryptographic inventory takes the broader operational view: not just built-in capability but how cryptography is configured and used in your specific environment, including which algorithms are actually enabled and how keys are provisioned and rotated.

In practice organisations need both, and the useful goal is a unified view combining software-level capability with operational configuration. Our guide to building a cryptographic inventory covers the operational side in detail.

Common challenges

Scale and complexity

Modern IT environments are vast and heterogeneous, with cryptography embedded throughout — often invisibly — in applications, infrastructure, cloud services, endpoints and operational technology. The volume makes manual approaches impractical and demands automated discovery.

Most organisations are surprised by the extent of their cryptographic footprint when they begin. Cryptography is introduced without central oversight through development choices, vendor products and infrastructure defaults, and the resulting estate is consistently larger than anticipated.

Fragmented visibility

Cryptographic assets are typically managed, where they are managed at all, by different teams using different tools. Network certificates are handled separately from application certificates, which are handled separately from code signing. Cloud environments add further complexity through native services that may not integrate with on-premises tooling.

Building a unified CBOM means bringing together data across organisational silos. This is as much an organisational challenge as a technical one. For guidance, see our post on making automation work across silos.

Dynamic environments

Applications are deployed and retired, configurations change, certificates are issued and renewed. A CBOM reflecting a point-in-time snapshot goes stale quickly. Organisations need processes and tooling to maintain accuracy over time.

The CBOM as a sensitive asset

A comprehensive CBOM is itself sensitive. It provides a detailed map of cryptographic dependencies and potential weak points. In the wrong hands it would inform targeted attacks.

CBOMs must be classified and protected accordingly, with appropriate access controls, storage security and handling procedures. This adds governance overhead that should be planned for rather than discovered.

A practical approach to CBOM development

1. Start with what you know

Most organisations already have partial visibility, even if fragmented. Certificate management platforms, PKI systems and configuration management tools all contain relevant data. Consolidating what exists provides a starting point and identifies the most significant gaps.

2. Prioritise based on risk

Not all cryptographic assets carry equal risk. Externally facing systems, those handling sensitive data and those supporting critical processes warrant priority. A risk-based approach delivers value quickly rather than becoming an exhaustive cataloguing exercise that delays action.

3. Deploy appropriate tooling

Discovery tools can scan networks, analyse configurations, interrogate certificate stores and identify dependencies across the environment. The landscape is still maturing, but automated discovery is essential for comprehensive coverage at enterprise scale.

4. Establish context and ownership

Raw discovery data must be enriched with business context. Which services depend on which assets? Who owns each system? What is the impact if a certificate expires or an algorithm is compromised? Context is what turns inventory data into decision support.

5. Integrate with existing processes

A CBOM delivers most value when integrated with vulnerability management, change management, compliance reporting and incident response. Integration ensures the data informs operational decisions and that the inventory stays current.

6. Plan for ongoing maintenance

A CBOM is not a one-time deliverable. It is a living inventory that evolves with the estate, requiring defined processes, clear ownership and tooling to detect change.

CBOM readiness checklist

A short assessment of where you stand. Gaps here indicate where to start.

• Coverage. Does the inventory extend across on-premises, cloud, containers and operational technology, or only the systems that were easy to scan?
• Depth. Does it record algorithms, key lengths and protocol versions, or only certificate hostnames and expiry dates?
• Usage versus capability. Can you distinguish what a system supports from what it actually negotiates?
• Ownership. Does every asset have a named owner and an escalation path when that person leaves?
• Format. Is it machine-readable in an open standard, or is it a spreadsheet?
• Currency. Is discovery continuous, or was the inventory compiled once?
• Integration. Does CBOM data reach vulnerability management and change processes, or does it sit in isolation?
• Protection. Is the CBOM itself classified and access-controlled?
• Dependency mapping. Can you answer which business services are affected if a given certificate or algorithm fails?
• PQC readiness. Can you produce a list of every system using RSA or ECC, with an owner against each?

The CBOM as foundation for cryptographic agility

Beyond immediate risk management and compliance, a CBOM provides the foundation for cryptographic agility: the ability to adopt new algorithms and standards efficiently when required.

The post-quantum transition will not be the last time organisations need to update their cryptographic implementations. Standards evolve, vulnerabilities are discovered, new threats emerge. Organisations that can respond quickly without costly re-engineering hold a significant advantage.

In practical terms, agility means consolidating and modernising PKI services, decoupling cryptographic operations from applications using standardised APIs, automating certificate lifecycle management, and designing systems so algorithms can change through configuration rather than code. All of these depend on knowing what you have today.

How Unsung supports CBOM and cryptographic inventory

We work with UK government and enterprise clients to establish comprehensive visibility over their cryptographic estates. Our Cryptographic Bill of Materials service combines automated discovery with expert analysis to deliver actionable inventories tailored to each environment.

Our approach goes beyond asset discovery. We contextualise findings against business requirements, identify areas of concern and provide practical recommendations that support informed decisions. As a vendor-neutral consultancy, we focus on what is right for your organisation rather than promoting particular platforms.

A PKI health check is often the fastest route to a baseline, and our PKI consultancy team can translate the findings into a phased programme. Talk to our team to discuss scope.

Frequently asked questions

What does CBOM stand for?

CBOM stands for Cryptographic Bill of Materials. It is a structured inventory of every cryptographic asset in an organisation's estate — algorithms, libraries, certificates, keys and protocols — along with the dependencies between them.

What is the difference between a CBOM and an SBOM?

An SBOM inventories all software components and dependencies. A CBOM inventories cryptographic assets specifically, and in more depth. An SBOM might record that an application uses OpenSSL 3.1.4; a CBOM records which algorithms, key sizes and protocol versions that instance is actually configured to use. They are complementary, and for post-quantum planning it is the CBOM that matters.

What format should a CBOM use?

CycloneDX is the established standard. It extends the SBOM schema with cryptographic asset types, so both inventories can live in one document and be consumed by the same tooling. Machine-readable format is what allows a CBOM to be generated automatically, queried during incident response and compared between scans.

Do we need a CBOM for Cyber Resilience Act compliance?

The CRA requires manufacturers placing products with digital elements on the EU market to document components, manage vulnerabilities across the support period and meet security-by-design obligations. A bill of materials is required, and cryptographic components fall within scope. Organisations already producing an SBOM will find the cryptographic extension significantly less work than starting from nothing.

How do you build a CBOM?

Consolidate the visibility you already have from certificate management platforms and PKI systems, prioritise by risk rather than attempting complete coverage first, deploy automated discovery across networks and configurations, enrich the raw data with ownership and business context, then integrate the output into existing vulnerability and change processes. Maintaining it matters more than producing it.

What is the difference between a CBOM and a cryptographic inventory?

A CBOM in its original sense documents the cryptographic capabilities built into software, usually derived from code or composition analysis. A cryptographic inventory covers how cryptography is configured and used in your specific environment. Most organisations need both, combined into a single operational view.

Is a CBOM sensitive information?

Yes. It maps cryptographic dependencies and weak points across the organisation, which would be valuable to an attacker. Treat it as a high-value asset with appropriate classification, access controls and handling procedures.

How often should a CBOM be updated?

Continuously. Applications are deployed and retired, configurations change and certificates are issued daily. A point-in-time snapshot is out of date within weeks, which is why automated discovery and a machine-readable format matter more than the initial exercise.