Cryptographic Bill of Materials (CBOM), explained

A regular SBOM, built to formats like CycloneDX or SPDX, answers "what components and versions does this product contain?" — see CycloneDX vs. SPDX: SBOM formats for that comparison. A CBOM answers a narrower, different question: what cryptography does this product actually use, and where? CycloneDX's own published schema defines a dedicated cryptoProperties structure for this, described in the schema itself as "cryptographic properties, algorithms, protocols, and related data that uniquely identify the cryptographic asset." Every cryptographic asset gets classified under an assetType: algorithm, certificate, relatedCryptoMaterial (keys, secrets), protocol, ciphersuite, signature, salt, or token. For algorithms specifically, an algorithmProperties block captures the detail that actually matters for a migration decision — primitives, parameterizedAlgorithm, cryptoKeySize, cryptoKeyFormat, cryptoKeyGeneration, nonce and certifications. A CBOM entry that says "RSA-2048 for TLS key exchange in module X" is something a migration team can act on; a software SBOM entry that says "OpenSSL 3.0.2" is not, because it doesn't say which of OpenSSL's many supported algorithms the product actually negotiates.

US federal cryptographic-inventory policy did not start in 2026 — OMB Memorandum M-23-02 (18 November 2022) first directed civilian agencies to submit a prioritized inventory of quantum-vulnerable cryptographic systems, building on the White House's 2022 National Security Memorandum on quantum computing. What changed on 22 June 2026 is that the inventory requirement got a name, a schema deadline, and teeth reaching outside government. Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," directs CISA and NIST to publish the minimum elements for a Cryptographic Bill of Materials within 270 days of the order — landing roughly Q1 2027 — explicitly so agencies can run "automated assessment of the cryptographic assets utilized by a hardware or software element," per secondary reporting on the order's text. OMB Memorandum M-26-15, issued two days later on 24 June 2026, translates that into an operational five-phase timeline:

Agencies were directed to submit a PQC Migration Plan to OMB and the National Cyber Director within 120 days of M-26-15 — around 22 October 2026. One sequencing wrinkle worth tracking if you supply the federal government: per secondary analysis, agencies must start building migration plans and inventories before CISA and NIST's CBOM minimum-elements specification actually exists, since that specification isn't due until roughly Q1 2027 — meaning an organization building a CBOM today should expect to reconcile its own format choices against CISA/NIST's baseline once it lands, not assume today's ad hoc inventory is the final shape.

The detail that matters most for a device or firmware vendor rather than a federal IT office: per secondary legal analysis of Executive Order 14412, the order directs the FAR (Federal Acquisition Regulatory) Council to propose, within 180 days of the order, a rule requiring covered federal contractors to comply with NIST's FIPS standards — including NIST's finalized post-quantum algorithms — by 31 December 2030, the same date set for agencies to migrate key establishment on their most sensitive systems. Digital-signature migration follows a year later, by 31 December 2031. A separate FAR rule, per the same reporting, is to require contractors to maintain vulnerability disclosure policies that specifically address cryptographic weaknesses, on a 270-day clock. For a hardware or firmware company selling into, or hoping to sell into, the US federal supply chain, this means a CBOM is heading toward the same category SBOMs already occupy under Executive Order 14028: a delivery artifact a contracting officer can require, not an optional transparency gesture.

CBOM as a schema did not start inside CycloneDX. IBM Research developed it as a standalone extension of the format and, per CycloneDX's own 9 April 2024 release announcement, worked with the CycloneDX community to upstream it: the announcement states the Cryptographic Bill of Materials, "developed by researchers and software engineers at IBM, serves as a structured framework for inventorying cryptographic assets," alongside a second new capability in the same release, CycloneDX Attestations (CDXA). CycloneDX 1.6 — the version carrying CBOM — has since been adopted as Ecma International standard Ecma-424. IBM continues to maintain CBOMkit, an open-source tool IBM describes as letting developers "generate, visualize, analyze and store" cryptographic inventories against the CycloneDX schema.

The practical catch: CBOM support is newer and less universally implemented than the base CycloneDX software-component model. A scanning tool that already produces a clean software SBOM in CycloneDX format does not automatically populate cryptoProperties — that requires detecting cryptographic API calls, certificate material and runtime protocol negotiation, a different and generally harder analysis than dependency resolution. Secondary reporting on M-26-15 notes OMB's own expectation that "vendors producing SBOMs already possess relevant tooling and processes" to extend into CBOM production — an assumption worth testing against your actual pipeline rather than accepting at face value, particularly for firmware that mixes source code, vendored libraries and silicon-level crypto accelerators a static source-code scan won't see.