CERT-In's CBOM and QBOM Guidelines: What India's Technical Guidelines v2.0 Actually Requires

If you work in Indian financial services or critical infrastructure and someone has asked you "do we have a CBOM policy yet," the honest answer starts with a document most people haven't read past the title: CERT-In's "Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM," Version 2.0, dated 9 July 2025.

It's easy to skim past. It's issued by India's national computer emergency response team, not a financial regulator, and its title buries CBOM in a list of four other BOM types. But read past the first page and it's the single most detailed cryptographic-inventory specification published by any national authority currently on this site, ahead of every one of the 30-plus other scored countries.

Who it's for

Section 2.2 states that the guideline "has been issued by Indian Computer Emergency Response Team (CERT-In) for the following entities especially in the Government, Public Sector, Essential Services Organizations and organizations involved with software exports and software services industry," and then names three roles: software consumer, software developer, and system integrator or reseller. That's a broad but not universal scope: it's squarely aimed at government and government-adjacent organizations, plus India's large software export sector, not private enterprise generally and not the financial sector specifically (RBI's separate Q-SAFE effort covers that gap; see below).

What it actually defines

Section 8 of the guidelines draws a specific, useful distinction:

• CBOM (Cryptographic Bill of Materials): an inventory of cryptographic assets, algorithms, keys, protocols, and certificates, with defined metadata for each. For a cryptographic algorithm entry, the guidelines specify capturing the algorithm name, asset type, cryptographic primitive, mode, function, classical security level (bit-strength), and OID. For keys: state (active, revoked, expired), size, and creation/activation dates. For certificates: subject and issuer name, validity window, signature algorithm reference, and format (e.g., X.509).
• QBOM (Quantum Bill of Materials): a separate but related inventory of quantum algorithms, security frameworks, and the hardware/software dependencies that enable an organization's move to post-quantum cryptography.

This is a genuinely detailed schema, not a one-line definition. Few of the primary sources cited elsewhere on this tracker specify what a cryptographic inventory entry should actually contain field by field.

Where the "shall" language sits

Section 2.2 frames the entire document as a guideline issued to named sectors, not a statute or regulation, and there's no stated penalty for non-adoption anywhere in the text. It goes further than that, in a way that is easy to miss: the guidelines cite no legal basis at all. There is no reference to section 70B of the IT Act, and no cross-reference to CERT-In's own 2022 Directions, which are binding. Whatever enforceability those directions carry does not transfer to this document by its own text.

On this tracker, India's mandate-strength score rests on IRDAI's and SEBI's binding sectoral controls, not on CERT-In's guidelines, which contribute the country's inventory-specification evidence rather than its enforceability.

But recommendation 8.4.1.1, inside that same guideline, doesn't read like a soft suggestion: "All government, public sector, and essential services organizations shall require a comprehensive Bill of Materials (BOM), specifically a Cryptographic BOM (CBOM) for cryptographic assets and a Quantum BOM (QBOM) for quantum systems in all related procurements, developments, and integrations." Recommendation 8.4.1.2 extends this to suppliers: any vendor delivering cryptographic or quantum technology "must provide a complete CBOM and/or QBOM detailing all components, algorithms, technologies, and dependencies present in the delivered solution."

That's the nuance worth sitting with: a document that calls itself a guideline, addressed to named sectors, with no stated enforcement mechanism, using unambiguously mandatory language inside its own recommendations. Whether that functions as a real requirement in practice likely depends on whether it gets referenced in procurement contracts and audits, not on the document's own force of law.

What else the guidelines require

Beyond the inventory itself, CERT-In's recommendations tie CBOM/QBOM data into an organization's broader security operations:

• BOMs should use recognized interoperable formats (SPDX or CycloneDX), not a bespoke internal spreadsheet.
• When a vulnerability is found in a cryptographic or quantum component, the guidelines call for a Vulnerability Exploitability eXchange (VEX) document classifying the status as Not Affected, Affected, Fixed, or Under Investigation.
• CBOM/QBOM data should be cross-referenced against CERT-In's own advisories and vendor bulletins for real-time visibility, and periodically audited for completeness and accuracy.

How this fits with India's other regulators

CERT-In's guidelines are the most detailed CBOM specification in India, but they aren't the only thing happening. The Reserve Bank of India convened Q-SAFE specifically for the financial sector in May 2026, and SEBI's Cybersecurity and Cyber Resilience Framework already has a live cryptographic-inventory clause in force for its regulated entities. See the India country page for how this tracker scores the combination.

Primary source: CERT-In, "Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM" v2.0 (9 July 2025).