In 2024, NIST published its post-quantum cryptographic standards and set a firm expectation: migrate away from RSA and elliptic-curve cryptography by 2030. But the more pressing threat is already here. 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 a CBOM actually contains
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.
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
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.
Regulatory context for Indian organisations
For regulated entities in India, building a CBOM is becoming 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.
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 NXRadar CBOM platform 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.
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.
