Crypto Bill of Materials (CBOM), Explained

CBOMs are SBOMs for cryptography, tracking your organization's use of cryptography for quantum migration or vulnerability remediation.

A cryptographic bill of materials (CBOM) inventories all of the cryptography used by an organization. This includes the algorithms in use, configurations, protected data, and similar information.

Why to Build a Comprehensive CBOM

For many organizations, the main driver for building a CBOM and pursuing crypto-agility is quantum migration. A full inventory of cryptography vulnerable to quantum computing is essential for a full and timely migration.

Two quantum algorithms currently threaten classical cryptography: Shor's and Grover's algorithms. Shor's algorithm impacts asymmetric cryptographic algorithms (RSA, ECDSA, etc.) and renders them completely broken once large enough quantum computers are available. In contrast, Grover's algorithm only halves the effective key length of symmetric encryption and hash algorithms (AES, SHA, etc.).

Since Shor's algorithm completely breaks classical asymmetric cryptography, a comprehensive inventory of these algorithms is essential for quantum migration. However, symmetric algorithms are still secure if their key lengths are secure even after being effectively halved.

However, quantum migration isn't the only reason to build a CBOM, and a full CBOM should incorporate both asymmetric and symmetric cryptography. If, for example, a vulnerability is discovered in a cryptographic library like Bouncy Castle, the organization needs to know everywhere it uses and needs to replace the affected code, whether it's an asymmetric or symmetric algorithm.

Where to Look for Cryptographic Code

Cryptographic code may be scattered across an organization's codebases and IT infrastructure. When building a comprehensive CBOM, organizations should look at:

Networks and Protocols: Cryptography is commonly used in network protocols to ensure confidentiality, integrity, and authenticity. Places to look include TLS handshakes, VPN configurations, and SSH keys.
Codebases and Dependencies: Applications may access cryptographic code either by directly calling cryptographic functions or as part of their dependency trees. Teams should run source code analysis and software composition analysis (SCA) to find cryptography both in source code and dependencies.
Digital Certificates: Digital certificates are used for various purposes within the organization. Certificates are used to distribute public keys for digital signatures and are digitally signed themselves.
Embedded, Firmware, and IoT: Embedded code, firmware, and IoT devices can use cryptographic code for data storage, integrity verification, etc. Check network traffic and vendor documentation for signs of crypto usage.
Third-Party and Vendor Crypto: Organizations may use SaaS apps, enterprise apps, cloud KMS/HSM-as-a-Service platforms, and other tools that use cryptography. Teams should check documentation and engage with vendors during contract renewal to track quantum readiness.
Bulk Data Encryption: Bulk data encryption commonly uses symmetric encryption algorithms like AES. However, it also incorporates asymmetric cryptography to transmit or securely store symmetric keys.

Why Symmetric Cryptography is "In Scope"

Many CBOMs are designed to support post-quantum migration. As a result, they focus on asymmetric algorithms, like RSA or ECDSA, which are broken by Shor's algorithm when CRQCs become available.

CBOM should incorporate both asymmetric and symmetric algorithms for a couple of reasons. One is that symmetric algorithms may be vulnerable to quantum computing due to Grover's algorithm, which halves the effective key length. For example, AES-128, AES-192, and SHA variants with digest lengths under 384 bits are vulnerable and should be migrated.

Non-Quantum Threats to Cryptography

Another important reason why symmetric algorithms should be included in a CBOM regardless of key length is that quantum computing is not the only threat to cryptography. Cryptographic algorithms and their implementations have been broken in the past, and this will continue in the future.

Some reasons to include all cryptography within a CBOM include:

