As organisations prepare for the transition to post-quantum cryptography, one requirement has emerged as foundational: knowing what cryptographic assets you actually have. This is where the Cryptographic Bill of Materials, or CBOM, becomes essential.

A Cryptographic Bill of Materials is a structured, comprehensive inventory of all cryptographic components within your systems and applications. It catalogues the algorithms, libraries, certificates, keys, and protocols that underpin your digital security, along with the relationships and dependencies between them.

The concept builds on the Software Bill of Materials (SBOM), which has gained significant traction in software supply chain security. Where an SBOM documents the software components and dependencies within an application, a CBOM extends this principle specifically to cryptography, providing visibility into the cryptographic foundations that protect your data, communications, and digital identities.

For UK organisations navigating an increasingly complex threat landscape, understanding and implementing CBOMs is no longer optional. It is becoming a prerequisite for effective cryptographic governance, regulatory compliance, and readiness for the quantum computing era.

What is a Cryptographic Bill of Materials (CBOM)?

A Cryptographic Bill of Materials — commonly abbreviated to CBOM — is a detailed, machine-readable record of every cryptographic asset deployed across an organisation’s technology estate. It answers a deceptively simple question: what cryptography are we actually using, and where?

In practice, a CBOM captures the specific algorithms configured in production systems, the cryptographic libraries applications depend on, the certificates securing communications and identities, the keys protecting data at rest and in transit, and the protocols governing how all of these components interact. Crucially, it also records the dependencies between them — which application relies on which library version, which service depends on which certificate chain.

The CycloneDX standard has emerged as the leading format for representing CBOMs, providing a structured schema that supports automation, integration with security tooling, and interoperability across supply chains.

Without a CBOM, organisations are essentially operating blind. They cannot scope a PQC migration with any accuracy, they cannot respond quickly when a cryptographic vulnerability is disclosed, and they cannot demonstrate to regulators that their cryptographic estate is under control.

Why CBOMs Matter Now

The urgency around cryptographic visibility has intensified for several interconnected reasons. Understanding these drivers helps organisations appreciate why CBOM initiatives warrant priority attention and investment.

The Post-Quantum Imperative

Quantum computing poses a fundamental threat to the cryptographic algorithms that currently secure most digital systems. When sufficiently powerful quantum computers become available, they will be capable of breaking widely used public-key cryptography, including RSA and elliptic curve algorithms. This is not a theoretical concern for the distant future. The G7 Cyber Expert Group has set 2035 as the target date for financial services to complete their transition to post-quantum cryptography, and guidance from bodies including NIST, NSA, and NCSC makes clear that planning must begin now.

Before any organisation can migrate to quantum-resistant algorithms, it must first understand where cryptography is currently deployed. A CBOM provides exactly this foundation. Without it, organisations cannot accurately scope the transition, prioritise remediation efforts, or track progress over time.

NIST has now finalised the first set of post-quantum cryptographic standards, including ML-KEM (formerly CRYSTALS-Kyber) for key encapsulation and ML-DSA (formerly CRYSTALS-Dilithium) for digital signatures. These standards represent the algorithms that will eventually replace current cryptographic implementations. But adoption cannot begin until organisations understand their current state. For a detailed walkthrough of the NIST standards, see our guide to navigating the NIST PQC roadmap.

Harvest Now, Decrypt Later

The threat is not confined to some future date when quantum computers arrive. Sophisticated adversaries, including nation-state actors, are already harvesting encrypted data today with the intention of decrypting it once quantum capabilities become available. This strategy, known as Harvest Now, Decrypt Later (HNDL), means that data encrypted with vulnerable algorithms today may be exposed in the future.

For organisations handling data that retains its sensitivity over long periods — whether government secrets, intellectual property, health records, or commercially sensitive information — this presents an immediate risk that requires immediate action. A CBOM helps identify which systems and data flows are most vulnerable to this threat, enabling targeted protection of the most sensitive assets.

The key questions for boards and security leaders are: which of our data remains sensitive for ten, twenty, or more years? Could that data realistically be harvested by capable adversaries today? Do we have plans to protect those flows with quantum-resistant controls? Answering these questions requires the visibility that a CBOM provides.

Regulatory and Compliance Pressure

Regulatory 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 their cryptographic assets. A CBOM provides the structured, auditable evidence that regulators and auditors require.

In the UK, organisations operating in regulated sectors face growing scrutiny of their cryptographic practices. The Financial Conduct Authority, the Information Commissioner’s Office, and sector regulators increasingly expect organisations to demonstrate that they understand and manage their cryptographic estate. A CBOM provides the documentary foundation for such demonstrations.

Operational Resilience

Certificate-related outages continue to cause significant disruption across industries. When an organisation lacks visibility into its certificate estate, expired certificates can bring down critical services without warning. High-profile incidents have affected major technology companies, airlines, and financial institutions, causing service outages that cost millions in lost revenue and reputational damage.

