What Is CBOM (Cryptographic Bill of Materials)? This Guide Answers

There is a good chance that you know which libraries your applications use. But do you know which cryptographic algorithms those libraries are running? Are you aware which certificates are expiring silently in the background? Or whether any of the encryption protecting your customer data today will hold up against a quantum-capable adversary by 2030? A CBOM or Cryptographic Bill of Materials give answers to these questions and does much more.

CBOM has moved from a niche concept to a named expectation in CERT-In’s Technical Guidelines Version 2.0, a regulatory priority under SEBI’s Cybersecurity and Cyber Resilience Framework (CSCRF) and an active area of assessment under the RBI’s Q-SAFE expert committee.

If you are a CISO, compliance officer or security architect in a regulated Indian organisation, CBOM should be a priority.

This guide explains what CBOM is, how it works, why post-quantum cryptography (PQC) has made it urgent, and how to build one in a way that satisfies regulators while improving your real security posture.

What is a CBOM?

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset used across your software and systems. Where an SBOM (Software Bill of Materials) catalogues components and dependencies, a CBOM goes one layer deeper. It catalogues the cryptography those components rely on.

A complete CBOM typically records:

• Algorithms: the cipher suites, hash functions and signature schemes in use (for example, AES-256-GCM, RSA-2048, SHA-256, ECDSA)
• Protocols: TLS versions, SSH configurations, IPsec profiles and any other protocol carrying encryption
• Keys and certificates: key lengths, certificate issuers, expiry dates, rotation policies and storage references (HSM, keystore, Kubernetes secret)
• Cryptographic libraries: OpenSSL, BouncyCastle, OS-level crypto APIs and their versions
• Dependencies: which applications, services and endpoints rely on which cryptographic assets

The result is a single source of truth about how cryptography is implemented across your environment, not just whether encryption is present, but which encryption, where it runs, what it protects and how vulnerable it is.

How is CBOM different from SBOM?

The two inventories work at different layers and serve different risk concerns. For a detailed breakdown, see our dedicated post on CBOM vs SBOM. In brief:

They are complementary. An SBOM might tell you that an application uses OpenSSL 3.0 while a CBOM tells you that it is running RSA-1024, a key length that is already deprecated and that the certificate protecting it expires in 47 days.

A brief history: where CBOM came from

CBOM did not emerge in isolation. It grew from a recognition that software supply chain security was incomplete without cryptographic visibility.

SBOMs gave organisations a way to track components and respond to vulnerabilities. But they treated cryptography as an invisible implementation detail. When post-quantum cryptography became a concrete policy concern that gap became impossible to ignore.

The CycloneDX standard introduced cryptographic assets as a native component type in version 1.6, published in 2024 and ratified as ECMA-424. This gave CBOM a machine-readable, vendor-neutral format that organisations could implement, audit and exchange.

Globally, the US National Security Memorandum on Post-Quantum Cryptography and the EU Cyber Resilience Act have both referenced the need for cryptographic inventory. In India, CERT-In’s Technical Guidelines on SBOM, QBOM and CBOM Version 2.0 named CBOM explicitly as a recommended security practice, extending the earlier SBOM-focused guidance into the cryptographic domain.

The CBOM lifecycle

A CBOM is not a report you generate once. It is a continuously maintained capability. Understanding the lifecycle helps you build one that stays useful after the first scan.

1. Discovery

Automated tools scan across source code, compiled binaries, container images and network traffic to identify every cryptographic asset in use. This goes beyond checking whether TLS is enabled. It identifies which cipher suites are negotiated, whether hardcoded keys exist in the codebase and which certificates are approaching expiry.

2. Modelling

Each asset is represented using a structured object model. Properties captured include algorithm variant, mode of operation, key length, security level (such as FIPS 140-3 compliance) and any known weaknesses. CycloneDX 1.6 provides the schema for this.

3. Dependency mapping

CBOM distinguishes between cryptography that a component implements (an algorithm provided by a library) and cryptography that a component uses (an algorithm actively called at runtime). This distinction matters for prioritisation – usage in a high-traffic, customer-facing path carries more urgency than a dormant fallback.

4. Governance and analysis

Security teams analyse the CBOM against policy baselines. Which algorithms are deprecated? Which certificates expire within 30 days? Which systems are running TLS 1.0 or 1.1? Which components use RSA key lengths below the current recommended minimum?

5. Refresh

Because cryptographic usage changes with every code release, configuration update and certificate renewal, CBOMs need continuous regeneration. Tying CBOM generation into CI/CD pipelines ensures the inventory reflects the current state of your environment rather than the state it was in at the last audit.

Our post on the automated SBOM management lifecycle covers the same principle for SBOM, and the same logic applies here.

Why post-quantum computing makes CBOM urgent now

