How many fields does CERT-In require in an SBOM?

Twenty-one. Section 4.2 of CERT-In's Technical Guidelines v2.0 expands Table 5's 'Data Fields' element into 21 numbered entries, from Component Name through Unique Identifier. Data Fields is one of three elements in Table 5, so meeting all 21 is necessary but not sufficient: Automation Support and Practices and Processes are separate requirements.

Does the same 21-field list apply to a CBOM?

No. CERT-In sets a different minimum-elements table for each bill of materials it defines, and the lists do not overlap. A CBOM entry is governed by Table 9, which varies by asset type: algorithms need name, primitive, mode, crypto functions, classical security level and OID; keys need id, state, size and creation date; certificates need subject, issuer, validity window and format. None of those appear in Table 5.

What file formats does CERT-In accept for an SBOM?

Two: SPDX (Software Package Data Exchange) and CycloneDX. Table 5's Automation Support element names these and no others. A spreadsheet or PDF listing the same 21 fields does not satisfy the element, because the requirement is machine-readability for automated consumption, not the presence of the data.

Is CERT-In's SBOM guideline mandatory in India?

Not by its own text. For SBOM, section 1 says departments and organizations are 'encouraged to make' SBOM a mandatory standard practice in procurement, which is a recommendation to impose a requirement rather than a requirement itself. The guidelines cite no legal basis, no section of the IT Act, and no cross-reference to CERT-In's binding 2022 Directions. Section 8.4.1.1 uses 'shall' for CBOM and QBOM in government and essential-services procurement, but that clause sits under a heading titled Recommendations.

Who do the guidelines apply to?

Section 2.2 names government, public sector, essential services organizations, and organizations involved in software exports and software services, in three roles: software consumer, software developer, and system integrator or reseller. It is not aimed at private enterprise generally, and not at the financial sector specifically, which SEBI and RBI address separately.

What is a 'Known Unknown' in an SBOM?

It is one of six items under Table 5's Practices and Processes element, and it obliges you to declare where your inventory is incomplete. An SBOM that silently omits a dependency tree the toolchain could not resolve does not meet this element. One that states the gap does, which makes an honest partial inventory compliant where a confident-looking incomplete one is not.

Do SEBI and RBI require the same fields?

Neither names a format or a field list. SEBI's CSCRF requires regulated entities to maintain an inventory of cryptographic assets and prioritise critical ones for PQC migration; IRDAI's 2026 guidelines add an audited control requiring insurers to maintain the same. Because neither specifies what an entry must contain, CERT-In's tables are the most detailed Indian reference available to fill that gap, not a rule those regulators have adopted.

What does AIBOM's 'Out of Scope Usage' field require?

Table 10 asks you to document uses the AI model is not intended for and should be avoided, alongside Intended Usage. It is unusual among BOM fields because it records a negative: stating what a model must not be used for turns misuse into a documented deviation rather than a judgement made after an incident.

sbomcbomqbomaibomhbomindiacert-in

The 21 Data Fields CERT-In Requires in an SBOM, and the Separate Lists for CBOM, AIBOM and HBOM

CERT-In's Technical Guidelines v2.0 sets a different minimum-elements table for each bill of materials it defines. Here are all four, field by field, from the primary document, with the distinction most summaries get wrong.

PQC Security EditorialOctober 1, 20267 min read

If you have been asked to produce an SBOM for an Indian government or public-sector contract, the requirement you are being measured against is almost certainly Table 5 of CERT-In's "Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM," Version 2.0, dated 9 July 2025.

Most secondary summaries of that document describe the fields in general terms. The list below is the document's own, taken from section 4.2, which expands Table 5's "Data Fields" element into 21 numbered entries.

One distinction is worth settling before the list, because it is the thing most often got wrong: CERT-In does not set one minimum-elements table for all five BOM types. SBOM, QBOM, AIBOM and HBOM each get their own, and the lists do not overlap. Applying Table 5 to a CBOM deliverable produces the wrong artefact.

Table 5: the 21 SBOM data fields

Section 4.1 defines "Minimum Elements of SBOM" as three things, not one: Data Fields, Automation Support, and Practices and Processes. The 21 items below are the Data Fields element only.

