NIST’s post-quantum migration documentation confirms that “harvest now, decrypt later” attacks are actively happening, where hackers capture encrypted data today to decrypt it the moment quantum computing reaches enough capability.
Before you can protect cryptographic systems, you need full visibility into where they exist. A Cryptographic Bill of Materials (CBOM) is that foundation – a structured inventory of every algorithm, certificate, key, protocol and cryptographic library running across your systems. This guide will cover how to build a CBOM from first principles, the formats and tools involved, and why RBI and CERT-In have made cryptographic asset inventory a regulatory expectation for Indian firms.
What does a CBOM contain
A CBOM documents the full cryptographic footprint of your apps and infrastructure. It’s most commonly represented using the CycloneDX standard, and has the following core components:
- Algorithms and key sizes: RSA, ECC, AES variants, SHA functions and their exact parameters
- Digital certificates: SSL/TLS certificates, code-signing certificates, issuing CAs, validity windows and revocation status
- Cryptographic keys: key pairs, types, lengths, storage location (HSM, cloud KMS or application memory) and rotation schedules
- Protocols in use: TLS versions, SSH configurations and IPsec settings
- Libraries and dependencies: OpenSSL, BouncyCastle and any deprecated versions embedded in third-party components
A CBOM is not just a one-time audit output. It is a living inventory that must grow with every software release, infrastructure change and certificate rotation.
Why Indian organisations cannot wait to build a CBOM
India’s regulators are moving faster than most security teams expect. Two developments from May 2026 set the pace:
- RBI Q-SAFE committee: On May 25, 2026, RBI formed an expert committee to study quantum risk in the financial sector. Its mandate includes evaluating the sector’s cryptographic inventory through CBOMs and assessing crypto-agility.
- DST quantum-safe roadmap: The Department of Science and Technology’s Task Force report under the National Quantum Mission expects critical sectors, including BFSI, to complete cryptographic inventories by Dec 2027. The roadmap is advisory. Binding obligations will come through sector regulators such as RBI.
Building your CBOM now gives you time to fix what it reveals, before a regulator asks to see it. The steps below show you how to start.
How to build a CBOM: A step-by-step approach
Building a CBOM needs you to have a structured process for discovery, analysis, governance and continuous maintenance. Here are the six steps to build a CBOM effectively:
Define your scope and application inventory
List out every application across your organisation, including vendor-supplied software, internal builds, cloud-hosted workloads and on-premise systems. Attempting to build a CBOM without a defined scope creates gaps that can lead directly to audit risk and compliance exposure.
Run multi-source cryptographic discovery scans
No single scan type provides a complete picture. Effective CBOM generation needs four parallel discovery approaches:
- Network scan: SSL/TLS certificate discovery, protocol version detection and cipher suite enumeration
- Code repository scan: Static analysis of source code to detect cryptographic functions and algorithm usage
- Artifact scan: Container image scanning, binary cryptographic analysis and dependency mapping
- HSM/KMS integration: Key metadata from AWS KMS, Azure Key Vault, GCP KMS and HashiCorp Vault
You do not need to build discovery from scratch. The open-source CBOMkit suite, now maintained by the Post-Quantum Cryptography Alliance under the Linux Foundation, automates much of the code and container work:
- Sonar-cryptography: A SonarQube plugin that scans source code and writes a CycloneDX cbom.json file
- CBOMkit-action: A GitHub Action that generates a CBOM for every module in a repository as part of your pipeline
- CBOMkit-theia: A container image scanner that finds certificates, keys and security configurations
These tools work well for code you own. They do not cover HSMs, cloud KMS, network traffic, vendor software or regulatory mapping. Enterprise platforms such as CyberNX’s CBOM solutions close that gap with HSM and KMS integration and RBI and CERT-In-mapped reporting. Our guide to evaluating CBOM tools explains what to look for.
Structure output in a machine-readable format
Use CycloneDX (ECMA-424) as your CBOM format. It is the OWASP-backed standard for bill-of-materials documentation, with native cryptographic asset support added in version 1.6. CERT-In’s Technical Guidelines v2.0 recognises CycloneDX and SPDX as the primary machine-readable formats for CBOM generation and recommends their use for regulated entities.
Analyse findings and assign risk scores
Raw scan output needs structured interpretation. Map each cryptographic asset against known risk factors: deprecated algorithms like SHA-1 and RSA-1024, expired or near-expiry certificates, non-compliant TLS configurations and quantum-vulnerable implementations including RSA-2048 and ECC P-256.
Assign ownership and establish governance
A CBOM without accountability delivers less operational value. Every cryptographic asset needs an explicit owner, a team or service account responsible for renewals, policy violations and migration. Define escalation paths for certificate expirations and algorithm deprecations before they become incidents.
Integrate into CI/CD and monitor continuously
Integrate CBOM generation into your development pipeline so every build produces an updated inventory. Configure policy gates to flag outdated protocols before they reach production and set real-time alerts for new quantum-vulnerable cryptographic usage as it enters your systems.
Common pitfalls when building a CBOM
Most CBOM programmes stall for avoidable reasons. Watch out for these four:
- Scanning code only: Network, HSM and appliance cryptography stays invisible, leaving large gaps in your inventory
- Skipping vendor software: RBI Advisory No. 11/2024 expects CBOM coverage for third-party components too
- Scanning everything at once: Start with a pilot on your most critical applications, then scale in waves
- Treating it as a one-time audit: A stale CBOM creates false confidence the moment a certificate rotates
Regulatory context for Indian organisations
For regulated entities in India, building a CBOM is becoming an auditable obligation. Two instruments define the current regulatory baseline:
- RBI Advisory No. 11/2024 (25 November 2024) explicitly references CERT-In’s CBOM technical guidelines. It requires regulated entities to share these guidelines with developers and vendors, and to ensure CBOM accuracy, completeness and timeliness across all software components, including those sourced from third parties.
- CERT-In Technical Guidelines v2.0 (9 July 2025) makes CBOM mandatory for critical applications, mandates standards-based generation using CycloneDX or SPDX, and integrates CBOM into the software development lifecycle. The same guidelines provide guidance on QBOM for quantum-readiness assessment, extending the cryptographic inventory requirement into post-quantum migration planning.
For banks, NBFCs and BFSI entities, audit readiness now means demonstrating a live, maintained CBOM, not a plan to create one.
From CBOM to crypto-agility
A CBOM tells you where your cryptography lives. Crypto-agility is the ability to change it quickly without disrupting live systems. RBI’s Q-SAFE committee will assess it too. Your CBOM is the starting point. Our CBOM maturity model shows how to move from discovery to quantum readiness.
Conclusion
Cryptographic visibility is the prerequisite for everything else: quantum readiness, regulatory compliance and effective incident response. Knowing how to build a CBOM correctly gives your company the foundation to take care of cryptographic risk proactively.
CyberNX’s CBOM solutions helps regulated enterprises build and maintain a complete cryptographic inventory, from multi-source discovery and intelligent risk scoring to RBI and CERT-In-aligned evidence packs and post-quantum readiness dashboards. To get started with how to build a CBOM for your organisation, connect with our experts.
How to Build a CBOM FAQs
What is the difference between a CBOM and an SBOM?
An SBOM lists all software components and their dependencies. A CBOM focuses specifically on the cryptographic assets within those components: algorithms, keys, certificates and protocols. A CBOM builds on and extends an SBOM by adding cryptographic-specific metadata, risk context and post-quantum readiness indicators. Read our detailed comparison of CBOM vs SBOM.
Which format should organisations use when building a CBOM?
CycloneDX (ECMA-424) is the primary standard for CBOM generation and is recognised by CERT-In’s Technical Guidelines v2.0 and NIST. SPDX is also accepted by Indian regulators but is more commonly used for software component licensing documentation.
How often should a CBOM be updated?
A CBOM should be updated with every software release, dependency change, certificate rotation or infrastructure modification. For regulated entities under RBI and CERT-In guidelines, continuous monitoring with automated re-scanning are considered best practice to align with CERT-In guidance.
What is the cost of delaying a CBOM programme?
Delays create compounding risk across three dimensions: regulatory penalties and audit failures when RBI or CERT-In-aligned evidence is unavailable; exposure of long-lived encrypted data to future quantum decryption through “harvest now, decrypt later” attacks; and a compressed, expensive post-quantum cryptography migration timeline when a deadline forces urgency.
