CERT-In SBOM, AIBOM, CBOM, QBOM & HBOM Guidelines v2.0 — Explainer

TL;DR for founders

CERT-In has published India's first consolidated framework for software transparency: the Technical Guidelines on SBOM, AIBOM, CBOM, QBOM and HBOM, version 2.0, October 2024 (reference CISG-2024-02). An SBOM is a machine-readable ingredient list for software; AIBOM does the same for AI/ML systems including training-data provenance; CBOM/QBOM inventory cryptographic and quantum-relevant components; HBOM covers hardware. The Guidelines target public-sector buyers, essential-services operators, and software exporters, and will cascade into RBI, SEBI and IRDAI vendor-diligence playbooks. Start here: name an SBOM owner, pick a format (CycloneDX or SPDX), and commit to shipping an SBOM with every release this quarter.

The Indian Computer Emergency Response Team (CERT-In) issued the second version of its Technical Guidelines on Software, Quantum, Cryptographic, AI and Hardware Bills of Materials in October 2024 (reference CISG-2024-02). The Guidelines are the canonical Indian source on supply-chain transparency for software and AI systems procured into Government of India entities, operators of Critical Information Infrastructure notified under Section 70 of the Information Technology Act, 2000 ('IT Act'), essential services in the financial sector, and software exporters whose customers are already bound by equivalent frameworks in the United States (US Executive Order 14028) and the European Union (Cyber Resilience Act, Regulation (EU) 2024/2847).

This explainer walks through what the five Bill-of-Materials ('BOM') types are, who must produce them, the minimum data fields, and how the Guidelines interact with the RBI IT Governance Master Direction 2023, the SEBI Cybersecurity and Cyber Resilience Framework ('CSCRF'), the IRDAI Information and Cyber Security Guidelines 2023, and the CERT-In 28 April 2022 incident-reporting Directions.

Glossary — the five BOMs in one line each

• SBOM — Software Bill of Materials: a machine-readable inventory of all components, libraries and dependencies that make up a piece of software, with version, supplier and licence information. International lineage: NIST minimum elements, July 2021.
• AIBOM — AI Bill of Materials: the SBOM equivalent for an AI/ML system, extending coverage to training datasets, model architecture, pre-trained weights, fine-tuning data, hyperparameters, evaluation results, intended-use constraints and model card metadata.
• CBOM — Cryptographic Bill of Materials: an inventory of the cryptographic primitives, algorithms, protocols, key lengths, implementations and libraries used by a product — necessary to reason about post-quantum migration.
• QBOM — Quantum Bill of Materials: an inventory of quantum-relevant components and algorithms — relevant in the long term for quantum-safe migration and, in the near term, for tracking post-quantum cryptography ('PQC') readiness.
• HBOM — Hardware Bill of Materials: an inventory of hardware components including processors, memory modules, firmware, microcontrollers and sub-assemblies — increasingly demanded for critical-infrastructure procurement.

Think of the BOMs as concentric transparency layers: SBOM covers software; AIBOM adds the AI training layer; CBOM and QBOM add the cryptographic layer; HBOM adds the hardware substrate. A modern AI-enabled product running on bespoke hardware will produce, if fully mature, an SBOM + AIBOM + CBOM + HBOM (a QBOM becomes necessary only where quantum-relevant components are in play).

What the Guidelines cover — section-by-section

The CERT-In v2.0 Guidelines are organised around the five BOM types, with a common lifecycle framework and shared guidance on distribution, access control and incident-response use. The Guidelines adopt the industry-standard SBOM formats — CycloneDX (maintained by OWASP) and SPDX (ISO/IEC 5962:2021) — as the reference machine-readable formats for SBOM, and extend the same formats (via CycloneDX's modelCard and ML extensions, and SPDX's upcoming AI profile) for AIBOM.

