From SBOM to QBOM: Why Bills of Materials Are Becoming the Operating System for Cyber Resilience

On June 22, 2026, President Trump signed Executive Order 14412, Securing the Nation Against Advanced Cryptographic Attacks. Section 5(d) directs CISA, with NIST, to publish minimum elements for a Cryptographic Bill of Materials (CBOM) within 270 days, roughly mid-March 2027, so cryptographic assets can be assessed automatically. Anyone who has run an SBOM program will recognize that phrase. “Minimum elements” is the same term NTIA used in 2021 to define what a Software Bill of Materials must contain. CISA continued the NTIA effort with the publication in 2024 of the Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM). Currently, CISA has draft version, 2025 Minimum Elements for a Software Bill of Materials (SBOM) released for public comment August 2025. It is clear to see that the federal government continues to see the value and the benefit to continue to establish and enhance minimum SBOM elements to drive normalcy and uniformity.

The Question Every SBOM-Mature Organization Is About to Ask

Organizations that spent years standing up SBOM programs, building process, training teams, integrating tooling, now face an immediate worry: does CBOM mean a new system, a new vendor, a new contract, all over again? CBOM is arriving alongside AIBOM, with early conversation about QBOM and HBOM too. That stacking is producing real BOM fatigue, the sense that transparency requirements are multiplying faster than any organization can absorb them. Fatigue is a planning risk, not just an inconvenience: it stalls programs and re-litigates budgets. The right response is not to assume new tooling is required for every new acronym, but to find out concretely what an existing SBOM provider can already do, a question this piece returns to below.

The BOM Family: What Each Type Does

SBOM (Software) is a structured inventory of software components: packages, libraries, versions, suppliers, licenses, dependencies, and known vulnerabilities. It became central to policy after Executive Order 14028 (2021), with NTIA's minimum elements and continuing CISA guidance defining what a usable SBOM contains.

HBOM (Hardware) inventories chips, boards, modules, sensors, processors, firmware-bearing components, suppliers, and lifecycle status. Hardware risk is increasingly inseparable from software risk, since a product may be exposed simply because its hardware cannot support required updates or cryptographic modernization.

CBOM (Cryptographic) inventories algorithms, protocols, certificates, key lengths, libraries, trust anchors, and signing mechanisms everywhere cryptography protects data and identity. Post-quantum migration starts with discovery: an organization cannot replace quantum-vulnerable cryptography until it knows where that cryptography lives. This is a harder discovery problem than software inventory, since cryptographic assets are often embedded or inherited several supply-chain layers down, a distinction that shapes how CBOM tooling is likely to develop. CycloneDX, one of the two SBOM formats long recognized by NTIA and CISA alongside SPDX, added native cryptographic-asset support in version 1.6 (April 2024), absorbing IBM Research's CBOM specification into the core schema, and has since become an Ecma International standard (ECMA-424). Building on CycloneDX is a strong, verifiable head start; it is not yet a guarantee of exactly what format the CBOM minimum elements guidance due under EO 14412 will require.

AIBOM (Artificial Intelligence) documents the models, datasets, training data, frameworks, pipelines, lineage, provenance, and governance metadata behind an AI system. NIST has described AIBOMs as enablers of AI transparency and trust, and the Institute for Security and Technology has argued AIBOMs need a shared minimum set of elements, much like what CISA and NIST are now producing for CBOM, before the field fragments into incompatible formats. Like CBOM, AIBOM data does not map cleanly onto a software-package schema, which is part of why it has developed as its own tooling track.

QBOM and the quantum layer is still an inconsistently defined term, referring either to an inventory of quantum technologies themselves or a quantum-risk view of cryptographic assets that overlaps with CBOM. For most enterprise PQC work today, CBOM remains the more precise and actionable term.

VEX explains whether a known vulnerability actually affects a specific product in context, turning a long vulnerability list into a prioritized one. SaaSBOM, DBOM, and FBOM extend the same idea to cloud dependencies, datasets, and firmware respectively; all are early-stage but reflect the same underlying trend.

Policy Is Moving Toward BOM-Based Evidence

SBOM policy accelerated after EO 14028 and NTIA's minimum elements work. FDA Section 524B has required an SBOM with premarket cyber device submissions since March 2023. The EU Cyber Resilience Act will require reporting of actively exploited vulnerabilities starting September 11, 2026. IEC 62443, UN R155/R156, O-RAN requirements, and PCI DSS 4.0 follow the same logic in their sectors, and AI regulation is heading the same direction under frameworks like the NIST AI RMF and the EU AI Act.

