QBOM vs CBOM: What's the Actual Difference?
QBOM isn't a rival to CBOM, it's a CBOM with a quantum-risk layer on top. The mechanics, plus what SEBI, RBI, NIST, and EO 14412 actually require.
- A CBOM (Cryptographic Bill of Materials) is the base inventory: every algorithm, key, certificate, protocol, and crypto library in your stack, recorded in the CycloneDX 1.6 (ECMA-424) format.
- A QBOM (Quantum Bill of Materials) is not a separate inventory. It's that same CBOM enriched with quantum-vulnerability scoring, break-year estimates, and data-lifespan classification.
- The tell is a single CycloneDX field: nistQuantumSecurityLevel. A CBOM records it. A QBOM is built by reading it and acting on what's at 0.
- Executive Order 14412 (signed June 22, 2026) is the first US order to name CBOM directly, with CISA and NIST due to publish minimum CBOM elements by March 19, 2027.
- CERT-In's July 2025 guidelines name QBOM as a category, but define it around quantum computing components, not quantum-risk-graded cryptography. Most vendors use the term loosely to mean the latter.
- India is the only place with QBOM in an official document, but CERT-In's guidelines are voluntary. The real deadline pressure comes from SEBI, which made SBOM mandatory for critical applications by August 31, 2025.
- No US regulator has a binding CBOM mandate for financial institutions yet. NIST's SP 1800-38 calls a CBOM an urgent need, and the G7 roadmap co-chaired by US Treasury targets 2030-2032, but both are guidance, not rules an examiner can cite.
Ask three vendors what a QBOM is and you'll get three different answers. At least one of them will just be describing a CBOM with extra steps. That's not vendor sloppiness. The term is young. It gets used two different ways at once. It's worth untangling, because QBOM and CBOM aren't rival formats. One is built directly on top of the other.
A CBOM, Cryptographic Bill of Materials, is a structured inventory of every cryptographic asset in your systems. Algorithms, key sizes, certificates, protocols, and the libraries implementing them. A QBOM, Quantum Bill of Materials, takes that same inventory and grades each entry for one question: does this break once a real quantum computer exists, and if so, how soon does that matter. You don't pick one instead of the other. You build a CBOM. If quantum risk is what you're scoping for, that CBOM becomes your QBOM.
Side by side
| CBOM | QBOM | |
|---|---|---|
| Origin | OWASP CycloneDX, native support since v1.6 (2024), standardized as ECMA-424 | No dedicated schema. CERT-In (India) named it as a category in its July 9, 2025 Technical Guidelines v2.0 |
| What it inventories | Algorithms, key sizes, certificates, protocols, crypto libraries, deployment locations | The same asset list, with quantum-vulnerability score, NIST security category, and data-lifespan tag added |
| Who needs it | Nearly every org doing PQC migration, vendor risk review, or crypto compliance | Orgs prioritizing which crypto to migrate first, or (in the CERT-In sense) orgs deploying actual quantum hardware or algorithms |
| Regulatory driver | EO 14412 (US), EU Cyber Resilience Act, DORA | CERT-In BOM guidelines (India), referenced loosely elsewhere as the deliverable for PQC prioritization |
| Maturity | Formal, machine-readable, tool-generated (CBOMkit and others) | Emerging term, not a settled standard. In practice, built on top of a CycloneDX CBOM |
If a vendor tells a CISO "you need a QBOM," they almost always mean "you need to know where your quantum-vulnerable cryptography lives." That's a CBOM question. The QBOM label just adds the quantum framing on top.
QBOM and CERT-In compliance in India
India is the one place QBOM has an official name. CERT-In's Technical Guidelines on SBOM, QBOM & CBOM, AIBOM, HBOM, Version 2.0, released July 9, 2025, lists QBOM as one of five BOM categories organizations should be able to produce. The guidelines say plainly that they "have not been made mandatory." They're offered as best practice, not a rule with an audit attached. So the QBOM name exists in an official Indian document. A binding QBOM requirement does not, at least not yet.
For BFSI specifically, the actual audit pressure comes from a sector regulator, not from CERT-In directly. SEBI's Cybersecurity and Cyber Resilience Framework already made SBOMs mandatory for critical and core applications at regulated entities, covering banks, NBFCs, mutual funds, and depositories. Most REs had to comply by August 31, 2025. Qualified and mid-size REs have a further deadline of June 30, 2026, with half-yearly audit and action-taken reports due on the same cycle. Miss the audit deadline and NSE or BSE can levy a daily penalty of Rs 1,500 a day for smaller REs and Rs 5,000 a day for qualified REs, on top of further regulatory action. SEBI hasn't named CBOM or QBOM directly, but an SBOM rule that already touches encryption is close enough that BFSI compliance teams shouldn't wait for the label to catch up.
What RBI's 2026 directions actually require
RBI moved second but harder, and this is the one banks can't treat as optional. Its Commercial Banks Cybersecurity, Technology, Risk, Resilience and Assurance Framework Directions, 2026, issued July 31, 2026, set cryptography as one of the baseline requirements in Chapter V: key lengths, algorithms, cipher suites, and protocols used across transmission, processing, and authentication must all be strong. The same directions require banks to maintain an up-to-date inventory of information assets, business applications, supporting IT infrastructure, key personnel, and facilities. Put those two requirements together and you have a CBOM in substance, even before anyone attaches the label. The directions apply immediately to commercial banks, including the State Bank of India, but exclude small finance banks, payments banks, and local area banks.
RBI has since named CBOM directly, too. On May 25, 2026, it constituted the Q-SAFE committee, the Expert Committee for a Quantum Secure and Adaptive Financial Ecosystem, and its terms of reference task it to "evaluate the financial sector's cryptographic inventory through a Cryptography Bill of Materials (CBOM)" and assess crypto agility across the sector. That's an official RBI document using the term CBOM by name, ahead of the July directions. It's still a study committee, not a rule. Its report is due six months after its first meeting and will recommend a roadmap, not impose one directly. Treat it as a strong signal of where a binding requirement is heading, not as one that already exists.
SEBI hasn't named CBOM or QBOM in a binding rule. RBI now has, through Q-SAFE, though only as a study committee's brief so far, not an audit requirement. If you're a CISO or compliance lead at a bank, NBFC, exchange, or depository, don't wait for either regulator to turn that into a circular before you build one. The SBOM and cryptography inventory requirements already in force cover the same ground. Building the CBOM now means the QBOM layer, and whatever Q-SAFE recommends, is a smaller lift later.
The field that turns a CBOM into a QBOM
This is easier to see in the actual data than in prose. CycloneDX 1.6 defines a cryptographic asset with an assetType field. For algorithms, it adds an algorithmProperties block. That block already carries the fields a QBOM needs. Nothing new has to be invented.
Look at classicalSecurityLevel and nistQuantumSecurityLevel side by side. RSA-2048 carries 112 bits of classical security. That's fine against today's computers. Its nistQuantumSecurityLevel sits at 0. That means it meets none of NIST's post-quantum security categories. Shor's algorithm breaks RSA outright, not just weakens it, once a large enough quantum computer exists. A CBOM records that 0. A QBOM is what you get when you sort your entire inventory by that field and use it to sequence a migration.
“The QBOM layer doesn't add a new record type to CycloneDX. It reads a field that's already there and ranks migration priority by it.”
Why this is showing up on compliance calendars now
Three deadlines, two continents, one underlying requirement: know your cryptography before you can prove you're migrating it.
- CERT-In BOM Guidelines v2.0 (July 9, 2025): India's CERT-In lists QBOM alongside SBOM, CBOM, AIBOM, and HBOM as a BOM category organizations should be able to produce. It doesn't define QBOM in technical depth beyond naming it.
- Executive Order 14412 (June 22, 2026): The first US executive order to name a cryptographic bill of materials directly. It directs CISA, coordinating with NIST, to publish guidance on the minimum elements of a CBOM within 270 days.
- CISA + NIST minimum CBOM elements (due March 19, 2027): The 270-day deadline from EO 14412. This becomes the reference definition US agencies and contractors build against.
- EU Cyber Resilience Act (full application December 11, 2027): CRA-covered products need documented, risk-based security processes, including how cryptographic risk is managed, to keep CE marking.
Every one of those deadlines is a CBOM requirement first. None of them mandate a standalone QBOM as CERT-In formally defines it. If you're building toward any of these dates, the CBOM is the artifact regulators actually ask for. Whether you also call it a QBOM depends on one thing: have you added the quantum-risk scoring on top, yes or no.
United States: what's actually binding for financial institutions
EO 14412 gets the headline, but it isn't the only federal signal. For a bank or asset manager, it isn't even the most direct one. NIST's own practice guide, SP 1800-38, comes from the National Cybersecurity Center of Excellence and more than two dozen industry partners, including AWS, IBM, and Microsoft. It states plainly that building a CBOM is now an urgent need. Its reasoning is simple. A current, detailed CBOM is what lets you find the vulnerable signature algorithms in your TLS certificates and the key agreement algorithms in your handshakes. You can't prioritize what you haven't found. NIST is not a regulator. It doesn't fine anyone. But when your examiner asks what standard you built your inventory against, SP 1800-38 is the answer that holds up.
CISA, NSA, and NIST jointly published quantum-readiness guidance in August 2023, well before EO 14412 existed. It recommended organizations build a cryptographic inventory and prioritize high-impact systems first. The NSA's own CNSA 2.0 suite sets hard 2030 to 2033 deadlines, but only for National Security Systems: defense, intelligence, and their direct vendors. It does not reach a commercial bank. What does reach the financial sector is softer and newer. In January 2026, the G7 Cyber Expert Group, co-chaired by the US Treasury and the Bank of England, published a post-quantum roadmap aimed at banks, regulators, payment networks, and fintechs. It targets migration of critical systems by 2030 to 2032. Like CERT-In's guidelines, it's explicitly a planning framework, not a mandate.
Bank regulators specifically have said more than a general "risk to monitor," and the timeline matters. The OCC was first, flagging quantum risk in its Fall 2022 Semiannual Risk Perspective. By its Fall 2024 edition, published December 16, 2024, the guidance had sharpened: banks were told to inventory where encryption is used across their operations and to work with third parties on PQC transition assessments. That's a CBOM in substance, described in OCC's own supervisory language, without the acronym attached. The Federal Reserve called quantum a significant emerging risk area in its July 2025 Cybersecurity and Financial System Resilience Report, the same report where it acknowledged NIST's finalized post-quantum algorithms from August 13, 2024. The FDIC went further in its 2024 Risk Review, published May 22, 2024, advising institutions to build a Quantum-Readiness Roadmap ahead of migration.
None of this amounts to a binding CBOM rule yet. It's supervisory guidance and risk commentary, not an enforceable requirement with an exam checklist attached. But four separate US regulators, OCC, the Fed, the FDIC, and NCUA, have each flagged quantum risk in an official report since 2022, and OCC has already told banks in writing to inventory their encryption. If you're waiting for a rule that says "CBOM" before you build one, the supervisory language is already most of the way there.
What quantum-vulnerable actually means here
- Asymmetric algorithms built on integer factoring or discrete logarithms break under Shor's algorithm: RSA at any key size, ECDSA, ECDH, Diffie-Hellman.
- Symmetric algorithms and hash functions are weakened, not broken: Grover's algorithm roughly halves their effective security level, which is why AES-256 stays fine but AES-128 gets a second look.
- NIST IR 8547 sets the US federal timeline: RSA, ECDH/ECDSA, and finite-field DH/DSA are deprecated after 2030 and disallowed after 2035.
- Replacements are already standardized: ML-KEM for key establishment, ML-DSA and SLH-DSA for signatures. NIST's guidance is to start deploying them now, not wait for the deprecation date.
The bottom line
Stop treating this as a naming decision. Build the CBOM first. It's the CycloneDX-standard, regulator-recognized artifact. EO 14412, the EU CRA, and DORA all point back to it. Once you have it, check whether nistQuantumSecurityLevel and a data-lifespan tag are populated for each asset. If they are, congratulations, you already have a QBOM. You just built it under its other name. The label on the document matters a lot less than whether the inventory behind it is actually complete and current.