This is the part of the CBOM story that is moving fastest, and it is the piece most organisations have not yet internalised.

The “harvest now, decrypt later” threat

State-level adversaries are already collecting encrypted data today with the intention of decrypting it once sufficiently powerful quantum computers are available. This is not speculative – it is a documented threat posture referenced in both US government advisories and India’s own regulatory communications.

The implication is concrete. Data encrypted today under RSA-2048 or elliptic curve algorithms may not remain confidential through 2032 or beyond. For any organisation protecting data with long-term confidentiality requirements – patient records, KYC archives, financial transactions, key management infrastructure – that risk exists today, not in a future decade.

NIST’s post-quantum standards are final

In August 2024, the US National Institute of Standards and Technology (NIST) finalised its first post-quantum cryptographic algorithms: ML-KEM (CRYSTALS-Kyber) for key encapsulation and ML-DSA (CRYSTALS-Dilithium) for digital signatures. These replace classical asymmetric algorithms that quantum computers will be able to break.

Migration to these algorithms is not optional in the long run. But migration cannot begin until you know what you are migrating from. That is exactly what a CBOM provides.

You cannot migrate what you cannot see

Every quantum-safe migration project starts with the same question: which systems are using RSA, ECC or Diffie-Hellman? Without a CBOM, answering that question requires months of manual discovery. With one, it becomes a query against a structured inventory.

Crypto agility is the goal, CBOM is the foundation

Crypto agility – the ability to swap out a vulnerable algorithm without re-architecting the systems that depend on it – is what regulators and security architects mean when they say an organisation is “quantum-ready.” But crypto agility is impossible to demonstrate without visibility into which algorithms are in place. A CBOM is the evidence base that makes crypto agility measurable and auditable.

CBOM formats

Cryptographic Bill of Materials is designed for practicality, not complexity. That is why it extends an existing and widely adopted standard.

CBOM builds directly on CycloneDX version 1.4. It introduces cryptographic assets as a new component type while remaining fully compatible with existing SBOM tooling. This means organisations can reuse pipelines, parsers, and governance workflows already in place.

The CBOM schema is defined as a JSON schema. It adds three core extensions:

• Component type: crypto-asset
• Properties: cryptoProperties
• Dependencies: dependencyType

Crypto assets can represent:

• Algorithms
• Certificates
• Protocols
• Related cryptographic material such as keys.

Each asset captures only the properties needed to reason about security, avoiding unnecessary noise.

An algorithm crypto asset can capture properties such as:

• Primitive: blockcipher
• Variant: AES-128-GCM
• Mode: gcm
• Certification level: fips140-3-l1
• Classical security level: 128 bits

Capturing these details enables automated reasoning and policy enforcement.

Because CBOM stays aligned with CycloneDX, adoption is smoother. Security teams do not need to choose between SBOM and CBOM. They work together.

What CERT-In, SEBI and RBI now expect

This is the section that matters most if your organisation operates in India’s regulated sectors.

CERT-In: from recommendation to operational expectation

CERT-In’s Technical Guidelines on SBOM, QBOM and CBOM Version 2.0 introduced CBOM as a named, structured security practice. The guidelines describe CBOM as a recommended approach for inventorying cryptographic assets – algorithms, certificates, protocols and key material – in machine-readable, CycloneDX-aligned formats.

CERT-In’s 2026 AI Cybersecurity Blueprint, released on 25 May 2026, referenced these Version 2.0 guidelines directly in its Technical Defensive Controls section. The Blueprint names SBOM and CBOM as controls against AI-assisted attacks, framing cryptographic visibility as an operational defence rather than a compliance checkbox.

CERT-In’s empanelled auditors are now referencing CBOM readiness in assessments. Organisations that cannot produce a structured cryptographic inventory face scrutiny in audits tied to CERT-In empanelment, government project participation and vendor security assessments.

SEBI CSCRF: cryptographic controls embedded in the framework

The Securities and Exchange Board of India’s Cybersecurity and Cyber Resilience Framework (SEBI CSCRF) mandates that regulated entities – stock exchanges, depositories, clearing corporations, KRAs, Qualified REs and Small REs – maintain detailed software inventories for critical systems. The framework explicitly calls out cryptographic controls, key management practices and the documentation of encryption across systems handling sensitive financial data.

In practice, a SEBI CSCRF audit for a regulated entity’s critical systems now reasonably extends to questions about which encryption algorithms protect transaction data, what certificate governance looks like and whether deprecated cipher suites remain in use. Our work with SEBI CSCRF compliance frequently surfaces cryptographic gaps that SBOMs alone cannot expose.

RBI: the Q-SAFE signal