Component Name. The name of the software component or library included in the SBOM.
Component Version. The version number or identifier of the software component.
Component Description. A brief description or summary of the functionality and purpose of the software component.
Component Supplier. The entity or organization that supplied the software component, such as a vendor, third-party supplier, or open-source project.
Component License. The license under which the software component is distributed, including details such as the license type, terms, and restrictions.
Component Origin. The source or origin of the software component, such as whether it is proprietary, open-source, or obtained from a third-party vendor.
Component Dependencies. Any other software components or libraries that the current component depends on, including their names and versions.
Vulnerabilities. Information about known security vulnerabilities or weaknesses associated with the software component, including severity ratings and references to security advisories or CVE identifiers.
Patch Status. Whether any patches or updates are available to address known vulnerabilities or issues.
Release Date. The date when the software component was released or made available for use.
End-of-Life (EOL) Date. The date when support or maintenance for the component is scheduled to end.
Criticality. The importance of the component to the overall functionality or security of the application, often categorized as critical, high, medium, or low.
Usage Restrictions. Any restrictions or limitations associated with the component, such as export control restrictions or intellectual property rights.
Checksums or Hashes. Cryptographic checksums or hashes of the component files to ensure integrity and authenticity.
Comments or Notes. Additional comments, notes, or annotations relevant to the component or its inclusion in the SBOM.
Author of SBOM Data. The name of the entity that creates the SBOM data for this component.
Timestamp. Record of the date and time of the SBOM data assembly.
Executable Property. Attributes indicating whether a component within an SBOM can be executed.
Archive Property. Characteristics denoting if a component is stored as an archive or compressed file.
Structured Property. Descriptors defining the organized format of data within a component listed in an SBOM.
Unique Identifier. A distinct code assigned to each component, structured as pkg:supplier/OrganizationName/ComponentName@Version?qualifiers&subpath.

That last one is a purl (package URL). The syntax in the guidelines is the purl specification, so a toolchain that already emits purls satisfies field 21 without extra work.

The two elements people skip

Automation Support. Table 5 names two acceptable formats and no others: SPDX (Software Package Data Exchange) and CycloneDX. A spreadsheet is not an SBOM under this table, however complete its 21 columns are.

Practices and Processes. This is where the operational requirements live, and it is the element most often dropped from summaries entirely. Table 5 lists six: Frequency, Depth, Known Unknowns, Distribution and Delivery, Access Control, and Accommodation of Mistakes.

"Known Unknowns" is worth pausing on. It requires you to declare where your inventory is incomplete. An SBOM that silently omits a dependency tree it could not resolve does not meet this element; one that says so does.

Table 8: the QBOM elements, and where CBOM sits

Section 8 covers QBOM and CBOM together, and Table 8 lists eleven elements describing a quantum device or system: Model Name, Version, Vendor & Origin Information, License Information, Cryptographic Asset, Communication Protocol, Hardware, Software Dependencies, Environmental Impact, Vulnerabilities, and Attestations.

The fifth of those, Cryptographic Asset, is a pointer. Table 9 defines what a cryptographic asset entry contains, and it varies by asset type:

Algorithms — name, asset type, primitive, mode, crypto functions, classical security level, OID. The document's own example is AES-128-GCM, OID 2.16.840.1.101.3.4.1.6.
Keys — name, asset type, id, state, size, creation date, activation date.
Protocols — name, asset type, version, cipher suites, OID.
Certificates — name, asset type, subject name, issuer name, not-valid-before, not-valid-after, signature algorithm reference, subject public key reference, certificate format, certificate extension.

A CBOM built from Table 5's software fields will be missing every one of these. They describe different objects.

Tables 10 and 11: AIBOM and HBOM

Table 10 (AIBOM) sets nineteen elements, and they reach well past a component list: Model Name, Model Version, Model Type, Model Developer, Model Licensing Information, Software Dependencies, ML Models and Algorithms, Model Performance Metrics, Data Source, Data Sets, Hardware, Security Requirements, Input, Output, Intended Usage, Out of Scope Usage, Environmental Impact, Vulnerabilities, Attestations.

Out of Scope Usage is unusual enough to flag: CERT-In asks you to document what the model is not built for. That makes misuse a documented deviation rather than a judgement call after the fact.

