A cryptography bill of materials (CBOM) is a structured inventory of the cryptographic assets used within software, systems, and infrastructure. It documents algorithms, protocols, keys, certificates, libraries, and their dependencies, enabling organizations to understand where cryptography is deployed, identify potential security risks, and manage cryptographic changes as standards, technologies, and threats evolve.
The OWASP CycloneDX CBOM specification provides a standardized approach to documenting cryptographic assets and their relationships, supporting cryptographic visibility and security assessments.
Key Points
Cryptographic Visibility: A CBOM identifies cryptographic algorithms, protocols, certificates, keys, libraries, and dependencies across software and systems.
Quantum Readiness: Cryptographic inventories help organizations identify quantum-vulnerable public-key cryptography and prioritize migration to post-quantum standards.
Living Inventory: A living CBOM is regularly updated to reflect changes in cryptographic assets, configurations, and dependencies.
Risk Management: CBOM information supports the identification, assessment, and prioritization of weak, deprecated, or vulnerable cryptography.
Cryptographic Agility: Understanding cryptographic dependencies helps organizations plan algorithm replacements and manage changes with less operational disruption.
Cryptography protects digital communications, financial transactions, sensitive information, authentication systems, and critical infrastructure. However, cryptographic components are frequently embedded within applications, software libraries, hardware, and third-party services, making it difficult for organizations to maintain a complete understanding of their cryptographic dependencies.
The transition to post-quantum cryptography (PQC) has increased the importance of this visibility. In August 2024, the National Institute of Standards and Technology (NIST) finalized three post-quantum cryptographic standards: FIPS 203, FIPS 204, and FIPS 205.
A sufficiently capable quantum computer could undermine widely deployed public-key algorithms, including RSA and elliptic curve cryptography. Although the timeline for such capabilities remains uncertain, organizations need to understand where vulnerable cryptography is deployed and how it affects interconnected systems.
The risk also extends to encrypted information collected today and retained for future decryption, commonly described as harvest now, decrypt later. The Canadian Centre for Cyber Security's PQC migration roadmap identifies this threat as an important consideration when prioritizing systems protecting sensitive information.
A CBOM provides the information needed to assess cryptographic exposure, identify dependencies, and plan changes as cryptographic standards and security requirements evolve.
A CBOM provides structured information that supports cryptographic risk management throughout the technology lifecycle.
| Benefit | Description |
|---|---|
| Cryptographic visibility | Identifies algorithms, protocols, keys, certificates, libraries, and their relationships |
| Vulnerability assessment | Helps determine which systems may be affected by cryptographic weaknesses or implementation vulnerabilities |
| Quantum readiness | Supports discovery of public-key cryptography requiring PQC migration |
| Dependency management | Identifies applications and services that depend on specific cryptographic components |
| Regulatory support | Provides information that may support applicable inventory, documentation, and risk-management obligations |
| Cryptographic agility | Helps assess the impact of replacing algorithms or modifying cryptographic implementations |
| Lifecycle management | Supports ongoing monitoring as cryptographic assets and standards change |
A CBOM represents the cryptographic composition of a system at a particular point in time. However, applications, infrastructure, and cryptographic implementations change throughout their operational lifecycles.
A living CBOM is an inventory that is regularly or continuously updated and validated to reflect those changes.
Software updates may introduce new cryptographic libraries, certificate renewals may change cryptographic characteristics, and infrastructure modifications may alter the protocols or algorithms used to protect communications. A static inventory can become inaccurate as these changes accumulate.
Maintaining a living CBOM enables organizations to identify changes in cryptographic dependencies, reassess exposure when vulnerabilities emerge, and monitor progress toward approved cryptographic configurations.
It also helps distinguish between cryptography that is present within a software component and cryptography that is actively used. This distinction matters because a library may support an algorithm without an application invoking it.
The OWASP CycloneDX specification supports documenting cryptographic assets and relationships, while the Canadian Centre for Cyber Security recommends iterative cryptographic inventory development.
A living CBOM should therefore be integrated into relevant development, deployment, change management, and security assessment processes rather than treated as a one-time documentation exercise.
A CBOM documents cryptographic assets and the relationships between them, providing a structured representation of how cryptography is implemented within a system.
According to the OWASP CycloneDX Authoritative Guide to CBOM, cryptographic information can be represented through several interconnected asset types.
| Component | Information documented |
|---|---|
| Cryptographic algorithms | Algorithm name, family, mode, and relevant properties |
| Cryptographic protocols | Protocol type, version, and associated cryptographic mechanisms |
| Cryptographic keys | Key type, length, algorithm association, and relevant metadata |
| Certificates | Certificate characteristics, issuer, validity, and signature information |
| Cryptographic libraries | Software components implementing cryptographic functions |
| Dependencies | Relationships between cryptographic assets, applications, and services |
The CBOM connects this information to the relevant software or system components. For example, an application may use a cryptographic library to establish TLS connections, authenticate users, or verify digital signatures. The inventory can document the algorithms involved and their relationships to the application.
These relationships help organizations understand which systems may be affected when a cryptographic component becomes vulnerable, deprecated, or requires replacement.
A CycloneDX Cryptography Bill of Materials (CBOM) is a standardized, machine-readable inventory that documents cryptographic assets and their relationships within software, applications, and systems. Developed through the OWASP CycloneDX project, it provides a consistent format for identifying cryptographic algorithms, protocols, keys, certificates, and related dependencies.
CBOM capabilities were introduced in CycloneDX 1.6 and are supported in subsequent versions of the specification.
CycloneDX supports cryptographic dependency relationships, including:
This distinction is important because a software library may support multiple cryptographic algorithms without an application actively using all of them.
By documenting cryptographic properties and dependencies in a machine-readable format, CycloneDX CBOMs help organizations evaluate cryptographic exposure, identify potentially vulnerable implementations, and plan post-quantum cryptography migration.
A Software Bill of Materials (SBOM) identifies software components and dependencies, while a CBOM focuses specifically on cryptographic assets and their relationships.
| Feature | Cryptography Bill of Materials (CBOM) | Software Bill of Materials (SBOM) |
|---|---|---|
| Primary purpose | Identify cryptographic assets and dependencies | Identify software components and dependencies |
| What it includes | Algorithms, keys, certificates, protocols, libraries, and configurations | Software packages, libraries, versions, suppliers, and dependencies |
| Security focus | Weak cryptography, deprecated algorithms, and quantum risks | Software vulnerabilities, dependency risks, and supply chain security |
| Quantum readiness | Identifies quantum-vulnerable cryptography requiring assessment or migration | Identifies software components that may require cryptographic updates |
| Risk assessment | Evaluates cryptographic algorithms, configurations, and dependencies | Evaluates software components, versions, and known vulnerabilities |
| Standards and formats | CycloneDX CBOM | CycloneDX, SPDX |
| Primary use cases | PQC migration, cryptographic inventory, crypto-agility, and cryptographic risk management | Vulnerability management, software supply chain security, and dependency tracking |
An SBOM may identify a cryptographic library used by an application, but that information alone does not necessarily establish which algorithms are implemented, which are actively used, or how cryptographic functions are configured.
A CBOM provides additional cryptographic detail, complementing software supply chain visibility rather than replacing it.
Both types of information can be represented using CycloneDX, standardized through Ecma International as ECMA-424.
Consider a financial services organization preparing for post-quantum cryptography migration.
The security team generates a CBOM for a customer-facing application and discovers that the application uses:
The CBOM helps the team identify which applications depend on RSA, determine where additional cryptographic assessment is required, and evaluate whether software upgrades or vendor coordination will be necessary.
The organization can prioritize quantum-vulnerable public-key mechanisms for migration while separately assessing symmetric encryption against applicable security requirements.
This example illustrates how a CBOM turns cryptographic inventory data into actionable migration planning.
A cryptography bill of materials supports post-quantum cryptography (PQC) migration by identifying quantum-vulnerable cryptographic algorithms, mapping their dependencies, and providing an inventory of systems that may require cryptographic updates.
Organizations can use CBOM data to support five migration activities:
A CBOM does not automatically replace vulnerable algorithms. It provides the visibility needed to plan and manage migration toward quantum-resistant cryptography.
Maintaining an accurate CBOM requires consistent discovery, validation, and integration with existing security processes.
The NIST National Cybersecurity Center of Excellence's Migration to Post-Quantum Cryptography project examines cryptographic discovery and inventory development as foundational activities for migration planning.
There is no universal legal requirement to maintain a standardized CBOM. However, certain government policies, cybersecurity regulations, and industry standards establish requirements for cryptographic inventories, software documentation, or related risk-management activities.
| Jurisdiction or standard | Relevant requirement | CBOM applicability |
|---|---|---|
| United States — Quantum Computing Cybersecurity Preparedness Act | Federal guidance for inventories of IT vulnerable to quantum decryption | Can support covered federal inventory activities; CBOM format not mandated |
| PCI DSS 4.0.1 | Requirement 12.3.3 addresses inventories and periodic review of cryptographic cipher suites and protocols | Can support relevant inventory documentation |
| European Union — Cyber Resilience Act | Software component documentation, including machine-readable SBOM requirements for covered products | CBOM may supplement required software documentation |
| European Union — NIS2 | Cybersecurity risk-management measures, including asset management and cryptographic policies for covered entities | May support related assessments and documentation |
| European Union — DORA | ICT asset identification, dependency documentation, and risk management for covered financial entities | May support cryptographic dependency visibility |
| United Kingdom — NCSC PQC Guidance | Recommended discovery and migration milestones for 2028, 2031, and 2035 | Supports recommended cryptographic discovery activities |
| Canada — Government PQC Migration Roadmap | Federal migration planning, cryptographic discovery, and priority migration milestones | Supports government cryptographic inventory development |
The distinction between mandatory requirements and recommended practices is important. A CBOM can provide supporting information for relevant obligations, but generating one does not independently demonstrate regulatory compliance.
Threat intelligence provides information about vulnerabilities, attack techniques, and emerging threats that may affect cryptographic assets. When combined with CBOM data, this information helps organizations determine which cryptographic dependencies require investigation, remediation, or migration.
Cryptographic threat intelligence can include newly disclosed vulnerabilities in cryptographic libraries, weaknesses in protocols, changes to algorithm recommendations, and evidence of exploitation affecting cryptographic implementations.
For example, when a vulnerability is identified in a cryptographic library, an organization can use its CBOM to identify applications and systems associated with the affected component. Additional analysis is necessary to determine whether the vulnerable functionality is actually used or exposed.
Public sources supporting these assessments include the NIST National Vulnerability Database, CISA Known Exploited Vulnerabilities Catalog, and CISA cybersecurity advisories.
Quantum computing introduces a longer-term risk to widely deployed public-key cryptography. The harvest now, decrypt later threat model describes the possibility that encrypted information collected today could be decrypted in the future using sufficiently capable quantum computers.
This is particularly relevant to information that must remain confidential for many years. The Canadian Centre for Cyber Security identifies this risk as a consideration in prioritizing PQC migration.
A CBOM can help organizations identify affected algorithms and dependencies, while cryptographic research and government security guidance inform the assessment of future exposure.
The combination supports both immediate vulnerability response and longer-term cryptographic modernization.
Creating a CBOM involves discovering cryptographic assets, documenting their characteristics, and maintaining a structured inventory as systems change.
The following process is consistent with the principles described in the OWASP CycloneDX CBOM guide and NIST's PQC migration research.
Once cryptographic assets have been identified, organizations can classify them according to their security characteristics and required actions.
| Assessment outcome | Recommended action |
|---|---|
| Meets current security requirements | Maintain and monitor |
| Usage or exposure is unknown | Investigate and validate |
| Weak, deprecated, or vulnerable | Prioritize remediation |
| Quantum-vulnerable public-key cryptography | Assess and plan PQC migration |
Prioritization should consider data sensitivity, confidentiality lifespan, system criticality, exploitability, external exposure, and dependencies on other systems or suppliers.
The Canadian Cyber Centre's PQC migration roadmap identifies factors such as confidentiality lifespan, harvest-now-decrypt-later exposure, and the consequences of compromise as considerations for migration prioritization.
A living CBOM can then support tracking changes and identifying cryptographic risks that remain unresolved.
Although a CBOM provides valuable cryptographic visibility, developing and maintaining an accurate inventory presents several challenges.
Incomplete discovery: Cryptographic functionality may be embedded in proprietary software, firmware, hardware, or third-party services that cannot be directly inspected.
Complex dependencies: A single cryptographic library or protocol may support multiple applications, making it difficult to determine the impact of replacing a component.
Implementation versus usage: Identifying an algorithm within a library does not necessarily establish that the application actively uses it.
Changing environments: Software updates, certificate renewals, infrastructure modifications, and new services can make static inventories outdated.
Inconsistent information: Different discovery methods and supplier documentation may provide incomplete or conflicting information about cryptographic assets.
Migration constraints: Some cryptographic implementations can be updated through software changes, while others require protocol modifications, hardware replacement, or coordination with external providers.
Addressing these challenges requires a combination of technical discovery, inventory validation, organizational ownership, and ongoing lifecycle management.
The adoption of post-quantum cryptographic standards is increasing the importance of maintaining accurate cryptographic inventories. As organizations assess existing public-key cryptography and introduce new algorithms, CBOMs can help document the transition and identify dependencies that require coordinated updates.
Three developments are particularly relevant.
Post-quantum migration: The NIST PQC standards establish standardized quantum-resistant algorithms, while government migration guidance encourages organizations to identify affected systems and plan the transition. CBOMs can support assessments of existing cryptography and documentation of replacement mechanisms.
Cryptographic agility: As cryptographic requirements evolve, organizations will need to update algorithms and implementations while maintaining compatibility across interconnected systems. Understanding cryptographic dependencies can help determine the impact of those changes.
Continuous cryptographic inventory management: Integration with software development, deployment, and change management processes can help maintain CBOM accuracy as environments change. The OWASP CycloneDX standard provides a machine-readable foundation for exchanging cryptographic asset information.
Together, these developments point toward cryptographic inventories becoming an ongoing component of security operations and technology lifecycle management rather than a one-time assessment conducted during migration.