In May 2026, the Reserve Bank of India formed an expert committee called Q-SAFE specifically to study quantum risk in the financial sector. One of Q-SAFE’s first mandated responsibilities is to assess the financial sector’s cryptographic inventory using a CBOM framework and to test crypto agility in regulated entities.

This is a direct regulatory signal. When the central bank forms a committee tasked with reviewing your cryptographic inventory methodology, CBOM moves from best practice to the ground on which future regulatory requirements will be built. Banks and NBFCs that are ahead of this assessment cycle will find the transition to formal mandates far smoother than those that wait.

What CBOM covers: the six key asset types

A complete CBOM goes beyond recording that “encryption is in use.” It captures six categories of cryptographic asset, each with specific properties.

1. Algorithms

The cipher suites, hash functions and digital signature schemes your systems use. A CBOM records not just the algorithm name but the variant (AES-128 vs AES-256), the mode of operation (GCM, CBC, ECB) and whether the algorithm meets current standards. Deprecated algorithms like MD5, SHA-1 and RSA-1024 should surface immediately.

2. Certificates

Every X.509 certificate across your environment, including TLS certificates, code-signing certificates and internal CA-issued certificates. Key properties: issuer, subject, key type, key size, validity period, intended usage and whether it chains to a trusted root.

3. Keys and key material

Key references (not raw key values) including key IDs, types, sizes, storage locations (HSM, Kubernetes secret, cloud KMS) and rotation policies. A CBOM does not store secrets – it stores the metadata needed to reason about secret health.

4. Protocols

The network protocols carrying encryption – TLS version (1.0, 1.1, 1.2, 1.3), SSH configurations, IPsec profiles, QUIC support – and the cipher suite negotiated. TLS 1.0 and 1.1 are deprecated; a CBOM makes their presence visible so they can be removed.

5. Cryptographic libraries

OpenSSL, BouncyCastle, OS-level crypto APIs and any other library providing cryptographic primitives. Version matters here: a known-vulnerable version of a widely used library is a high-priority finding that only surfaces when you track library usage at this level.

6. Cryptographic dependencies

Which components, services and endpoints depend on which assets. This is the mapping layer that makes a CBOM useful for incident response. When a new vulnerability in a protocol or library is disclosed, dependency mapping tells you immediately which systems are affected.

What CBOM gives your security team and your auditor

Knowing your cryptographic posture changes what your security and compliance teams can do and how fast they can do it. These are the five areas where a well-maintained CBOM creates the most immediate, measurable difference.

1. Eliminates cryptographic blind spots

Most organisations have cryptography they do not know about – hardcoded keys in codebases, certificates issued by a forgotten internal CA, deprecated cipher suites left behind after a migration. A CBOM surfaces all of it. You cannot govern what you cannot see.

2. Accelerates incident response

When a cryptographic vulnerability is disclosed – a critical OpenSSL CVE, a newly deprecated cipher suite, a compromised CA – the first question is always: are we affected? Without a CBOM, that question takes days to answer. With one, it becomes a structured query. Our post on SBOM use cases covers the same principle for software dependencies; CBOM applies it to cryptography.

3. Strengthens compliance and audit readiness

CBOM gives auditors a structured artifact showing which cryptography is in use, where it runs and how it is governed. That is precisely what CERT-In, SEBI and RBI assessments are beginning to ask for. Generating audit evidence from a live, continuously updated CBOM is far faster than reconstructing it manually before each audit cycle.

4. Supports post-quantum migration planning

A PQC migration starts with an inventory. CBOM provides the map: which systems use which algorithms, which are quantum-vulnerable and which carry long-lived data that is already at risk from harvest-now-decrypt-later collection. Without this foundation, a PQC migration is guesswork. With it, you can scope pilots, prioritise by data sensitivity and track progress over time.

5. Demonstrates crypto agility

Regulators, enterprise customers and auditors are beginning to ask not just “are you encrypted?” but “can you change your encryption when required?” A CBOM, combined with a documented migration process, is the evidence that answers that question credibly.

CBOM best practices for implementation

Building a CBOM is straightforward in principle; sustaining one is where most organisations struggle. These practices reflect what separates a cryptographic inventory that holds up under audit from one that is stale before the first review cycle is complete.

1. Start with discovery

Before you can enforce standards, you need to know what you have. Begin with broad automated discovery across source code, binaries, containers and network traffic. Accept that the first run will surface surprises.

2. Prioritise usage over presence

An algorithm supported by a library but never called in production carries less urgency than one actively protecting customer-facing endpoints. Prioritise findings by actual usage and data sensitivity, not by the length of the algorithm list.

3. Integrate into CI/CD from day one

A CBOM generated manually once a quarter is already stale before the ink is dry. Integrate CBOM generation into your build pipelines so that every release produces an updated cryptographic inventory automatically. This is the same principle that drives automated SBOM lifecycle management.