A CBOM, maintained as part of ongoing cryptographic governance, enables proactive management that prevents such incidents. When organisations know what certificates they have, where they are deployed, and when they expire, they can ensure timely renewal and avoid the costly disruption of unexpected outages. Pairing a CBOM with a certificate lifecycle management solution turns visibility into automated action.

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:

‍

Algorithms and Modes

At the core of any CBOM is an inventory of the cryptographic algorithms in use across the environment. This includes 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 are supported by a given system, but which are actively configured and in use.

This granularity is essential for identifying deprecated or weak algorithms that require remediation, as well as for scoping the eventual transition to post-quantum alternatives. An algorithm that is merely supported but not used presents less immediate risk than one actively protecting sensitive data.

Cryptographic Libraries and Modules

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

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

Protocols and Versions

Cryptographic protocols govern how algorithms are applied in practice. A CBOM should capture which protocols are in use, including TLS versions, SSH configurations, IPsec profiles, and any application-specific cryptographic protocols. Protocol version information is particularly important, as older versions often contain known vulnerabilities or support weak cipher suites.

For example, TLS 1.0 and 1.1 are now deprecated and should not be used, yet many organisations still have systems that support or even require these older protocol versions. A CBOM highlights such issues, enabling targeted remediation. For more context on protocols, see our explanation of digital certificates, SSL/TLS, and X.509.

Certificates and Trust Anchors

Digital certificates are among the most visible cryptographic assets, yet many organisations lack complete visibility into their certificate estate. A CBOM should document certificates across the environment, including issuing authorities, validity periods, key types and sizes, subject alternative names, and key usage attributes.

The scale of this challenge should not be underestimated. A typical Windows environment may contain between 80,000 and 500,000 certificates when accounting for both organisationally deployed certificates and those shipped with the operating system and applications. Red Hat Linux systems typically contain between 200 and 20,000 certificates. iOS devices can hold 40,000 to over 200,000 certificates. Manual tracking at this scale is simply not feasible.

Keys and Secrets Metadata

While a CBOM should never contain actual cryptographic keys or secrets, it should document metadata about key material: key types, lengths, storage locations, rotation policies, and the systems or services that depend on them. This information supports both security assessment and operational planning.

Understanding where keys are stored is particularly important. Keys protected by hardware security modules (HSMs) present different risk profiles than those stored in software keystores. A CBOM should capture these distinctions to support accurate risk assessment.

Usage Context and Dependencies

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

This contextual information transforms a CBOM from a static inventory into a tool for risk-based decision making. It enables organisations to prioritise remediation based on business impact, not just technical severity.

CBOM vs SBOM: What is the Difference?

The terms CBOM and SBOM are sometimes used interchangeably, but they serve distinct purposes that are worth understanding clearly.

A Software Bill of Materials (SBOM) is a comprehensive inventory of the software components, libraries, and dependencies within an application or system. SBOMs have become standard practice in software supply chain security, enabling organisations to track open-source components, identify known vulnerabilities, and manage licensing obligations. Frameworks such as the US Executive Order on Improving the Nation’s Cybersecurity and the EU Cyber Resilience Act have cemented SBOMs as a regulatory expectation.

A Cryptographic Bill of Materials (CBOM) narrows this lens specifically to cryptographic assets. Rather than cataloguing all software dependencies, a CBOM inventories the algorithms, keys, certificates, protocols, and cryptographic libraries that protect data and communications. While 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.

The two inventories are complementary, not competing. An SBOM provides breadth across all software components; a CBOM provides depth on cryptographic specifics. For organisations preparing for post-quantum cryptography, the CBOM is indispensable — it is the CBOM, not the SBOM, that identifies which algorithms need replacing when quantum-resistant standards take effect.

CBOM Versus Cryptographic Inventory: Understanding the Distinction

There is an important distinction between a CBOM in its narrower sense and a comprehensive cryptographic inventory, though the terms are sometimes used interchangeably.

A CBOM, as originally conceived, focuses primarily on the cryptographic capabilities built into software applications. It documents what algorithms, libraries, and protocols a given piece of software supports or includes. This information is typically derived from source code analysis or software composition analysis and is tied to specific software versions or releases.

A cryptographic inventory takes a broader view. It encompasses not just built-in capabilities but also how cryptography is configured and used within a specific organisational context. It captures operational details such as which algorithms are actually enabled, how keys are provisioned and rotated, and how cryptographic controls are applied to protect specific data and services.

Both perspectives are valuable, and in practice, organisations need both. The CBOM perspective helps identify potential vulnerabilities in software before deployment and supports software supply chain security practices. The inventory perspective provides the operational visibility needed for day-to-day cryptographic management, compliance reporting, and transformation planning.

