CERT-In QBOM requirements: Table 8 elements and recommendations

CERT-In's Version 2.0 BOM guidelines give India its first official definition of a QBOM. This is what they ask for, element by element, and what they say about migration.

The document

CERT-In published Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025 ^[1]. Version 2.0 extends CERT-In's earlier SBOM guidance to cryptographic, quantum, AI and hardware bills of materials, a change law firms advising Indian clients have highlighted as a significant widening of scope ^[2][3]. Section 8 covers the QBOM and CBOM together.

Definition (section 8.1)

CERT-In states that a Quantum Bill of Materials "focuses on components related to quantum computing and quantum-safe cryptography", including quantum algorithms, security frameworks and related technologies, and that QBOMs help organisations maintain integrity, compliance and resilience as they adopt post-quantum cryptographic solutions ^[1]. Section 8.2 describes QBOM and CBOM together as a unified foundation for securing cryptographic systems and assessing readiness for post-quantum security ^[1].

Table 8: minimum elements

Element names and descriptions are from Table 8 ^[1]; the last column is our suggestion.

The Cryptographic Asset element (Table 9)

Table 9 lists minimum fields by asset type ^[1]:

• Algorithms: name, asset type, primitive, mode, crypto functions, classical security level, OID, list.
• 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, validity dates, signature algorithm reference, subject public key reference, certificate format and extensions.

These map closely to CycloneDX 1.6 cryptoProperties, which has matching fields such as primitive, mode, cryptoFunctions, classicalSecurityLevel, key state and size, and protocol cipherSuites ^[4].

Recommendations (section 8.4)

• Government, public sector and essential services organisations should require a CBOM for cryptographic assets, and a QBOM for quantum systems, in related procurements, developments and integrations.
• Suppliers of software, systems or devices involving cryptographic or quantum technologies should provide a complete CBOM and/or QBOM.
• Organisations should maintain an accurate, up-to-date CBOM/QBOM for systems they use, develop or procure, with transparency into hardware, software, algorithms and protocols.
• BOMs should use recognised formats such as SPDX or CycloneDX.
• Developers should issue VEX with status Not Affected, Affected, Fixed or Under Investigation, and BOM data should be integrated with vulnerability databases, CERT-In advisories, threat intelligence and vendor bulletins.
• Consumers should create an internal CBOM/QBOM aligned with supplier data and use it in vulnerability management.
• Inventories should be audited periodically, stored and transmitted securely, and updated as new components, algorithms or quantum technologies are introduced.

Source: section 8.4 ^[1]. The best practices add a single access-controlled inventory, complete keymaps from root to leaf, version control, dependency mapping that separates libraries implementing algorithms from applications using them, automation, periodic risk assessment, alignment with NIST, ETSI and CERT-In standards, and cross-functional collaboration ^[1].

Migration strategy (section 8.5)

CERT-In notes that RSA, ECC, Diffie-Hellman and DSA are vulnerable to Shor's algorithm and recommends quantum-resistant schemes based on lattice-based, code-based and multivariate primitives. It recommends a risk-based approach using cryptographic validation testing, independent assessments and adversarial simulation, guided by threat exposure, technical feasibility and risk tolerance. It also recommends tiered vendor PQC contractual requirements ^[1]; see PQC procurement requirements.

How to comply in practice

1. Build the CBOM first; it fills the Cryptographic Asset element (see QBOM vs CBOM).
2. Populate Table 8 from SBOM, HBOM and procurement data; flag gaps rather than leaving fields blank.
3. Publish in CycloneDX or SPDX, signed, with version history.
4. Add the clauses in section 8.5 to supplier contracts.

See How to build a QBOM for the full sequence.

How IntelliXBOM helps

IntelliXBOM validates QBOMs and CBOMs against CERT-In's Table 8 and Table 9 fields and reports missing elements. It ingests and generates CycloneDX and SPDX, records VEX decisions, keeps version history, and produces timestamped evidence mapped to the guideline's recommendations. This article summarises public guidance and is not legal advice; check how the guidelines apply to your organisation with CERT-In, your regulator or your legal adviser.