CERT-In's QBOM Is a Hardware Checklist, Not a Quantum Readiness Strategy
CERT-In's July 2025 guidelines introduced QBOM alongside SBOM, CBOM, AIBOM and HBOM. It is a useful inventory template for quantum hardware, but it is not a PQC migration plan. Here is what QBOM actually asks for, why the rest of the world standardised on CBOM instead, and the seven-step process that answers the question CISOs are really asking.
There's a new acronym doing the rounds in India's compliance conversations: Quantum Bill of Materials, or QBOM.
It turns up in CERT-In's July 2025 Technical Guidelines, listed alongside SBOM, CBOM, AIBOM and HBOM. And the question we keep getting from CISOs is a practical one: do we need a QBOM to be audit-ready for post-quantum cryptography?
Short answer, not really.
A QBOM will help you identify relevant hardware and components – it won't give you a PQC migration plan, and the two are easy to confuse when they share a letter.
QBOM tells you what you have. CBOM tells you what cryptography you use. PQC readiness tells you what needs to change.
The acronym nobody else uses
QBOM has the ring of an established global standard. It isn't one.
There is no CycloneDX QBOM schema, no SPDX QBOM field, and no NIST or ETSI specification that defines QBOM as its own artifact. As far as we can tell, CERT-In is the first body anywhere to carve QBOM out as a category separate from CBOM, and so far it is still the only one.
Worth remembering too: the CERT-In guidelines are voluntary. They are not a globally mandated standard, and nothing about QBOM's presence in them changes that.
Why does this matter? Because an acronym in a government document tends to get read as an international requirement, and procurement teams start asking vendors for it. QBOM is a CERT-In concept built for a specific purpose. Understanding that purpose will serve you far better than assuming it's simply India's version of something the rest of the world already does.
What CERT-In's QBOM actually asks for
Read the minimum elements CERT-In specifies for a QBOM:
- Model Name
- Version
- Vendor & Origin Information
- License Information
- Communication Protocol
- Hardware
- Software Dependencies
- Environmental Impact
Then flip forward a few chapters to CERT-In's own HBOM, the Hardware Bill of Materials:
- Product Name
- Product Version
- Manufacturer Name
- Manufacturer Location
- Model Number
- Serial Number
- Technical Specification
Structurally, they're almost the same document.
Side-by-side list of CERT-In's QBOM minimum elements (model name, version, vendor and origin, license, communication protocol, hardware, software dependencies, environmental impact) against its HBOM minimum elements (product name, product version, manufacturer name, manufacturer location, model number, serial number, technical specification), showing the two are structurally near-identical. CERT-In's QBOM is an HBOM scoped to quantum devices: an asset inventory, not a cryptographic exposure model.
CERT-In's QBOM reads like an HBOM that happens to be pointed at quantum devices. It's a structured inventory of the quantum computer itself: the processor, the simulators, the SDKs, the firmware, the vendor who sold it to you. The intended reader is an organisation that owns or operates real quantum hardware and wants to track it the way it already tracks a server rack or a networking appliance.
Nothing wrong with that – it's simply not what most people are worried about when they put "quantum" and "cybersecurity" in the same sentence.
What everyone else means by "quantum risk"
NIST, CISA, CycloneDX and the NSA's CNSA 2.0 program have all converged on a different artifact entirely. That artifact is the CBOM, a Cryptographic Bill of Materials.
A CBOM doesn't inventory quantum computers at all. It inventories the classical cryptography you're already running: RSA keys, TLS certificates, ECC signatures. Then it puts a quantum-risk lens over the top, flagging which of those assets stop being trustworthy once a cryptographically relevant quantum computer (CRQC) exists, and how long the data sitting behind them actually needs to stay confidential.
Side-by-side comparison showing CBOM inventorying classical cryptographic assets such as RSA keys, TLS certificates and ECC signatures, versus QBOM inventorying quantum hardware such as processors, simulators, SDKs and firmware. CBOM inventories the cryptography you are exposed through. QBOM inventories the quantum hardware you operate. Different artifacts, different audiences.
You do occasionally see "QBOM" used outside CERT-In's guidelines, and when you do, it almost always means this: a CBOM re-read for quantum exposure, not a new file format. The work that matters is the analysis. Mapping cryptographic assets to the systems they sit in, scoring them against Shor's and Grover's algorithms, deciding what moves first. Generating a novel document type contributes nothing to any of it.
The regulatory pressure points the same way. NIST's draft IR 8547 proposes deprecating quantum-vulnerable algorithms by 2030 and retiring them by 2035. National agencies in the US, UK, Germany and France are all steering organisations toward hybrid classical/post-quantum deployments as the interim state.
None of that guidance asks anyone to catalogue a quantum computer. It asks them to catalogue their crypto.
So when does CERT-In's QBOM matter?
It does have a use – just a narrower one than the name suggests.
If you're genuinely procuring quantum hardware, wiring a quantum SDK into a research pipeline, or running a simulator in production, CERT-In's element list is a sensible checklist. Know your vendor. Know your firmware version. Know your dependencies and your environmental footprint. That's ordinary asset hygiene, and you'd want the same discipline around any specialised piece of lab or data-centre equipment.
What the checklist can't do is answer the question that actually keeps security teams up:
Which of our systems will be exposed when quantum computers get powerful enough to break today's encryption, and how much time do we have?
Nobody can date that precisely. Expert surveys, including the Global Risk Institute assessment most people cite, put meaningful probability on a CRQC arriving somewhere in the 2030–2035 window, with genuine uncertainty either side.
The arrival date isn't the whole risk though. Harvest now, decrypt later is the part that bites first: adversaries capturing encrypted traffic today on the bet that they'll be able to read it once the hardware catches up. That's happening now, to organisations that have never been anywhere near a quantum device.
So how do you answer the question?
If a QBOM won't tell you which systems are exposed, something has to. In practice it's a seven-step process built on your CBOM rather than on any new artifact.
1. Build a cryptographic inventory
Find every place your systems encrypt or sign something. TLS certificates, VPNs, databases, APIs, embedded firmware, third-party libraries, products you bought rather than built. For each one, record the algorithm, the key size and where it lives – most of this can be automated with tooling that scans code, network traffic and certificate stores, which is just as well, because doing it by hand at any real scale is hopeless.
2. Classify data by how long it must stay secret
Ask one question of each data set: if someone stole this today and decrypted it in ten years, would it still hurt? Medical records and state secrets need decades of protection. A one-time password reset link needs minutes.
This number – the confidentiality lifespan – is the single most important figure in the whole exercise, and it's the one most organisations have never written down.
3. Flag the quantum-vulnerable algorithms
RSA, ECC (ECDSA and ECDH) and Diffie-Hellman all fall to a sufficiently powerful quantum computer running Shor's algorithm. AES-256 and SHA-384/512 are weakened rather than broken, and longer keys already handle that.
This step tends to be a relief. It usually takes most of the inventory off the urgent list.
4. Map each vulnerable asset to what it protects
A cryptographic asset on its own tells you very little. Trace it to the system and the business process it secures, and flag the external dependencies you don't directly control, because those are the ones with the longest lead times.
5. Apply Mosca's theorem to find the real deadline
Mosca's theorem takes three estimates and turns them into one answer:
- X is how many years your data must stay confidential, from step 2
- Y is how many years your migration will realistically take
- Z is how many years until a CRQC exists
If X + Y > Z, you're already late.
Try it with plausible numbers. Records that need to stay confidential for ten years, so X = 10. A migration across a large estate that takes five years if it goes well, so Y = 5. A CRQC estimate around 2033, roughly seven years out, so Z = 7. That gives 15 against 7, which means the data you encrypt and ship this quarter is already inside the exposure window.
Bar chart of Mosca's theorem: X, a 10-year confidentiality lifespan, and Y, a 5-year migration, sum to a 15-year exposure window that overshoots Z, a cryptographically relevant quantum computer estimated roughly 7 years out around 2033. Mosca's inequality turns three estimates into one defensible deadline: if X + Y > Z, the data you are encrypting today is already exposed.
The theorem isn't precise, and it can't be, since Z is unknowable. Its value is that it converts a vague "sometime in the 2030s" into a per-dataset deadline you can defend in front of a board, and it makes obvious why the long-lived data has to move first.
6. Prioritise, then migrate the worst offenders
Work down from the highest-risk systems using NIST's finalised replacements: ML-KEM, ML-DSA and SLH-DSA, standardised as FIPS 203, 204 and 205. In most environments these run in hybrid mode alongside the classical algorithms for the duration of the transition.
7. Re-run all of this on a schedule
New systems get added. Vendors quietly change their crypto. Estimates of quantum progress move, usually forward. A crypto inventory produced once is a snapshot that starts going stale the day it's signed off.
Where IntelliXBOM fits
This is the gap we built IntelliXBOM to close. The discipline that keeps your SBOMs continuously generated and validated against CERT-In's mandatory fields extends into the cryptographic layer: cataloguing the cryptographic libraries, algorithms, certificates and protocol configurations across your estate, and keeping that picture current as the estate changes underneath you.
In practice, that turns steps 1, 4 and 7 from a recurring manual audit into something that simply stays true. Your teams get to spend their time on the judgement calls that actually need people: confidentiality lifespans, migration sequencing, and pressing vendors who'd rather not be pressed.
Ready to see where your quantum-vulnerable cryptography actually lives?
See a live CBOM generated from your own environment, mapped against CERT-In's guidelines and the NIST/CNSA 2.0 timeline. No slideware, no spreadsheets.
What to do on Monday
Don't wait on a QBOM to start your PQC work, and don't mistake building one for being audit-ready.
Build the CBOM you can build today. The CycloneDX specification is real, mature and already wired into several vulnerability-management pipelines. Layer quantum-risk and data-lifespan scoring on top of it, and you'll have an answer the next time someone asks how exposed you are.
Keep CERT-In's QBOM checklist in your back pocket for the day your organisation starts operating quantum hardware of its own. Until then it's a tidy inventory template for a category of asset almost nobody owns yet, and not the thing that prepares you for the cryptography the rest of us have to worry about.