For most UK enterprises, the practical goal is a unified view that combines software-level cryptographic capabilities with operational configuration and usage data. This requires collecting information from multiple sources and normalising it into a coherent inventory.

Common Challenges in Building a CBOM

Organisations undertaking CBOM initiatives typically encounter several challenges that must be anticipated and addressed.

Scale and Complexity

Modern IT environments are vast and heterogeneous. Cryptography is embedded throughout — often invisibly — in applications, infrastructure, cloud services, endpoints, and operational technology. The sheer volume of cryptographic assets makes manual approaches impractical and demands automated discovery tooling.

Many organisations are surprised by the extent of their cryptographic footprint when they begin discovery exercises. Cryptography is often introduced without central oversight, through development choices, vendor products, and infrastructure defaults. The resulting estate is typically far larger and more complex than anticipated.

Fragmented Visibility

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

Building a unified CBOM requires bringing together data from multiple sources and organisational silos. This is as much an organisational challenge as a technical one, requiring collaboration across teams that may not traditionally work together. For guidance on managing certificates across these silos, see our post on making automation work across silos.

Dynamic Environments

IT environments are not static. Applications are deployed and retired, configurations change, certificates are issued and renewed, and new services are introduced. A CBOM that reflects a point-in-time snapshot quickly becomes outdated. Organisations need processes and tooling to maintain CBOM accuracy over time.

The CBOM as a Sensitive Asset

A comprehensive CBOM is itself a sensitive document. It provides a detailed map of cryptographic dependencies and potential weak points across the organisation. If this information were to fall into the wrong hands, it could inform targeted attacks. CBOMs must therefore be appropriately classified and protected, adding governance overhead that organisations must plan for.

CISOs should treat the CBOM as a high-value asset that requires appropriate access controls, storage security, and handling procedures.

A Practical Approach to CBOM Development

For organisations beginning their CBOM journey, a phased approach typically proves most effective.

1. Start with What You Know

Most organisations already have partial visibility into their cryptographic estate, even if that visibility is fragmented and incomplete. Certificate management platforms, PKI systems, and configuration management tools all contain relevant data. Consolidating existing information provides a starting point and helps identify 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 business processes warrant priority attention. A risk-based approach ensures that CBOM efforts deliver value quickly rather than becoming an exhaustive cataloguing exercise that delays meaningful action.

3. Deploy Appropriate Tooling

A new generation of discovery tools is emerging to support cryptographic inventory and CBOM creation. These tools can scan networks, analyse configurations, interrogate certificate stores, and identify cryptographic dependencies across the environment. While the tooling landscape is still maturing, automated discovery is essential for achieving comprehensive coverage at enterprise scale.

4. Establish Context and Ownership

Raw discovery data must be enriched with business context. Which services depend on which cryptographic assets? Who owns each system? What is the business impact if a certificate expires or an algorithm is compromised? Establishing this context transforms technical inventory data into information that supports decision making.

5. Integrate with Existing Processes

A CBOM delivers greatest value when integrated with existing security, risk, and IT management processes. This includes vulnerability management, change management, compliance reporting, and incident response. Integration ensures that CBOM data informs operational decisions and that the inventory remains current as the environment evolves.

6. Plan for Ongoing Maintenance

A CBOM is not a one-time deliverable. It must be maintained as a living inventory that evolves with the organisation’s technology estate. This requires defined processes, clear ownership, and appropriate tooling to detect changes and update the inventory accordingly.

The CBOM as Foundation for Cryptographic Agility

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

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

Cryptographic agility requires that organisations understand their current cryptographic dependencies, can identify what needs to change when new requirements emerge, and have architectures that support efficient updates. A well-maintained CBOM provides the visibility that makes this possible.

In practical terms, cryptographic 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 be changed via configuration rather than code rewrites. All of these capabilities depend on knowing what you have today.

How Unsung Supports CBOM and Cryptographic Inventory

At Unsung, 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 cryptographic inventories tailored to each organisation’s environment and requirements.

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

For organisations preparing for post-quantum cryptography, strengthening operational resilience, or improving cryptographic governance, a CBOM provides the essential foundation. Without visibility, there can be no effective management. With it, organisations can plan, prioritise, and act with confidence.

Conclusion

The Cryptographic Bill of Materials represents a fundamental shift in how organisations approach cryptographic management. Where cryptography was once treated as an invisible technical detail, the combination of quantum threats, regulatory pressure, and operational risk now demands explicit visibility and governance.

Building and maintaining a CBOM requires investment in tooling, processes, and expertise. But the alternative — continuing to operate without clear visibility into the cryptographic foundations of digital trust — carries risks that are no longer acceptable for organisations serious about security.

The question is not whether to develop a Cryptographic Bill of Materials, but how quickly and effectively you can establish the visibility your organisation needs. The sooner that foundation is in place, the better positioned you will be to address both current vulnerabilities and the cryptographic challenges that lie ahead.