1. Scope and applicability — who must produce BOMs, and for which products.
2. SBOM minimum data fields — the seven NIST-aligned core fields plus India-specific distribution and authenticity recommendations.
3. AIBOM minimum data fields — the SBOM baseline plus training-data, model-architecture, evaluation, and intended-use fields drawn from the model-card pattern.
4. CBOM and QBOM — cryptographic and quantum-relevant inventory fields geared to post-quantum readiness.
5. HBOM — hardware-component inventory fields.
6. Lifecycle and distribution — when a BOM must be produced (build-time), refreshed (at each release and on material change), and communicated (with the product, at point of sale, on security request).
7. Access control — BOMs are security-sensitive. Distribution options include public publication, customer-only access, authenticated API delivery, and security-team-only release under NDA.
8. Integration with incident response — using BOMs to scope the blast radius of a supply-chain vulnerability quickly, and to feed the 6-hour CERT-In notification clock under Direction (ii) of the 28 April 2022 Directions.

Minimum data fields

SBOM minimum fields (CERT-In v2.0)

The CERT-In v2.0 Guidelines adopt the seven NIST minimum elements (published 12 July 2021 pursuant to US Executive Order 14028) as the baseline and extend them for Indian procurement contexts:

To these, CERT-In v2.0 adds guidance on distribution channel, integrity signature, licence, and a "known vulnerabilities at the time of release" field (typically linked to a companion VEX — Vulnerability Exploitability eXchange — document) so that a consumer can reason about exposure immediately.

AIBOM minimum fields

An AIBOM is an SBOM plus the fields necessary to reason about an AI/ML system's provenance, behaviour and governance. CERT-In v2.0 recommends, at minimum:

• Model identity — name, version, unique identifier, author/supplier, SBOM-AIBOM linkage
• Model architecture — type (e.g., transformer, CNN, random forest), parameter count, layer topology where disclosable
• Training data provenance — dataset names, sources, licences, collection windows, pre-processing steps, data-quality notes
• Pre-trained dependencies — base model identity and licence (important for fine-tuned open-source models)
• Fine-tuning data — where applicable
• Hyperparameters — disclosable ranges; security-critical ones flagged
• Evaluation results — benchmarks, fairness and bias metrics, robustness tests
• Intended use and known limitations — scope, out-of-scope uses, known failure modes
• Model card reference — link to the canonical model card
• Security-relevant notes — prompt-injection susceptibility, training-data contamination risk, jailbreak evaluation

CBOM and QBOM minimum fields

CBOM items typically include: algorithm name and mode, key length, cryptographic primitive type (encryption / signature / KEM / hash), library and version, API/boundary context, protocol context (TLS version, IPsec suite), and a post-quantum flag indicating whether the algorithm is NIST PQC-standardised or quantum-vulnerable.

QBOM extends CBOM with quantum-relevant component metadata — useful in the near term for tracking PQC migration and in the long term for quantum-hardware component tracking.

HBOM minimum fields

HBOM items typically include: hardware component name, manufacturer, part number, firmware version, country of manufacture, security-critical feature flags (TPM presence, secure enclave availability, PUF presence), and known CVEs at release time.

Who must produce BOMs

The CERT-In v2.0 Guidelines target four primary audiences:

1. Government of India entities — as software and AI procurers; expected to cite the Guidelines in RFPs and to require SBOM/AIBOM delivery with the product and on major release.
2. Critical Information Infrastructure ('CII') operators — entities whose systems are notified under Section 70 of the IT Act and supervised by NCIIPC under Section 70A. The NCIIPC Guidelines for Protection of Critical Information Infrastructure expect CII operators to exercise supply-chain transparency equivalent to the CERT-In baseline.
3. Essential services operators in the financial sector — banks, NBFCs and AIFIs (under the RBI IT Governance Master Direction, 7 November 2023, effective 1 April 2024), SEBI-regulated entities (under the SEBI Cybersecurity and Cyber Resilience Framework, Master Circular dated 20 August 2024), insurers and insurance intermediaries (under the IRDAI Information and Cyber Security Guidelines, 2023, dated 24 April 2023). Each framework requires supply-chain risk management that the BOM Guidelines operationalise.
4. Software and AI exporters — Indian vendors whose customers are already required to demand SBOMs under US Executive Order 14028 or the EU Cyber Resilience Act, Regulation (EU) 2024/2847 (in force September 2024, security requirements applying from December 2027).

