What is a QBOM? The Quantum Bill of Materials explained

A Quantum Bill of Materials records the quantum-related and quantum-safe components in a system. In practice it also becomes the working view of how exposed an organisation's cryptography is to future quantum attack, and how far its migration has progressed.

A definition in two parts

The term Quantum Bill of Materials (QBOM) is used in two related ways, and it helps to keep them apart.

The CERT-In definition. India's CERT-In introduced the QBOM in its Technical Guidelines on SBOM, QBOM & CBOM, AIBOM and HBOM, Version 2.0, dated 9 July 2025. Section 8.1 says a QBOM "focuses on components related to quantum computing and quantum-safe cryptography" and includes quantum algorithms, security frameworks and related technologies ^[1]. The same section positions QBOMs as a way for organisations to maintain integrity, compliance and resilience as they adopt post-quantum cryptographic (PQC) solutions ^[1]. In this sense a QBOM is a component inventory, much like an SBOM, but for quantum devices, quantum-safe libraries and the hardware, protocols and dependencies around them.

The migration-practice view. Organisations planning a move to post-quantum cryptography also need a quantum-exposure view of their existing cryptographic inventory. The joint CISA, NSA and NIST factsheet on quantum readiness asks organisations to build an inventory of quantum-vulnerable cryptography, correlate it with asset inventories and document how long sensitive data sets need protection ^[2]. The U.S. OMB memorandum M-23-02 asks federal agencies for similar per-system detail, including the algorithm, key length and how long the data must be protected ^[3]. Many teams call this exposure-and-readiness view their QBOM too.

Both views are legitimate. CERT-In's definition tells you which components and fields to document; the migration view tells you what to do with that information. A mature QBOM programme covers both.

Why quantum computing changes cryptographic risk

CERT-In's guidelines state that public-key systems using RSA, ECC, Diffie-Hellman and DSA are vulnerable to Shor's algorithm, and recommend transitioning to quantum-resistant schemes ^[1]. Symmetric cryptography is affected far less: NIST's draft transition report says it does not expect to need to transition away from its existing symmetric standards such as AES ^[4], and the UK NCSC says symmetric algorithms with at least 128-bit keys can continue to be used ^[5].

No one can say with confidence when a cryptographically relevant quantum computer will exist, and this article makes no such prediction. The planning problem is different: data captured today can be stored and decrypted later, a risk the CISA, NSA and NIST factsheet calls "harvest now, decrypt later" ^[2]. Migrations also take years. See Harvest now, decrypt later explained.

What a QBOM contains: CERT-In's minimum elements

Table 8 of the CERT-In guidelines lists the minimum elements of a QBOM ^[1]:

The Cryptographic Asset element links the QBOM directly to the CBOM. For a detailed walk-through of each field and CERT-In's related recommendations, see CERT-In QBOM requirements.

The quantum-exposure view

For migration planning, organisations typically extend each cryptographic asset record with attributes like these. They are drawn from government migration guidance rather than from CERT-In's table:

Scoring these attributes is covered in Quantum risk assessment.

How the QBOM relates to other BOMs

• SBOM lists software components. It tells you which libraries you ship, including cryptographic libraries.
• CBOM lists cryptographic assets (algorithms, keys, protocols and certificates) and where they are used. See What is a CBOM?
• QBOM documents quantum-related and quantum-safe components and, in practice, the quantum exposure and readiness of the cryptographic inventory.
• HBOM lists hardware and firmware, which matters because roots of trust and signing keys often live there. See What is an HBOM?

CERT-In itself describes the QBOM and CBOM as together forming a unified foundation for securing cryptographic systems ^[1]. For the detailed comparison, read QBOM vs CBOM.

Formats

CERT-In recommends that BOMs be generated in recognised formats such as SPDX or CycloneDX ^[1]. CycloneDX 1.6 added first-class support for cryptographic assets ^[8]; its schema models four asset types (algorithm, certificate, protocol and related cryptographic material such as keys) and records properties such as primitive, parameter set, classical security level and NIST quantum security level ^[6]. OWASP describes post-quantum readiness as one of the main CBOM use cases ^[9].

The standards and timelines a QBOM supports

• NIST standards. FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) were published on 13 August 2024 ^[10]. See NIST PQC standards.
• NIST IR 8547. The initial public draft proposes deprecating quantum-vulnerable algorithms at the 112-bit security strength after 2030 and disallowing quantum-vulnerable algorithms after 2035 ^[4]. See NIST IR 8547 timeline.
• CNSA 2.0. NSA intends all U.S. national security systems to be quantum-resistant by 2035 ^[11]. See CNSA 2.0 timeline.
• EU. The coordinated roadmap asks Member States to start transitioning by the end of 2026 and to protect high-risk use cases no later than the end of 2030 ^[12].
• India. A DST task force report published in February 2026 sets targets for critical information infrastructure by 2029 and enterprise-wide PQC adoption by 2033 ^[13].

A consolidated view is in QBOM and post-quantum compliance.

Who needs a QBOM

CERT-In's recommendations in section 8.4 are addressed to government, public sector and essential services organisations, which should require a CBOM for cryptographic assets; suppliers of software, systems or devices involving cryptographic or quantum technologies are expected to provide a complete CBOM and/or QBOM, and consumer organisations are expected to maintain an internal CBOM/QBOM aligned with the supplier's data ^[1]. Beyond India, any organisation that holds data needing long-term confidentiality, operates long-lived devices or sells into markets with post-quantum procurement rules has a reason to build one. Sector guidance is in banks, government and Indian enterprises.

Common misconceptions

• "A QBOM makes us quantum-safe." It documents components and readiness. Migration is separate engineering work; see Preparing for post-quantum cryptography.
• "Quantum readiness means quantum key distribution." NSA states it does not generally consider QKD a practical security solution for protecting national security systems ^[11]; most programmes focus on PQC algorithms.
• "It is a one-off exercise." CERT-In expects CBOM/QBOM data to be kept up to date as new components, algorithms or quantum technologies are introduced ^[1]. See QBOM management.

How IntelliXBOM helps

IntelliXBOM generates and ingests CBOM and QBOM data in CycloneDX and SPDX, and validates it against required-field policies such as CERT-In's Table 8 elements. It keeps version history and diffs, so changes in cryptographic assets between releases are visible, and correlates those assets with vulnerabilities, end-of-life data and the business services they support. Inventory is mapped to framework controls with timestamped evidence, on-premise, in private cloud or air-gapped.