CERT-In SBOM Requirements Explained

01What the guidelines cover

In October 2024, CERT-In (India's Computer Emergency Response Team, under the Ministry of Electronics and Information Technology) published its Technical Guidelines on Software Bill of Materials (SBOM) — a roughly 40-page document establishing how organizations in scope should create, structure, and maintain SBOMs. In July 2025, a version 2.0 update broadened the guidance beyond software alone to the full xBOM family — SBOM, QBOM, CBOM, AIBOM and HBOM — reflecting how quickly the underlying risk landscape has expanded beyond traditional application dependencies.

Unlike CERT-In's binding Directions 20(3)/2022-CERT-In (the April 2022 rules requiring 6-hour incident reporting and extended log retention), the SBOM guidelines are framed as technical guidance rather than a legally enforced directive with stated penalties. That distinction matters: the two documents are frequently confused, but they serve different purposes and carry different legal weight. This page covers the SBOM guidelines specifically — for the incident-reporting rules, see the CERT-In Guidelines Overview.

02Who must comply

CERT-In's guidelines are explicitly addressed to five overlapping groups:

• Government bodies and departments procuring or operating software
• Public sector organizations (PSUs)
• Essential services operators — critical infrastructure sectors as defined under India's broader cybersecurity framework
• Software producers supplying products into any of the above
• Software services and export entities, given India's position as a major software exporter

What makes this more than a single national requirement is that sector regulators have independently layered their own SBOM expectations on top of CERT-In's baseline:

In practice, a regulated bank or fintech in India may need to satisfy CERT-In's guidelines and RBI's circular and SEBI's CSCRF simultaneously — the field-level requirements overlap heavily but aren't guaranteed to be identical. See CERT-In compliance for banks and NBFCs for a sector-specific breakdown.

03The 21 data fields

CERT-In's guidelines define 21 minimum data fields per component — a meaningfully broader set than NTIA's 2021 baseline of seven fields. They span four categories: component identity, dependency relationships, vulnerability and lifecycle status, and integrity.

See the field-by-field mapping against SPDX and CycloneDX schema properties in the minimum viable SBOM fields reference.

04Accepted formats

CERT-In does not mandate a single proprietary format. The guidelines accept either SPDX or CycloneDX — both internationally standardized (ISO/IEC 5962:2021 and ECMA-424 respectively) and both with mature open-source tooling. Two additional technical recommendations sit alongside format choice:

• Licensing: use SPDX license identifiers for the license field, regardless of which BOM format you generate the document in — SPDX's license list has effectively become the shared vocabulary even for CycloneDX users.
• Vulnerability exploitability: generate a companion VEX document alongside the SBOM to communicate whether known vulnerabilities in listed components are actually exploitable in context, rather than leaving the SBOM's consumer to guess.

Since CERT-In's schema-level fields (criticality, executable property, archived property, end-of-life date) aren't part of the base SPDX or CycloneDX specification, they need to be carried as extension/custom properties. CycloneDX's properties array is the most common mechanism in practice — see the example below.

05Update requirements

CERT-In's guidance specifies a version-based update model rather than a fixed calendar cadence: maintain a separate SBOM for each software version, and update an existing SBOM only when additional component information becomes available or when errors in the document are identified and corrected. In practice, for teams shipping continuously, this means SBOM generation belongs in the release pipeline itself — see CI/CD integration tutorials — rather than as a periodic manual exercise.

06How it compares globally

CERT-In's guidelines were explicitly designed with reference to the US Executive Order 14028 / NTIA baseline, CISA's ongoing guidance, and the EU's Cyber Resilience Act — but the requirements aren't identical.

See the dedicated CERT-In vs. NIST vs. CISA comparison and India vs. EU Cyber Resilience Act articles for a deeper treatment of each.

07Examples

Generating a base CycloneDX SBOM is a single command with most modern scanners:

syft dir:. -o cyclonedx-json=sbom.cdx.json

The base output covers identity, relationship and integrity fields automatically. CERT-In's lifecycle and risk fields — criticality, executable/archived status, end-of-life date — get added as custom properties during review:

{
  "type": "library",
  "name": "log4j-core",
  "version": "2.22.1",
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.22.1",
  "licenses": [{ "license": { "id": "Apache-2.0" } }],
  "properties": [
    { "name": "cert-in:criticality", "value": "high" },
    { "name": "cert-in:executable", "value": "true" },
    { "name": "cert-in:archived", "value": "false" },
    { "name": "cert-in:end-of-life-date", "value": "2027-01-01" }
  ]
}

This is a working pattern, not a required schema — CERT-In does not publish a formal CycloneDX extension profile, so the property naming convention above is a reasonable practice, not a compliance requirement in itself. See more complete examples in the SBOM JSON examples reference.

08Advantages

09Implementation steps

1. Confirm applicability. Determine whether you're in scope directly via CERT-In (government/PSU/essential-services/software-export) and check for sector-regulator overlays (RBI, SEBI, Ministry of Power).
2. Pick a format. SPDX or CycloneDX — both satisfy CERT-In. See choosing the right SBOM standard.
3. Automate the 14 automatable fields. Wire SBOM generation into your build pipeline using tools like Syft, cdxgen or CycloneDX CLI — see generation tutorials.
4. Build a review process for the remaining 7. Criticality, EOL date, patch status and usage restrictions need a human owner, typically shared between security and engineering.
5. Adopt SPDX license identifiers for the license field, even if you're generating in CycloneDX.
6. Generate a companion VEX document once you have a working vulnerability-scanning process — see scanning tutorials.
7. Version SBOMs per release, updating only on component-info changes or corrections, per CERT-In's stated cadence.
8. Run a self-assessment before your first formal submission — see CERT-In readiness self-assessment.

10Common mistakes

• Confusing the SBOM guidelines with the 2022 incident-reporting Directions — they're separate instruments with separate obligations.
• Assuming full automation covers all 21 fields — roughly a third require deliberate human review.
• Treating CERT-In, RBI and SEBI obligations as identical without checking each regulator's specific circular for a regulated entity.
• Generating an SBOM once and never updating it, despite CERT-In's explicit per-version update expectation.
• Skipping the VEX companion document, leaving consumers of your SBOM unable to tell which listed vulnerabilities actually matter.
• Inventing a CycloneDX extension schema without documenting it for downstream consumers, since CERT-In hasn't published an official one.

11Best practices

• Map your 21-field compliance checklist once, and reuse it across CERT-In, RBI and SEBI obligations rather than three separate processes.
• Document your custom-property naming convention (like the cert-in:* prefix used above) so downstream consumers and auditors can interpret it consistently.
• Assign explicit ownership for the seven manual-input fields — don't leave them as an unowned gap between security and engineering.
• Re-run your self-assessment ahead of any major release or audit cycle, not just once at program kickoff.
• Keep SBOM and VEX generation in the same pipeline stage so they never drift out of sync with each other.

12Frequently asked questions

13Official references

• CCERT-In — Technical Guidelines on Software Bill of Materials (SBOM)cert-in.org.in · refcode CISG-2024-02 (October 2024, v2.0 July 2025)↗
• 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↗