Table 11 (HBOM) covers the product and each component beneath it, and it is explicitly recursive: where a component contains further hardware parts, those are listed with the same attributes. Product Name, Product Version, Product Details, Warranty/AMC, Manufacturer Name, Manufacturer Location, Manufacturing Date, Supplier Information, Supplier Location, Model Number, Serial Number, Technical Specification, Technology Node, Compliance, Power supply, License Information, Test Result, Sub-component.

Manufacturer and supplier details appear twice, once at product level and once per component, because the company that made a part is rarely the one that sold it to you.

What this does and does not oblige you to do

The guidelines are framed as guidance issued to named sectors, not as a statute. They cite no legal basis, no section of the IT Act, and no cross-reference to CERT-In's 2022 Directions, which are binding. That analysis is set out in our deep dive on the guidelines, and it has not changed.

What has changed is who points at them. SEBI's CSCRF requires regulated entities to maintain a cryptographic asset inventory, and IRDAI's 2026 guidelines add an audited control requiring the same of insurers — neither names a format, and CERT-In's tables are the most detailed Indian specification available to fill that gap. The India country page tracks both, with the circular numbers and dates.

If a procurement contract names these guidelines, the tables above are what you are being measured against. If it does not, they remain the most complete published answer to what an Indian regulator expects in a bill of materials, which is a different and weaker claim.

Primary source

Every field list above is taken from CERT-In, Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, 9 July 2025: Table 5 and section 4.2 (pages 20–22), Table 8 (page 44), Table 9 (pages 45–47), Table 10 (pages 54–55), Table 11 (pages 60–61).

Frequently asked questions

How many fields does CERT-In require in an SBOM?: Twenty-one. Section 4.2 of CERT-In's Technical Guidelines v2.0 expands Table 5's 'Data Fields' element into 21 numbered entries, from Component Name through Unique Identifier. Data Fields is one of three elements in Table 5, so meeting all 21 is necessary but not sufficient: Automation Support and Practices and Processes are separate requirements.
Does the same 21-field list apply to a CBOM?: No. CERT-In sets a different minimum-elements table for each bill of materials it defines, and the lists do not overlap. A CBOM entry is governed by Table 9, which varies by asset type: algorithms need name, primitive, mode, crypto functions, classical security level and OID; keys need id, state, size and creation date; certificates need subject, issuer, validity window and format. None of those appear in Table 5.
What file formats does CERT-In accept for an SBOM?: Two: SPDX (Software Package Data Exchange) and CycloneDX. Table 5's Automation Support element names these and no others. A spreadsheet or PDF listing the same 21 fields does not satisfy the element, because the requirement is machine-readability for automated consumption, not the presence of the data.
Is CERT-In's SBOM guideline mandatory in India?: Not by its own text. For SBOM, section 1 says departments and organizations are 'encouraged to make' SBOM a mandatory standard practice in procurement, which is a recommendation to impose a requirement rather than a requirement itself. The guidelines cite no legal basis, no section of the IT Act, and no cross-reference to CERT-In's binding 2022 Directions. Section 8.4.1.1 uses 'shall' for CBOM and QBOM in government and essential-services procurement, but that clause sits under a heading titled Recommendations.
Who do the guidelines apply to?: Section 2.2 names government, public sector, essential services organizations, and organizations involved in software exports and software services, in three roles: software consumer, software developer, and system integrator or reseller. It is not aimed at private enterprise generally, and not at the financial sector specifically, which SEBI and RBI address separately.
What is a 'Known Unknown' in an SBOM?: It is one of six items under Table 5's Practices and Processes element, and it obliges you to declare where your inventory is incomplete. An SBOM that silently omits a dependency tree the toolchain could not resolve does not meet this element. One that states the gap does, which makes an honest partial inventory compliant where a confident-looking incomplete one is not.
Do SEBI and RBI require the same fields?: Neither names a format or a field list. SEBI's CSCRF requires regulated entities to maintain an inventory of cryptographic assets and prioritise critical ones for PQC migration; IRDAI's 2026 guidelines add an audited control requiring insurers to maintain the same. Because neither specifies what an entry must contain, CERT-In's tables are the most detailed Indian reference available to fill that gap, not a rule those regulators have adopted.
What does AIBOM's 'Out of Scope Usage' field require?: Table 10 asks you to document uses the AI model is not intended for and should be avoided, alongside Intended Usage. It is unusual among BOM fields because it records a negative: stating what a model must not be used for turns misuse into a documented deviation rather than a judgement made after an incident.