What is a CBOM? The Cryptographic Bill of Materials explained
A Cryptographic Bill of Materials records which cryptography a system uses, where it is used and how strong it is. It is the starting point for removing weak cryptography and planning the move to post-quantum algorithms.
- A CBOM is a machine-readable inventory of cryptographic assets: algorithms, keys, protocols and certificates, and how they relate to the software that uses them.
- CERT-In's Version 2.0 guidelines define minimum CBOM elements for each of the four asset types and recommend CBOMs in government, public sector and essential services procurement.
- CycloneDX 1.6 added a cryptographic-asset component type and a cryptoProperties object, giving CBOMs a standard format.
- Post-quantum roadmaps from NIST, NSA, the EU, the UK NCSC and India's DST all begin with discovery and inventory of cryptography.
- A CBOM is only useful if it is kept current, linked to owners and business services, and tested against a written cryptographic policy.
Definition
A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of the cryptography used by a piece of software, a system or an organisation. It lists each cryptographic asset, records the properties that determine its strength and lifetime, and links it to the components and services that depend on it.
CERT-In's Technical Guidelines, Version 2.0 (9 July 2025), describe the CBOM as an inventory of cryptographic assets "including algorithms, keys, protocols, certificates, and dependencies", together with metadata such as usage and expiration [1]. OWASP CycloneDX, which provides the most widely used CBOM format, describes it as a way to represent "algorithms, keys, certificates, and their relationships to software components" [2].
A CBOM complements a software bill of materials. An SBOM tells you that an application ships a particular version of OpenSSL; a CBOM tells you that the application negotiates TLS 1.2 with a specific cipher suite, signs tokens with RSA-2048 and holds a certificate that expires in March. See SBOM vs CBOM for a detailed comparison.
Why organisations need a cryptographic inventory
Cryptography is configured in many places, load balancers, application code, libraries, HSMs, cloud key services, firmware, VPN concentrators and partner integrations, and usually has no single owner. Three pressures make an inventory necessary:
- Weak and deprecated cryptography. The IETF formally deprecated TLS 1.0 and 1.1 in RFC 8996 [12], and NIST SP 800-131A Rev. 2 sets a minimum of 112-bit security strength for federal use, which rules out RSA keys shorter than 2048 bits [13]. Neither can be enforced without knowing where these are in use.
- Certificate expiry. Every certificate carries a validity window. Without an inventory of certificates and their owners, renewals depend on memory and outages follow.
- The post-quantum transition. NIST IR 8547 (initial public draft) proposes that quantum-vulnerable public-key algorithms such as RSA and elliptic-curve schemes be deprecated after 2030 at the 112-bit level and disallowed after 2035 [5]. A migration of that scale cannot be planned without first knowing where those algorithms are used.
What a CBOM contains
CERT-In groups CBOM minimum elements into four asset types (Table 9 of the guidelines) [1]:
| Asset type | CERT-In minimum elements | Typical example |
|---|---|---|
| Algorithms | Name, Asset Type, Primitive, Mode, Crypto Functions, Classical security level, OID, List | AES-128-GCM used for encryption and tag generation |
| Keys | Name, Asset Type, id, state, size, Creation Date, Activation Date | A 2048-bit RSA private key held in an HSM, state active |
| Protocols | Name, Asset Type, Version, Cipher Suites, OID | TLS 1.2 with a list of negotiated cipher suites |
| Certificates | Name, Asset Type, Subject Name, Issuer Name, Not Valid Before, Not Valid After, Signature Algorithm Reference, Subject Public Key Reference, Certificate Format, Certificate Extension | An X.509 server certificate for an internet banking site |
CycloneDX models the same ground. Version 1.6, released on 9 April 2024, introduced CBOM support [3]. In the schema, a component of type cryptographic-asset carries a cryptoProperties object whose assetType is one of algorithm, certificate, protocol or related-crypto-material (the last covers keys, secrets, tokens and similar material) [4]. References between assets, a certificate pointing to its signature algorithm and public key, a protocol pointing to its cipher suites, let a CBOM express dependencies rather than a flat list.
Who expects a CBOM
Several public frameworks now expect a cryptographic inventory, even where they do not use the term CBOM:
| Source | What it expects |
|---|---|
| CERT-In Technical Guidelines v2.0 (India) | Government, public sector and essential services organisations "shall require" a CBOM for cryptographic assets in related procurements, developments and integrations (rec. 8.4.1.1); CBOMs to be reviewed at least quarterly [1] |
| SEBI CSCRF FAQs (June 2025) | Regulated entities to maintain an inventory of cryptographic assets that describes "what cryptography is used by which application for what purpose", including keys, certificates and algorithms [11] |
| DST Task Force report (India, February 2026) | Organisations to prepare CBOMs covering primitives, algorithms, libraries, protocols and dependencies as part of quantum-safe migration [10] |
| OMB M-23-02 (US federal) | Agencies to submit an inventory of quantum-vulnerable cryptographic systems by 4 May 2023 and annually thereafter [7] |
| NSA CNSA 2.0 (US national security systems) | Transition to quantum-resistant algorithms on a published timetable, which presupposes knowing current usage [6] |
| EU coordinated PQC roadmap | First steps, including cryptographic inventories, by the end of 2026 [8] |
| UK NCSC PQC timelines | A full discovery exercise by 2028 [9] |
For a framework-by-framework view, see CBOM compliance and CERT-In CBOM requirements.
How a CBOM is built
No single technique finds all cryptography. A practical CBOM combines several sources:
- Network scanning of TLS, SSH and VPN endpoints for protocol versions, cipher suites and certificate chains.
- Source-code analysis to find calls to cryptographic APIs and hard-coded algorithm choices.
- Binary and container analysis to find bundled libraries, certificates, keystores and configuration files.
- HSM, KMS and PKI exports for key metadata and issued certificates.
- Supplier CBOMs for products where you have no source code.
Results are normalised into one format, deduplicated and linked to applications and owners. CBOM generation covers each technique; CBOM tools lists open-source options.
What you do with a CBOM
- Find weak cryptography by testing the inventory against policy: deprecated protocols, short keys, SHA-1 signatures, ECB mode. See finding weak cryptography with a CBOM.
- Manage certificate and key lifecycles by forecasting expiry and tracking key state.
- Respond to vulnerabilities in cryptographic libraries by knowing exactly which services use the affected component.
- Plan post-quantum migration by identifying quantum-vulnerable algorithms, ranking them by data lifetime and exposure, and tracking replacement. See preparing for post-quantum cryptography.
- Build crypto-agility, so that the next algorithm change is a configuration exercise rather than a rewrite. See crypto-agility.
CBOM, SBOM and QBOM
CERT-In treats the CBOM and the QBOM together in Section 8 of its guidelines. The CBOM inventories cryptographic assets; the QBOM focuses on components related to quantum computing and quantum-safe cryptography [1]. The SBOM remains the base inventory of software components. In CycloneDX all three can live in one document, with cryptographic assets linked to the libraries that implement them.
Common pitfalls
- Treating the CBOM as a one-off project. Cryptography changes with every deployment and certificate renewal; CERT-In recommends reviews at least quarterly [1].
- Scanning only the perimeter. Internet-facing TLS is the easiest part to scan and often the smallest part of the estate.
- Recording assets without owners. A finding with no owner is rarely fixed.
- Storing the CBOM carelessly. A CBOM is a map of your cryptographic weak points; CERT-In recommends encryption, access control and integrity protection for CBOM data (rec. 8.4.1.12) [1].
How IntelliXBOM helps
IntelliXBOM generates and ingests CBOMs in CycloneDX, validates them against required-field policies such as the CERT-In minimum elements, and keeps version history so changes between scans are visible. It correlates cryptographic assets with vulnerabilities, end-of-life data and the business services they support, and maps the inventory to framework controls with timestamped evidence, deployed on-premise, in a private cloud or air-gapped.
Frequently asked questions
What does CBOM stand for?
CBOM stands for Cryptographic Bill of Materials, sometimes written Cryptography Bill of Materials. It is an inventory of the algorithms, keys, protocols and certificates used by software or systems, with the properties needed to judge their strength and lifetime.
Is a CBOM mandatory in India?
CERT-In's Version 2.0 guidelines recommend that government, public sector and essential services organisations require CBOMs in related procurements, developments and integrations. SEBI's CSCRF FAQs also expect regulated entities to maintain an inventory of cryptographic assets. Organisations should check how these apply to them with their regulator or advisers.
Which format should a CBOM use?
CERT-In recommends recognised formats such as SPDX or CycloneDX. CycloneDX 1.6 and later include a dedicated cryptographic-asset component type and cryptoProperties object designed for CBOMs.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- Cryptography Bill of Materials (CBOM)OWASP CycloneDXcyclonedx.org/capabilities/cbom/
- CycloneDX v1.6 Released, Advances Software Supply Chain Security with Cryptographic Bill of Materials and Attestations (9 April 2024)OWASP CycloneDXcyclonedx.org/news/cyclonedx-v1.6-released/
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards (November 2024)NISTnvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf
- Announcing the Commercial National Security Algorithm Suite 2.0NSA Cybersecurity Advisorymedia.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF
- M-23-02, Migrating to Post-Quantum Cryptography (18 November 2022)US Office of Management and Budgetwww.whitehouse.gov/wp-content/uploads/2022/11/M-23-02-M-Memo-on-Migrating-to-Post-Quantum-Cryptography.pdf
- EU PQC Workstream publishes 'A Coordinated Implementation Roadmap for the Transition to Post-Quantum Cryptography'PQShieldpqshield.com/eu-pqc-workstream-publishes-a-coordinated-implementation-roadmap-for-the-transition-to-post-quantum-cryptography/
- Timelines for migration to post-quantum cryptography (20 March 2025)UK National Cyber Security Centrewww.ncsc.gov.uk/guidance/pqc-migration-timelines
- Implementation of Quantum Safe Ecosystem in India: Report of the Task Force (February 2026)Department of Science and Technology, Government of Indiadst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20(v1).pdf
- FAQs on Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI REs (11 June 2025)SEBIwww.sebi.gov.in/sebi_data/faqfiles/jun-2025/1749647139924.pdf
- RFC 8996, Deprecating TLS 1.0 and TLS 1.1 (March 2021)IETFwww.rfc-editor.org/rfc/rfc8996
- SP 800-131A Rev. 2, Transitioning the Use of Cryptographic Algorithms and Key Lengths (March 2019)NISTcsrc.nist.gov/pubs/sp/800/131/a/r2/final
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.