CERT-In CBOM requirements: the four asset types and their fields
CERT-In's Version 2.0 guidelines give India a field-level definition of a CBOM. This article sets out every minimum element by asset type, maps each to CycloneDX, and summarises the recommendations that surround them.
- CERT-In's Technical Guidelines v2.0 (9 July 2025) define CBOM minimum elements for four asset types: algorithms, keys, protocols and certificates.
- Algorithms have eight elements, keys seven, protocols five and certificates ten.
- Most elements map directly to CycloneDX 1.6 cryptoProperties fields; a few, such as the algorithm 'List' element, need an agreed convention.
- Section 8.4.1 recommends CBOMs in government, public sector and essential services procurement, SPDX or CycloneDX formats, VEX and periodic audits.
- Best practice 8.4.2.8 calls for reviews at least quarterly.
Where the requirements come from
CERT-In's "Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM", Version 2.0, dated 9 July 2025, cover the CBOM and QBOM together in Section 8 [1]. Section 8.3 sets minimum elements, with the CBOM elements in Table 9; Section 8.4 gives recommendations and best practices; Section 8.5 covers quantum readiness. The guidelines state that BOMs should use SPDX or CycloneDX (8.4.1.5); the field names in Table 9 closely follow the CycloneDX cryptography model introduced in version 1.6 [3].
Algorithms
| CERT-In element | Meaning (per CERT-In) | CycloneDX 1.6 field |
|---|---|---|
| Name | Name of the algorithm, e.g. AES-128-GCM | name |
| Asset Type | "algorithm" | cryptoProperties.assetType |
| Primitive | The cryptographic primitive; for SHA512withRSA, "signature" | algorithmProperties.primitive |
| Mode | Operational mode, e.g. gcm | algorithmProperties.mode |
| Crypto Functions | Functions supported, e.g. key generation, encryption, decryption, tag generation | algorithmProperties.cryptoFunctions |
| Classical security level | Strength against classical attacks | algorithmProperties.classicalSecurityLevel (bits) |
| OID | Globally unique object identifier for the algorithm | cryptoProperties.oid |
| List | Algorithms employed by the device or system, to assess its capabilities, particularly regarding post-quantum standards | No single field; typically expressed as the set of algorithm components linked to a system |
Keys
| CERT-In element | Meaning (per CERT-In) | CycloneDX 1.6 field |
|---|---|---|
| Name | Name identifying the key | name |
| Asset Type | "key" | assetType = related-crypto-material, with type such as private-key or secret-key |
| id | Unique identifier such as a key ID | relatedCryptoMaterialProperties.id |
| state | E.g. active, revoked or expired | relatedCryptoMaterialProperties.state (pre-activation, active, suspended, deactivated, compromised, destroyed) |
| size | Key size in bits | relatedCryptoMaterialProperties.size |
| Creation Date | When the key was created | relatedCryptoMaterialProperties.creationDate |
| Activation Date | When the key became operational | relatedCryptoMaterialProperties.activationDate |
Note that CERT-In's examples of key state ("revoked", "expired") are not values in the CycloneDX state enumeration [2]; agree a mapping, for example recording expiry through expirationDate.
Protocols
| CERT-In element | Meaning (per CERT-In) | CycloneDX 1.6 field |
|---|---|---|
| Name | E.g. TLS, IPsec, SSH | name; protocolProperties.type |
| Asset Type | "protocol" | assetType |
| Version | E.g. TLS 1.2 or 1.3 | protocolProperties.version |
| Cipher Suites | Algorithms and parameters supported for encryption, key exchange and integrity | protocolProperties.cipherSuites |
| OID | Identifier for the protocol's specification | oid |
Certificates
| CERT-In element | Meaning (per CERT-In) | CycloneDX 1.6 field |
|---|---|---|
| Name | Usually the subject or entity, e.g. a website | name |
| Asset Type | "certificate" | assetType |
| Subject Name | Distinguished Name of the entity | certificateProperties.subjectName |
| Issuer Name | The issuing certificate authority | certificateProperties.issuerName |
| Not Valid Before | Start of validity | certificateProperties.notValidBefore |
| Not Valid After | Expiry | certificateProperties.notValidAfter |
| Signature Algorithm Reference | Algorithm used to sign the certificate | certificateProperties.signatureAlgorithmRef |
| Subject Public Key Reference | The subject's public key | certificateProperties.subjectPublicKeyRef |
| Certificate Format | E.g. X.509 | certificateProperties.certificateFormat |
| Certificate Extension | File extension, e.g. .crt | certificateProperties.certificateExtension |
Field meanings are summarised from Table 9 of the guidelines [1]; CycloneDX field names are from the 1.6 schema [2].
Recommendations around the fields
- 8.4.1.1government, public sector and essential services organisations shall require CBOMs in related procurements, developments and integrations.
- 8.4.1.2suppliers must provide a complete CBOM for delivered solutions.
- 8.4.1.6 and 8.4.1.11issue VEX on vulnerabilities in cryptographic components and cross-reference CBOM data with VEX status.
- 8.4.1.7integrate CBOM data with vulnerability databases, CERT-In advisories, threat intelligence and vendor bulletins.
- 8.4.1.10periodic audits for completeness and accuracy.
- 8.4.1.12store and transmit CBOM data with encryption, access control and integrity mechanisms.
- 8.4.2.8scheduled reviews at least quarterly.
All from CERT-In's guidelines [1]. Related Indian expectations include SEBI's CSCRF FAQs on inventories of keys, certificates and algorithms [4] and the DST task force's call for compulsory bills of materials in government RFPs [5].
How IntelliXBOM helps
IntelliXBOM validates CBOMs against a CERT-In required-field policy and reports missing elements per asset. It keeps version history for quarterly reviews, records VEX decisions, and maps the inventory to CERT-In recommendations with timestamped evidence.
This article summarises public guidance and is not legal advice; refer to the CERT-In document for the authoritative text.
Frequently asked questions
What fields does CERT-In require in a CBOM?
CERT-In's Table 9 lists minimum elements for four asset types. Algorithms: Name, Asset Type, Primitive, Mode, Crypto Functions, Classical security level, OID and List. Keys: Name, Asset Type, id, state, size, Creation Date and Activation Date. Protocols: Name, Asset Type, Version, Cipher Suites and OID. Certificates: Name, Asset Type, Subject Name, Issuer Name, Not Valid Before, Not Valid After, Signature Algorithm Reference, Subject Public Key Reference, Certificate Format and Certificate Extension.
Does CERT-In require CycloneDX for CBOMs?
No. The guidelines recommend recognised industry formats such as SPDX or CycloneDX. CycloneDX has dedicated cryptographic-asset structures whose field names closely match CERT-In's Table 9.
How often should a CBOM be reviewed under CERT-In guidance?
Best practice 8.4.2.8 calls for changes to be reflected promptly and for scheduled reviews at least quarterly to verify accuracy and completeness.
Sources
- Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0 (9 July 2025)CERT-In, Government of Indiawww.cert-in.org.in/PDF/TechnicalGuidelines-on-SBOM,QBOM&CBOM,AIBOM_and_HBOM_ver2.0.pdf
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- CycloneDX v1.6 Released, Advances Software Supply Chain Security with Cryptographic Bill of Materials and Attestations (9 April 2024)OWASP CycloneDXcyclonedx.org/news/cyclonedx-v1.6-released/
- FAQs on Cybersecurity and Cyber Resilience Framework (CSCRF) for SEBI REs (11 June 2025)SEBIwww.sebi.gov.in/sebi_data/faqfiles/jun-2025/1749647139924.pdf
- Implementation of Quantum Safe Ecosystem in India: Report of the Task Force (February 2026)Department of Science and Technology, Government of Indiadst.gov.in/sites/default/files/Report_TaskForce_PQMigration_4Feb26%20(v1).pdf
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.