Vulnerable Implementations: Why a cryptographic algorithm may be theoretically secure, implementations can contain bugs that make them vulnerable. For example, Bouncy Castle, a widely-used cryptographic library has had vulnerable versions in the past (CVE-2020-28052 and CVE-2026-5588). A CBOM should include library versions alongside algorithm names so an organization can easily determine its exposure to a newly-discovered CVE.
Protocol Downgrade Exposure: Protocol downgrade attacks involve an attacker tricking an application into using a less secure cryptographic algorithm. For example, TLS handshakes may cause a computer to downgrade to a weaker ciphersuite. A CBOM should track all crypto usage to identify exposure to cryptographic downgrade attacks.
Algorithm Deprecation: Cryptographic algorithms can be deprecated when their key length is too short to be secure or if an attack is developed that breaks their security. For example, 3DES and SHA-1 have been broken without quantum computing. Tracking all crypto usage enables the business to adapt if a formerly trusted algorithm is deprecated or broken.

Quantum computing is the most common and pressing reason why organizations pursue a CBOM. However, crypto visibility and agility are essential to manage other threats as well.

Building the CBOM

A comprehensive, up-to-date CBOM is an essential first step toward achieving crypto-agility. To make the most of this resource, organizations should take the following steps.

Discovery

Cryptographic algorithms appear in various places within an organization's IT infrastructure. The first step toward building a CBOM is discovering an organization's existing cryptographic exposure.

Teams can use a combination of automated tools and manual analysis to identify cryptographic code. Some applications of automation include:

Source Code Analysis: Applications commonly call cryptographic libraries for encryption or digital signatures. Source code analysis tools can help to identify these calls based on algorithm names and parameters.
Software Composition Analysis (SCA): Often, cryptographic code is hidden within an application's dependency tree. SCA tools can map both direct and indirect dependencies, allowing the organization to check these for cryptography usage.
Network Traffic Analysis: TLS, VPNs, IoT devices, and other systems may use cryptography to protect data in transit. Network traffic analysis can help to identify encrypted traffic and extract the algorithms and settings in use.

CBOM Generation

A CBOM tracks an organization's use of cryptography, including factors such as software versions, key lengths, and other configuration settings. This information should be organized in a way that makes it easy to use and update as needed.

CycloneDX is an open-source, standardized format for storing information, including CBOM data. Adopting this as the reporting format also helps interoperability as many tools will support this output format without the need for translation.

Prioritization

Often, companies adopt a CBOM as part of their quantum migration. Pressing deadlines, such as the requirement for full migration by 2031 for US government agencies and contractors defined in US EO 14412, mean that companies must migrate before CRQCs become available.

However, this isn't the only reason to build a CBOM or prioritize crypto-agility. Some factors that organizations should consider when prioritizing their CBOM for migration include:

Harvest Now, Decrypt Later (HNDL) Attacks: Data encrypted and collected today could be exposed when CRQCs become available. Data can be prioritized based on whether it will still be sensitive after Q-Day.
Regulatory Deadlines: EO 14412 and other regulations lay out hard deadlines for migrating certain algorithms in various industries. Prioritization should take these timelines into account.
Migration Complexity: The difficulty of adopting crypto-agile principles varies across the various types of crypto usage. Prioritization should include complexity and timelines to ensure that deadlines are met.

Revision and Updates

An organization's use of cryptography can evolve regularly. Each new piece of software or updated code can introduce new cryptography or change the algorithms, configurations, and software versions in length.

For this reason, CBOMs should be regularly revised to ensure that they are up-to-date. Ideally, this should be integrated into automated software deployment pipelines and acquisition processes to ensure that crypto usage is documented as soon as it enters the organization's IT environment.

From the CBOM to Crypto-Agility

A CBOM is a useful tool because it maps out an organization's existing use of cryptography. This is essential for managing quantum migration and addressing other cryptographic risks, such as vulnerable libraries or deprecated algorithms.

With a CBOM in hand, an organization can start working toward crypto-agility as well. When crypto-using code is updated, it should be modified to incorporate crypto-agile principles, making it easier to adapt and manage in the future. Migration status can also be tracked in the CBOM, allowing the business to track progress and the work that still needs to be done.