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 CBOM 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.

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. The alternative is to approach PQC migration blind, with no reliable way to estimate costs, timelines, or resource requirements.

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.

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.

What a CBOM Should Include

A comprehensive CBOM captures multiple categories of cryptographic information, along with the relationships and dependencies between them. The CycloneDX standard, which has emerged as a leading format for CBOMs, provides a structured framework for representing this information.

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.

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 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. It answers questions like: does this software version support deprecated algorithms? Does it include vulnerable cryptographic libraries?

The inventory perspective provides the operational visibility needed for day-to-day cryptographic management, compliance reporting, and transformation planning. It answers questions like: which algorithms are actually in use in our production environment? When do our certificates expire? How are our keys being managed?

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, including software analysis tools, network scanning, configuration management systems, and certificate management platforms, 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.

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.

This is particularly challenging in environments with rapid deployment cycles, where new services may be introduced without cryptographic review. Integration with CI/CD pipelines and change management processes helps maintain CBOM currency.

Technical outputs requiring business context

The discovery tools now emerging to support CBOM creation generate highly technical outputs. Translating these into information that supports business decision making, risk assessment, and executive reporting requires additional effort and expertise. A list of algorithms and certificates is valuable, but it becomes actionable only when contextualised against business services, risk appetite, and strategic priorities.

This translation layer is often where organisations struggle most. Technical teams can generate detailed inventories, but connecting those inventories to business value and risk requires collaboration with stakeholders who understand the business context.

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.

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.

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.

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.

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.

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.

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 CBOM, 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.

‍