4. Define ownership clearly

Cryptography sits at the intersection of development, security and infrastructure. CBOM governance works only when there is a named owner – ideally at CISO or security architect level – responsible for the inventory, the policies it enforces and the response to findings.

5. Map CBOM outputs to regulatory frameworks

Structure your CBOM reporting so that it maps directly to the fields CERT-In, SEBI and RBI assessments care about. Algorithm names, key lengths, certificate validity, deprecated protocol flags – these need to be exportable in formats auditors can use without translation.

6. Treat CBOM as a living asset

Cryptographic usage changes constantly. New dependencies are added, certificates are renewed, libraries are updated and configurations drift. A CBOM is only as useful as it is current. Build a refresh cadence tied to code releases and infrastructure changes, not to audit cycles.

CBOM and the broader bill of materials landscape

CBOM sits within a growing family of structured inventory formats that together give organisations complete visibility into everything their software and systems depend on.

• SBOM: the software components and open-source dependencies your applications are built from
• CBOM: the cryptographic algorithms, keys and certificates those components use
• AIBOM: the models, datasets and inference dependencies specific to AI systems
• HBOM: the hardware components and firmware your infrastructure runs on

CERT-In’s Version 2.0 guidelines cover all four. Organisations that have SBOM capability in place have a head start – the governance processes, tooling integrations and audit workflows transfer directly to CBOM. The inventory scope is different; the operating model is the same.

Conclusion

Cryptography is not a background implementation detail. It is the mechanism that makes digital trust possible – and it is under more pressure than it has been at any point in the last two decades.

CBOM gives you the visibility to govern cryptography the way your organisation governs software dependencies: continuously, systematically and with evidence that holds up in front of auditors, regulators and board-level risk committees.

The post-quantum clock is running. CERT-In, SEBI and RBI are all signalling in the same direction. Organisations that build CBOM capability now will be positioned to answer the regulatory questions coming in the next 24 months and to manage the PQC migration that every Indian financial institution will eventually be required to complete.

If you are ready to build a continuous, audit-ready cryptographic inventory across your environment, our CBOM solutions team is here to help. Talk to us about where to start.

CBOM FAQs

What is a CBOM?

A Cryptographic Bill of Materials (CBOM) is a structured inventory of all the cryptographic assets used across an organisation’s software and systems – including algorithms, keys, certificates, protocols and cryptographic libraries. It makes cryptography visible so it can be assessed, governed and upgraded when required.

How is CBOM different from SBOM?

An SBOM lists software components and dependencies. A CBOM focuses specifically on the cryptographic layer: which algorithms are running, which keys and certificates exist, and how each is used. They work together – an SBOM might identify that an application uses OpenSSL; the CBOM tells you which cipher suites that instance is actually running. For a full comparison, see CBOM vs SBOM.

Is CBOM only relevant for post-quantum readiness?

No. PQC migration is a major driver, but CBOM also supports everyday compliance, certificate lifecycle management, incident response and algorithm hygiene. Deprecated algorithms like SHA-1 and RSA-1024 are security risks today, long before any quantum computer poses a practical threat.

What do CERT-In and SEBI expect from a CBOM?

CERT-In’s Technical Guidelines Version 2.0 recommend CBOM as a structured practice for cryptographic asset management, aligned to CycloneDX format. CERT-In’s 2026 AI Cybersecurity Blueprint references these guidelines in its Technical Defensive Controls section. SEBI’s CSCRF framework expects regulated entities to maintain detailed cryptographic controls documentation for critical systems. For the full regulatory picture across all three bodies, see SBOM and CBOM: what RBI, SEBI and CERT-In expect from regulated entities.

What is the RBI Q-SAFE committee and why does it matter for CBOM?

The Reserve Bank of India formed Q-SAFE in May 2026 as an expert committee to assess quantum risk in the financial sector. One of its mandated tasks is to test regulated entities’ cryptographic inventories using a CBOM framework. This is a direct signal that CBOM will form part of RBI’s future regulatory expectations for banks and NBFCs.

How often should a CBOM be updated?

Continuously – not periodically. Cryptographic usage changes with every code release, configuration update and certificate renewal. Integrate CBOM generation into CI/CD pipelines so the inventory refreshes automatically. Quarterly or annual manual reviews are insufficient for the compressed timelines that modern threat response and emerging regulatory expectations require.

What is crypto agility and how does CBOM support it?

Crypto agility is the ability to change cryptographic algorithms or configurations without re-architecting dependent systems. It is a requirement for any organisation planning a post-quantum migration. A CBOM is the foundation: it maps every algorithm in use, every dependency on that algorithm and every system that would need to change. Without that map, crypto agility is a claim rather than a capability.