Cryptography is the part of a software estate that is now getting increased attention from regulators in India and across the globe. This is because algorithms, keys and certificates sit buried across applications, libraries and infrastructure, often without a single owner who can name them all.
CERT-In, the nodal agency of India overseeing cybersecurity in the country, addressed this directly in its Technical Guidelines on SBOM, QBOM and CBOM, AIBOM and HBOM, Version 2.0.
CERT-In is not alone in this. The US and the UK have published their own expectations for cryptographic inventories in 2026, and each takes a different route to the same destination. This blog sets out what CERT-In CBOM guidelines say plus how that compares with the US and UK approach.
What CERT-In’s guidelines say about CBOM
CERT-In released Version 2.0 of its Technical Guidelines on 9 July 2025. Section 8 covers Quantum Bill of Materials and Cryptographic Bill of Materials together, defining what a CBOM is, why it matters and what it should contain.
A CBOM is described as an inventory of cryptographic assets, capturing algorithms, keys, certificates and the metadata around their usage and expiry. It sits alongside SBOM, AIBOM and HBOM as one of five bill-of-materials categories the guidelines introduce.
What the minimum elements cover
Section 8.3 sets out the minimum elements of a CBOM, listed in Table 8 and Table 9 of the guidelines. These cover cryptographic algorithms in use, key lengths, certificate and protocol details, and the specific systems each asset supports.
The intent is to make cryptography as traceable as software components already are under SBOM. An organisation should be able to answer where a given algorithm or certificate is used, not just confirm that it exists somewhere in the estate.
What organisations are expected to do with a CBOM
Section 8.4 moves from inventory to action. Organisations are expected to assess crypto-agility, meaning how easily a system can switch from one cryptographic algorithm to another without a major rebuild.
This includes identifying quantum-vulnerable algorithms such as RSA and ECC, and mapping which systems depend on them. A CBOM without this step is a static list. With it, the CBOM becomes a working input to a migration plan.
Section 8.5 covers quantum-readiness and migration strategy directly. CERT-In expects organisations to sequence their transition to quantum-resistant algorithms, using the CBOM as the baseline for prioritisation.
Re-scanning after changes is part of this expectation, since certificates rotate and libraries update. A CBOM built once and left untouched loses its value quickly.
Is CERT-In’s CBOM guidance mandatory?
The guidelines are advisory, not statutory. CERT-In recommends them for public sector, government, essential services and software export organisations, without imposing a legal penalty for non-adoption.
In practice, the voluntary framing matters less than it appears to. SEBI’s Cyber Security and Cyber Resilience Framework requires regulated entities to manage software supply chain risk and maintain detailed inventories, which creates pressure toward cryptographic visibility that SBOM alone cannot satisfy.
The RBI has gone further with a dedicated Q-SAFE committee, tasked in part with building a CBOM to help financial institutions map their cryptographic tools and assess crypto-agility.
Neither SEBI nor RBI has published its own field-level CBOM standard. Both point back to CERT-In’s Technical Guidelines as the reference. A guideline that carries no legal force on its own becomes the working standard once sectoral regulators cite it.
How the US approach compares
On 22 June 2026, the United States issued Executive Order 14409, Securing the Nation Against Advanced Cryptographic Attacks. Section 5 of the order directs CISA, in coordination with NIST, to publish minimum elements for a cryptographic bill of materials within 270 days of the order, placing the deadline around March 2027.
The US approach is notably more prescriptive on format. The order specifies that CBOM elements must support automated assessment of cryptographic assets, ruling out a manually assembled inventory as sufficient. CERT-In’s guidelines describe minimum elements but do not mandate automation as a condition of compliance.
Fixed migration dates for federal systems and contractors
The order sets hard dates: federal agencies must migrate high-value assets and high-impact systems to post-quantum cryptography for key establishment by 31 December 2030, and for digital signatures by 31 December 2031. A separate procurement rule extends compliance expectations to covered federal contractors by the same 2030 deadline.
This is the clearest structural difference from CERT-In. India’s guidelines describe what a CBOM should contain and how it should be used, but set no fixed national migration date. The US order pairs its inventory requirement directly to calendar deadlines with procurement consequences attached.
How the UK approach compares
The UK’s National Cyber Security Centre published Timelines for Migration to Post-Quantum Cryptography in March 2025, setting three phases: discovery and planning by 2028, high-priority upgrades by 2031, and full migration by 2035.
The cryptographic inventory step sits inside Phase 1. NCSC’s guidance is explicit that this stage does not need to be a formal asset register at first. It asks organisations to understand the nature and scale of their cryptographic dependencies well enough to build a migration plan, then deepen that inventory for systems they manage directly.
Crypto-agility as the same core principle, different sequencing
NCSC’s guidance shares CERT-In’s emphasis on crypto-agility, recommending that organisations choose solutions capable of supporting multiple algorithm suites during the transition period. The difference lies in sequencing. NCSC ties its inventory milestone to a published national timeline with three fixed years. CERT-In’s Section 8 describes the same activity without attaching it to dates.
What this comparison means for Indian organisations
CERT-In’s Section 8 gives Indian organisations a detailed answer to what a CBOM should contain, arguably more detailed on minimum elements than the UK’s current guidance. What it does not yet provide is a fixed national timeline of the kind the US and UK have both published.
For organisations regulated by SEBI or RBI, or those exporting software to US or UK markets, this gap is worth planning around rather than waiting on. Building a CBOM now, ahead of a fixed CERT-In deadline, positions an organisation to meet whatever timeline follows and to respond to customer or regulator requests referencing the US or UK frameworks in the meantime.
Conclusion
CERT-In sets out a clear, detailed picture of what a CBOM should contain and how it should feed into crypto-agility and post-quantum planning. It stops short of the fixed calendar dates that the US and UK have both attached to their own frameworks, but SEBI and RBI’s growing reliance on it suggests that gap will not last.
Building a CBOM now, rather than waiting for a mandate, gives you a head start regardless of which timeline eventually applies. Our SBOM and CBOM management tools NXRadar generates and maintains CBOMs automatically across applications, mapping cryptographic assets to CERT-In’s minimum elements and flagging quantum-vulnerable algorithms before migration pressure forces a rushed decision. Talk to our team to see how CBOM tool NXRadar fits into your compliance roadmap.
CERT-In CBOM guidelines FAQ
Is CERT-In’s CBOM guidance mandatory?
No. The Technical Guidelines v2.0 are advisory. Adoption is recommended for public sector, government, essential services and software export organisations, though SEBI and RBI increasingly treat the framework as their field-level reference point.
How is CERT-In’s CBOM different from the US CBOM requirement?
The US Executive Order 14409 requires CBOM elements that support automated assessment of cryptographic assets and ties the inventory to fixed 2030 and 2031 migration deadlines. CERT-In describes minimum elements and expected use without mandating automation or setting a national migration date.
What is the UK NCSC’s timeline for cryptographic inventories?
NCSC places the cryptographic inventory step inside Phase 1 of its three-phase migration timeline, targeting 2028 for initial discovery and planning, 2031 for high-priority upgrades, and 2035 for full migration.