Responsibility to produce the BOM sits with the software supplier or integrator that ships the product. The prime contractor is responsible for aggregating sub-supplier BOMs into the product-level BOM. Open-source maintainers are not obliged to produce BOMs — the obligation falls on the downstream integrator that incorporates the open-source component into a shippable product.

Roll-out timeline and phasing

The v2.0 Guidelines were issued in October 2024 (reference CISG-2024-02). They are a technical advisory rather than a statutory instrument — their practical effective date is driven by three vectors:

1. Government procurement — RFP clauses referring to the Guidelines are expected from FY 2024-25 onwards, tightening progressively for Critical and Material IT procurement.
2. Sectoral regulator adoption — the SEBI CSCRF technical clarifications of August 2025 and the RBI IT Governance Master Direction's Chapter V (outsourcing) implicitly require supply-chain transparency and therefore create an indirect demand for SBOM/AIBOM.
3. Export-driven adoption — Indian software and AI exporters selling into the US federal market (since 2022, under EO 14028) and into the EU from late 2027 (Cyber Resilience Act) must already produce SBOMs; aligning to the CERT-In v2.0 Guidelines is a one-programme solution for both Indian and export markets.

Expect a 12–24 month cycle between Guideline issuance (October 2024) and widespread contractual enforcement. Early-mover suppliers who can credibly ship an SBOM today will have a commercial advantage in bank and government procurement through 2025–2026.

Interaction with adjacent frameworks

CERT-In Directions 2022 (incident reporting) — a well-maintained SBOM shortens the time to scope a supply-chain vulnerability and to file the 6-hour notification required under Direction (ii) of the 28 April 2022 Directions. It does not substitute for the notification itself.

Section 70B(6) of the IT Act — the statutory power under which CERT-In operates. The BOM Guidelines are issued under the same CERT-In mandate, and non-production of a BOM contractually required by a Regulated Entity can cascade into incident-response failure under the 2022 Directions.

SEBI CSCRF (August 2024) and Technical Clarifications (August 2025) — impose supply-chain risk management obligations that the CERT-In BOM Guidelines operationalise. SEBI-regulated entities should expect to cite SBOM/AIBOM delivery in their CSCRF Programme Documentation.

RBI IT Governance Master Direction, 7 November 2023 (effective 1 April 2024) — Chapter V requires due diligence and ongoing oversight of IT outsourcing engagements. BOM production is the most practical evidence of software supply-chain transparency that a vendor can provide.

IRDAI Information and Cyber Security Guidelines, 2023 (24 April 2023) — the supply-chain controls the insurance sector is expected to implement map naturally to SBOM and AIBOM practices.

EU Cyber Resilience Act, Regulation (EU) 2024/2847 — products with digital elements placed on the EU market must, from December 2027, meet essential cybersecurity requirements including supply-chain transparency and vulnerability handling. An SBOM is a necessary (not sufficient) artefact. Indian exporters selling into the EU should treat CERT-In v2.0 and the EU CRA as a single programme.

US Executive Order 14028 (12 May 2021) and NIST minimum elements (12 July 2021) — already require SBOMs for software sold to the US federal government. The CERT-In v2.0 Guidelines are deliberately compatible.

Practitioner analysis — how to structure a BOM programme

Veritect's practitioner view on operationalisation:

