What is a QBOM? The quantum bill of materials, explained

2 min read · Explainer
TL;DR

A QBOM is a quantum-readiness view computed over your cryptographic inventory: every algorithm, key, and protocol classified as quantum-vulnerable or quantum-safe against the finalized NIST post-quantum standards, aggregated into a posture you can track. It answers the question regulators and boards have started asking - how much of our cryptography breaks when quantum computers arrive - with a number instead of a shrug.

A QBOM, a quantum bill of materials, answers a question that has moved from research papers to boardrooms: which of our cryptography breaks when quantum computers arrive? It takes the cryptographic inventory of your software and classifies every asset - each algorithm use, key, certificate, and protocol configuration - as quantum-vulnerable or quantum-safe against the finalized NIST post-quantum standards, then rolls the verdicts up into a posture you can measure and track.

A verdict, computed over an inventory

The QBOM is best understood as a layer, not a separate scan. Underneath it sits the CBOM - the cryptography bill of materials that records which cryptographic assets exist, where, with evidence. The QBOM classifies each entry:

  • Quantum-vulnerable: today’s public-key algorithms - RSA, elliptic-curve signatures and key exchange, finite-field Diffie-Hellman. These are what a cryptographically relevant quantum computer breaks.
  • Quantum-safe: the NIST post-quantum standards (ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures) and symmetric cryptography at adequate key sizes, such as AES-256.
  • Weak regardless: legacy algorithms that should be retired without waiting for the quantum threat.

The layering has a sharp consequence: a QBOM inherits the honesty of its CBOM. If the inventory missed the RSA use inside a vendor binary, the readiness percentage is fiction. That is why a defensible QBOM is generated from artifacts - source, configuration, certificates, compiled binaries - with unresolvable assets declared as known-unknowns rather than silently omitted.

What it is for

The QBOM converts the quantum question into management-grade material:

  • A trackable number. The fraction of cryptographic assets that are quantum-safe, per service, per quarter - the burn-down chart that makes a migration program schedulable instead of aspirational.
  • A prioritized worklist. Vulnerable assets ranked by the lifetime of the data they protect, since harvest-now-decrypt-later makes long-lived secrets the urgent front.
  • Regulator-ready evidence. Government timelines such as CNSA 2.0 phase in quantum-resistance requirements, sector frameworks are inheriting them, and Indian guidance from CERT-In describes BOM dimensions beyond software explicitly. When the question arrives, the QBOM is the answer format.

In practice

BOMNexa generates the CBOM from real artifacts, computes the quantum verdict per asset against current NIST standards, and maintains the readiness posture as inventories regenerate with every build - entirely offline, with the standards data arriving through signed bundles. The result is that “are we quantum-ready” stops being a strategy-offsite question and becomes a dashboard number with a trend line.

Frequently asked questions

How does a QBOM relate to a CBOM?

The CBOM is the inventory: which cryptographic assets exist and where. The QBOM is a verdict layered over it: each of those assets classified against post-quantum standards. No separate scan is needed - if the CBOM is complete and evidence-based, the QBOM is computable from it, which is also why a QBOM is only as trustworthy as the inventory underneath.

What counts as quantum-vulnerable?

The public-key cryptography in universal use today: RSA, elliptic-curve schemes, and finite-field Diffie-Hellman, all of which fall to a sufficiently capable quantum computer running Shor's algorithm. Symmetric encryption like AES-256 and modern hash functions remain effectively safe, which usefully bounds the migration to key exchange, signatures, and the certificate estate.

Why produce a QBOM before quantum computers actually exist?

Two reasons. Harvest-now-decrypt-later means encrypted data stolen today becomes readable retroactively, so long-lived secrets are already exposed. And government migration timelines are already published, with regulated sectors expected to inherit them - and the first step of every one of those timelines is knowing your cryptographic inventory.

See QBOM in practice, on your own code
A 30-minute live session inside a network like yours.
Request a demo