CBOM procurement requirements for suppliers
Much of an organisation's cryptography lives inside products it buys. Procurement is where you secure visibility into it. These are the requirements to put in RFPs and contracts.
- CERT-In recommends that government, public sector and essential services organisations require CBOMs in related procurements, and that suppliers provide complete CBOMs.
- CERT-In's recommendation 8.5.4 proposes tiered vendor PQC requirements, including quarterly migration reports with C-level attestation.
- India's DST task force recommends common procurement requirements across government RFPs, with a compulsory bill of materials and crypto-agile assets.
- Specify format, fields, update triggers, VEX, secure delivery and a PQC roadmap, and validate what you receive.
- The G7 Cyber Expert Group identifies limited vendor transparency as a barrier to financial-sector PQC planning.
Why procurement is the lever
Core banking systems, network appliances, identity platforms, OT equipment and SaaS all bring their own cryptography, and buyers rarely have the source code to inspect it. The G7 Cyber Expert Group's financial-sector roadmap names "limited transparency, including obtaining detailed vendor roadmaps for specific cloud and cryptographic services" as a barrier to planning [3]. Contract terms are the most reliable way to close that gap.
What the guidance says
- CERT-In 8.4.1.1: government, public sector and essential services organisations "shall require" a CBOM for cryptographic assets "in all related procurements, developments, and integrations" [1].
- CERT-In 8.4.1.2: suppliers "must provide a complete CBOM and/or QBOM detailing all components, algorithms, technologies, and dependencies present in the delivered solution" [1].
- CERT-In 8.5.4: implement tiered vendor PQC contractual requirements, service providers to document all cryptographic implementations, provide quarterly migration progress reports with C-level executive attestation, accept penalty clauses for non-compliance, and demonstrate quantum-safe alternatives through proofs of concept before contract renewal [1].
- DST task force: "common procurement requirements across all government RFPs shall ensure crypto-agile and PQC-compliant assets, along with compulsory Bill of Materials" [2].
Requirements to specify
| Area | Requirement |
|---|---|
| Scope | All cryptography in the delivered product, including bundled libraries, firmware, cloud-hosted components and cryptography provided by third-party subcomponents |
| Format | CycloneDX 1.6 or later, using cryptographic-asset components and cryptoProperties [4]; SPDX accepted only if equivalent fields are present |
| Fields | At minimum, CERT-In Table 9 elements for algorithms, keys, protocols and certificates [1] |
| Linkage | Each cryptographic asset linked to the product component that implements or uses it |
| Configurability | For each algorithm, whether it can be changed by configuration, by update, or not at all |
| Updates | New CBOM with each major release, when cryptographic components change, and on request |
| Vulnerabilities | VEX statements for vulnerabilities in cryptographic components, as CERT-In recommends (8.4.1.6) [1] |
| PQC roadmap | Dates for supporting standardised post-quantum algorithms, hybrid options, and end of support for quantum-vulnerable-only configurations |
| Integrity and delivery | Signed or hashed CBOMs delivered through an access-controlled channel; the CycloneDX CLI supports signing and verification [5] |
| Confidentiality | Buyer to protect supplier CBOMs with encryption and access control, consistent with CERT-In 8.4.1.12 [1] |
Sample clause language
Adapt with your legal and procurement teams.
- "The Supplier shall deliver, with each release of the Product, a Cryptographic Bill of Materials in CycloneDX format version 1.6 or later, covering all cryptographic algorithms, keys, protocols and certificates used by the Product, and containing at least the minimum elements set out in CERT-In's Technical Guidelines, Version 2.0, Table 9."
- "The Supplier shall deliver an updated CBOM within [30] days of any change to the cryptographic components of the Product."
- "The Supplier shall provide a VEX statement within [n] days of the public disclosure of a vulnerability affecting a cryptographic component of the Product."
- "The Supplier shall provide, and update [annually], a roadmap for support of NIST-standardised post-quantum algorithms in the Product."
Evaluating responses
- Validate sample CBOMs during evaluation, not after contract award; see CBOM validation.
- Score completeness against the required fields, not merely whether a file was supplied.
- Ask how the CBOM was produced, code analysis, binary analysis, manual, and what it does not cover.
- Treat "no cryptography" claims for networked products with scepticism.
After award
Ingest supplier CBOMs into your own inventory. CERT-In asks consumer organisations to create an internal CBOM aligned with supplier data (8.4.1.8) [1], so link each supplier asset to where the product is deployed and who owns it. Track PQC roadmap commitments at each renewal. See CBOM management and CBOM for government.
How IntelliXBOM helps
IntelliXBOM ingests supplier CBOMs in CycloneDX and SPDX, validates them against required-field policies such as CERT-In's, and keeps version history across supplier releases. It records VEX decisions and correlates supplier cryptography with vulnerabilities and the business services that depend on each product.
This article summarises public guidance and is not legal advice; sample clauses should be reviewed by your legal advisers.
Frequently asked questions
What should a supplier CBOM include?
All cryptographic algorithms, keys, protocols and certificates used by the product, with at least the CERT-In Table 9 elements, linked to the components that use them. It should also state which algorithms can be changed by configuration and be accompanied by a post-quantum roadmap for critical products.
Can buyers require suppliers to provide a CBOM?
Yes, through contract terms. CERT-In recommends that government, public sector and essential services organisations require CBOMs in related procurements and that suppliers provide complete CBOMs for delivered solutions.
How often should suppliers update their CBOM?
With each major release, whenever cryptographic components change, and on request. CERT-In's recommendation 8.5.4 also proposes quarterly PQC migration progress reports from service providers.
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
- 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
- G7 Cyber Expert Group Statement on Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector (January 2026)US Department of the Treasury (G7 Cyber Expert Group)home.treasury.gov/system/files/136/G7-CEG-Quantum-Roadmap.pdf
- CycloneDX v1.6 JSON Reference (bom-1.6 schema)OWASP CycloneDXcyclonedx.org/docs/1.6/json/
- CycloneDX CLIOWASP CycloneDX (GitHub)github.com/CycloneDX/cyclonedx-cli
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.