EO 14412 fits this pattern with unusual specificity: federal agencies must migrate high-impact systems and high-value assets to NIST-approved post-quantum cryptography for key establishment by December 31, 2030, and digital signatures by December 31, 2031. Each agency named a PQC migration lead within 30 days of the order, and OMB's June 24 follow-up memo requires migration plans by October 22, 2026. The companion order, EO 14413, Ushering in the Next Frontier of Quantum Innovation, expands U.S. quantum computing, sensing, and networking capability. Both build on NIST's FIPS 203, 204, and 205 standards (finalized August 2024) and the “harvest now, decrypt later” risk that adversaries can capture encrypted data today to decrypt once quantum computers make it possible.

Learning From the SBOM Rollout

SBOM adoption taught organizations that the standard was the easy part; operationalizing it, ownership, refresh cycles, validation, and integration into existing workflows, was the hard part. CBOM and AIBOM will raise the same questions for different asset classes. This is also where the vendor-capability question gets answered: some SBOM platforms were built strictly around a software-package data model and cannot represent cryptographic or AI-model data without a rebuild, while others were architected to treat “BOM” as a general concept and can extend into new BOM types as a configuration exercise rather than a new procurement.

That split points to two legitimate models. Specialist tools, built around one asset type, tend to go deeper on that asset's edge cases, such as catching a cryptographic library three dependencies deep, and a specialist is often the stronger choice where one risk category dominates. Multi-BOM platforms unify several BOM types under one system of record, useful when a single vulnerability spans software, hardware, and cryptography at once, but extending a software-shaped schema to cover cryptographic or AI-model data is a genuinely hard engineering problem, and some “multi-BOM” tools show shallow coverage once tested. Either way, the question for any vendor is the same: what BOM types does it actually support today, at what depth, shown in a real exported record rather than a roadmap slide?

Buyer's Guide: BOM Types at a Glance

Cybeats is included below as an example of how a single platform can extend coverage across the BOM family. For domains where an organization's risk is especially concentrated, cryptographic modernization ahead of a hard deadline, for instance, pairing that platform coverage with deep domain specialists can add further assurance.

BOM TypeWhat It DocumentsMaturityCybeats Coverage (Example)SBOM (Software)Components, libraries, versions, suppliers, licenses, dependencies, known vulnerabilitiesMature; SPDX and CycloneDX establishedNative. SBOM Studio + SBOM Consumer; SPDX 2.2-3.0.1, CycloneDX 1.2-1.7VEX (Exploitability)Affected, not affected, fixed, under investigationMature, paired with SBOMNative, in vulnerability lifecycle workflowHBOM (Hardware)Chips, boards, sensors, firmware components, origin, lifecycle statusDeveloping; less standardizedSupported as part of the platformCBOM (Cryptographic)Algorithms, certificates, key lengths, trust anchors, TLS config, signingDeveloping fast ahead of the 270-day EO 14412 deadline; a genuine specialist disciplineSupported; pairs well with dedicated CBOM specialists for organizations running deep, deadline-driven PQC programsAIBOM (AI)Models, datasets, training data, pipelines, lineage, provenance, governanceEarly, standardizing via CycloneDX ML-BOMSupported; CTO Dmitry Raidman co-leads OWASP AIBOM InitiativeQBOM (Quantum)Quantum algorithms, hardware, sensors, protocolsNot yet standardizedAddressed today through CBOM coverage as the category takes shapeSaaSBOMCloud services, APIs, SaaS dependenciesEarlyCategory still forming industry-wideDBOM (Data)Datasets, sources, lineage, usage restrictionsEarly, overlaps AIBOMOverlaps with AIBOM's dataset documentationFBOM (Firmware)Firmware components, versions, embedded dependenciesEarly, overlaps HBOMAddressed within HBOM coverage

The Bottom Line

CBOM is not a hypothetical future requirement; EO 14412 has put a federal clock on it, and AIBOM is following a parallel path. More BOM types will likely follow. The right response is neither panic about a new procurement cycle for every acronym nor the assumption that one platform must do everything. It is a clear-eyed inventory of existing capability, what a specialist could add where risk is deepest, and what an integrated platform could add where risk is broadest. Whichever mix an organization lands on, the standard for any vendor stays the same: real depth in the BOM types it claims to support, verified against an actual output, not a checkbox.