1. Name a BOM owner. Typically, the CISO delegates to a software supply-chain security lead. Without a named owner, the programme drifts.
2. Pick a format and stick to it. CycloneDX (JSON or XML) is the most interoperable choice for most teams; SPDX is strong where Linux Foundation compliance is central. Producing in both is wasteful; translators exist.
3. Automate generation in CI/CD. A BOM produced by hand drifts immediately. Integrate an SBOM tool (Syft, CycloneDX Maven plugin, cyclonedx-node, etc.) into every build pipeline and gate releases on BOM production.
4. Sign and store. Sign the SBOM (for example via Sigstore/cosign) and store it in a tamper-evident registry alongside the artefact it describes. The CERT-In v2.0 Guidelines' authenticity recommendations require this.
5. Attach a VEX. A Vulnerability Exploitability eXchange document tells the consumer which listed CVEs actually affect the product in its shipped configuration. SBOM + VEX is far more useful than SBOM alone.
6. AIBOM — treat as an SBOM + Model Card overlay. Start with the SBOM baseline, add the model-card fields (OpenSSF's Model Card framework is a useful reference), include dataset provenance, and integrate into the procurement flow as a distinct deliverable.
7. Vendor contract clauses — include all of: (a) obligation to deliver SBOM with each release, (b) AIBOM for AI/ML components, (c) notification within a stated window of any new CVE affecting a listed component, (d) right to audit BOM completeness, (e) alignment with CERT-In v2.0, NIST minimum elements and (where relevant) EU CRA.
8. Distribute carefully. A full public SBOM can help attackers as much as defenders. Segment distribution by audience — public for general-purpose SaaS, customer-only for enterprise software, security-team-under-NDA for critical infrastructure.
9. Integrate with incident response. Store BOMs in the SOC's reachable repository; train the incident response team to query the BOM estate when a new critical CVE lands; use the BOM to scope the 6-hour CERT-In notification under Direction (ii) of the 28 April 2022 Directions.
10. Review cadence. Refresh each BOM on every release; re-audit the BOM programme itself annually, with the audit report tabled at the board-level IT Strategy Committee for RBI Regulated Entities.

Founder checklist

• Name a BOM owner this week and give them 5 per cent of the CISO's budget.
• Automate SBOM generation in your CI/CD — ship the first SBOM with the next release, not in the next board meeting.
• Add AIBOM obligations to the model lifecycle — every deployed model gets a versioned AIBOM with training-data and evaluation notes.
• Update procurement templates to require SBOM (and, where relevant, AIBOM) delivery from every Critical and Material vendor, with a right to audit.
• Wire the BOM estate into incident response — when a Log4j-class vulnerability lands, you want to answer the 6-hour question from an index, not from a scramble.

FAQ

Are the CERT-In BOM Guidelines legally mandatory?

Not as a stand-alone statute — the Technical Guidelines (reference CISG-2024-02, October 2024) are issued by CERT-In under its Section 70B mandate as a technical advisory baseline. They become contractually binding where a regulator, government procurer or prime contractor writes them into a procurement contract, and they become a compliance reference when RBI, SEBI or IRDAI cyber frameworks require supply-chain transparency. Software vendors to Government of India and to CII operators under Section 70 of the IT Act should expect the Guidelines to be cited in RFPs from 2024-25 onwards.

How do the SBOM minimum elements in the CERT-In Guidelines relate to the US NIST minimum elements?

The CERT-In v2.0 Guidelines reference the NIST minimum SBOM elements published on 12 July 2021 under US Executive Order 14028, and broadly align with them — component name, supplier name, version, unique identifiers (such as CPE, PURL, SWID), dependency relationships, SBOM author, and SBOM timestamp. CERT-In extends this set with India-specific guidance on distribution channels and authenticity, and adds parallel minimum fields for the AIBOM, CBOM, QBOM and HBOM categories which do not have a direct NIST counterpart. An SBOM produced in CycloneDX or SPDX format for US-federal use is generally adequate for Indian use without re-tooling.

Does the Guideline apply to SaaS imports?

The Guideline applies to the software and its accompanying BOM — not to the delivery model. A SaaS product procured into India is within scope when the procurer is a Government of India entity, a CII operator under Section 70 of the Information Technology Act, 2000, or a Regulated Entity whose sectoral framework (RBI IT Governance MD, SEBI CSCRF, IRDAI Information and Cyber Security Guidelines 2023) requires supply-chain transparency. Practitioners should expect "SBOM / AIBOM on request with contractual audit rights" clauses to become standard in SaaS procurement contracts alongside the existing data-localisation and DPA clauses.

What about open-source components — who produces the BOM?

The responsibility to produce a BOM sits with the software supplier or integrator, not with the upstream open-source project. Where the product bundles open-source components, the supplier's SBOM must list them (component name, version, licence, PURL/CPE/SWID identifiers, dependency relationships) and must be kept current with each release. For AI systems that fine-tune open-source models, the AIBOM must document the base model, the licence, the dataset used for fine-tuning, and any pre-trained weights included — a frequent gap in early AIBOM adoption.

How does this interact with CERT-In's 28 April 2022 incident-reporting Directions?

The BOM Guidelines are a supply-chain transparency instrument; the 28 April 2022 Directions are an incident-reporting instrument under Section 70B(6) of the Information Technology Act, 2000. A reportable cyber incident involving a compromised third-party component must be notified to CERT-In within 6 hours of noticing under Direction (ii) of the 2022 Directions; a well-maintained SBOM lets the Regulated Entity identify affected systems quickly, scope the incident accurately and meet the 6-hour clock without guesswork.

Sources

1. CERT-In Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM (version 2.0) — October 2024; reference CISG-2024-02. Available at https://www.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf and https://www.cert-in.org.in/s2cMainServlet?pageid=GUIDLNVIEW02&refcode=CISG-2024-02

2. CERT-In Directions under Section 70B(6) of the IT Act, 2000 — dated 28 April 2022 (No. 20(3)/2022-CERT-In). Available at https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf

3. Information Technology Act, 2000 — Sections 70 (protected systems), 70A (NCIIPC) and 70B (CERT-In). Available at https://www.indiacode.nic.in/handle/123456789/1999

4. Reserve Bank of India (Information Technology Governance, Risk, Controls and Assurance Practices) Directions, 2023 — notified 7 November 2023, effective 1 April 2024. Available at https://www.rbi.org.in/scripts/BS_ViewMasDirections.aspx?id=12562

5. SEBI Cybersecurity and Cyber Resilience Framework (CSCRF) — Master Circular — 20 August 2024; Technical Clarifications August 2025. Available at https://www.sebi.gov.in/legal/circulars/aug-2024/cybersecurity-and-cyber-resilience-framework-cscrf-for-sebi-regulated-entities-res-_85964.html

6. IRDAI Information and Cyber Security Guidelines, 2023 — 24 April 2023. Available at https://irdai.gov.in/documents/37343/366029/IRDAI+CS+Guidelines+2023.pdf/81730785-1f51-977b-5a92-d9cfd7eb2cd6

7. NCIIPC Guidelines for Protection of Critical Information Infrastructure — available at https://nciipc.gov.in/NCIIPC_Guidelines.html

8. NIST Cybersecurity Framework 2.0 — February 2024. Available at https://www.nist.gov/cyberframework

9. NIST minimum elements for a Software Bill of Materials — published 12 July 2021 pursuant to Executive Order 14028 of the United States (12 May 2021). Reference context only; the authoritative Indian baseline is the CERT-In v2.0 Guidelines.

10. EU Cyber Resilience Act — Regulation (EU) 2024/2847 — for comparative reference; Indian exporters should align to both.

This explainer is prepared by Veritect Legal Intelligence for general informational purposes and does not constitute legal advice. Entities should consult qualified counsel for engagement-specific advice. Statutory citations are current as of 21 April 2026.