CERT-In Software Supply Chain Security Guidance: The Complete Compliance Guide

01Background

CERT-In (the Indian Computer Emergency Response Team, under the Ministry of Electronics and Information Technology) first published Technical Guidelines on Software Bill of Materials (SBOM) in October 2024, addressing software composition transparency alone. On 9 July 2025, CERT-In released Version 2.0 — retitled Technical Guidelines on SBOM | QBOM & CBOM | AIBOM | HBOM — expanding the same underlying philosophy across five distinct bill-of-materials types instead of one.

That expansion tracks a real shift in what "software supply chain" risk actually means. A 2021-era SBOM mandate assumed the main risk was an undisclosed open-source dependency. By 2025, the same organizations also need to reason about which cryptographic algorithms are embedded in their products (relevant to post-quantum migration), what physical hardware and firmware make up a device, what data and models sit inside an AI system, and — looking further ahead — what quantum-computing components a product integrates. CERT-In's v2.0 guidelines fold all five into one coherent framework rather than issuing five separate documents.

02Objectives

Reading across the guidelines and how CERT-In and independent analysts describe their intent, four objectives stand out:

• Transparency by default. Make "what's actually inside this product" a standard, structured, machine-readable answer — not a manual, ad-hoc one produced only when an incident forces the question.
• Faster, more precise vulnerability response. When a new CVE breaks, organizations with structured BOMs and VEX/CSAF data can determine exposure in minutes rather than days.
• Risk-aware procurement. Give government and essential-services buyers a structured basis for evaluating supply chain risk before, not after, deployment.
• Alignment with global practice. Keep India's approach interoperable with the US Executive Order 14028 / NTIA baseline, CISA guidance, and the EU Cyber Resilience Act, so Indian software exporters aren't maintaining a wholly separate compliance track.

03Who should comply

The guidelines are addressed to government bodies and departments, public sector organizations, essential-services operators, software producers, and software services/export entities. Their legal character is best described as strongly encouraged guidance rather than a penalty-backed statute — but "encouraged" carries real weight for organizations that sell into government or regulated sectors, where BOM submission is increasingly becoming a de facto procurement expectation even without a codified fine for non-compliance.

That baseline is reinforced, not replaced, by sector regulators who have issued their own, more directly binding instruments:

For the full field-level detail on SBOM specifically, see CERT-In SBOM requirements explained. For a sector-specific walkthrough, see CERT-In compliance for banks and NBFCs.

04Requirements by BOM type

Each BOM type has its own minimum-elements section in the official guidelines. Page references below are to the official v2.0 PDF, for readers who want to go straight to the primary source.

SBOM

The most mature requirement, carried over from v1.0: 21 minimum data fields per component, SPDX or CycloneDX accepted, SPDX license identifiers recommended, and companion VEX/CSAF documents expected for vulnerability communication. Full breakdown: CERT-In SBOM requirements.

CBOM

CBOM inventories the cryptographic assets embedded in a system — encryption algorithms, key-management modules, and certificates. This matters most immediately for organizations planning a post-quantum cryptography migration: you can't replace what you can't first enumerate. CycloneDX 1.6 added a formal cryptographic-asset component type that can represent this data directly, illustrated below.

{
  "type": "cryptographic-asset",
  "name": "TLS-server-certificate",
  "cryptoProperties": {
    "assetType": "certificate",
    "algorithmProperties": {
      "primitive": "signature",
      "parameterSetIdentifier": "RSA-2048"
    }
  }
}

Full explainer: What is CBOM?

HBOM

HBOM covers the physical layer: components, sub-components, embedded devices and associated materials that make up a hardware product. This is most relevant to organizations building or procuring embedded systems, IoT devices, or hardware for critical infrastructure, where firmware and physical provenance carry distinct risk from application-layer software. Schema tooling here is still early — CycloneDX has an HBOM profile, but ecosystem-wide generator maturity lags SBOM significantly. Full explainer: What is HBOM?

AIBOM

AIBOM inventories what goes into building, training and deploying an AI system — datasets, model weights, training pipeline dependencies, and any third-party models incorporated by reference. This category is moving fastest given India's parallel and growing AI governance focus, but standardized generation tooling remains less mature than traditional SCA tooling. Full explainer: What is AIBOM?

QBOM

QBOM is the most forward-looking category: documenting quantum-computing elements integrated into a product. For most organizations today this is less about auditing existing quantum hardware and more about building the inventory habit now, ahead of the broader post-quantum cryptography transition that CBOM and QBOM together are meant to support. Full explainer: What is QBOM?

05Implementation roadmap

CERT-In's v2.0 guidelines describe a phased maturity model rather than expecting immediate, full compliance across all five BOM types. Independent legal and industry analysis of the guidelines summarizes it as a three-stage progression:

This sequencing matches the tooling-maturity reality in §4: Start/Progress focus on SBOM (and, where feasible, HBOM); Advance is where CBOM, AIBOM and eventually QBOM realistically enter the picture for most organizations.

06Governance

The Advance phase explicitly calls for distributing BOM governance across security, legal, and procurement functions, backed by periodic training and internal audits — not leaving BOM ownership as an unassigned side-responsibility of one engineering team. Several independent implementations of the guidelines further recommend naming a single accountable owner (sometimes framed as a "BOM Management Officer" role) to coordinate across those functions, even though the official guidelines describe the responsibility in terms of distributed roles rather than mandating a specific job title.

07Compliance workflow

Putting the roadmap and governance model into a single operational loop:

1. Require. BOM submission is written into procurement policy and vendor contracts.
2. Generate. BOMs are produced automatically as part of the build, not requested after the fact.
3. Validate. Structure and required fields are checked — see our free SBOM Validator for a first-pass check.
4. Risk review. Security correlates the BOM against vulnerability and VEX/CSAF data, and assigns criticality where CERT-In's fields require human judgment.
5. Sign-off and retention. Governance function signs off and retains the BOM against the applicable version, ready for audit or submission.

08Common challenges

09Best practices

• Start with SBOM and get it fully automated in CI/CD before investing heavily in CBOM/HBOM/AIBOM tooling.
• Adopt SPDX or CycloneDX now — both are accepted, and standardizing early avoids a costly format migration later.
• Write BOM submission into vendor and procurement contracts during the Start phase, not retroactively.
• Assign a single accountable owner for cross-functional coordination, whatever the title.
• Reuse one compliance program across CERT-In, RBI and SEBI rather than running parallel efforts.
• Treat CBOM as a starting point for post-quantum cryptography planning, not an isolated checkbox.
• Revisit your roadmap phase (Start/Progress/Advance) at least annually as tooling for the newer BOM types matures.

10Frequently asked questions

11Official references

• CCERT-In — Technical Guidelines on SBOM | QBOM & CBOM | AIBOM | HBOM, Version 2.0cert-in.org.in/PDF · dated 9 July 2025↗
• CCERT-In — Technical Guidelines on Software Bill of Materials (SBOM), v1.0cert-in.org.in · refcode CISG-2024-02 (October 2024)↗
• CCERT-In — Directions No. 20(3)/2022-CERT-Incert-in.org.in (28 April 2022) — the separate incident-reporting directive↗
• NNTIA — The Minimum Elements For a Software Bill of Materials (SBOM)ntia.gov (July 2021)↗
• EEU Cyber Resilience Actdigital-strategy.ec.europa.eu↗