Software Bills of Materials stopped being optional for anyone selling into US federal supply chains after Executive Order 14028, which in 2021 directed the National Telecommunications and Information Administration (NTIA) to define what an SBOM actually has to contain. NTIA’s “Minimum Elements for an SBOM” set out seven baseline fields – supplier name, component name, version, dependency relationships, and so on – and named two accepted formats for expressing them: SPDX and CycloneDX. What neither format could do, at the time, was describe cryptography itself. A CBOM had no formal home. That changed in April 2024.
Where CBOM actually sits
On 9 April 2024, the OWASP Foundation released CycloneDX v1.6, adding a “cryptographic-asset” component type and an accompanying cryptoProperties schema – work developed largely by IBM Research. This is the detail worth being precise about: a CBOM isn’t a separate file format bolted onto SBOM tooling. It’s the same CycloneDX document type an organisation may already be generating for software supply chain compliance, extended with a component type for cryptography. An organisation already producing SBOMs under EO 14028-driven procurement requirements doesn’t need a second, disconnected process to start inventorying cryptography – it needs the newer version of a schema it may already use.
What a cryptographic-asset component actually captures
The cryptographic-asset type covers several subtypes: algorithms, certificates, protocols, and related key material. Beyond simply listing them, CycloneDX distinguishes between two kinds of dependency relationship – “implements” and “uses”. A cryptography library that contains an implementation of an algorithm is modelled differently from an application that merely calls that library. That distinction is what makes a CBOM traceable rather than just descriptive: if a shared library implements ML-KEM-768 and forty internal applications use that library, exposure can be reasoned about through the dependency graph, rather than rediscovered application by application.
Why the standardisation itself matters
CycloneDX is no longer solely an OWASP project. It has been adopted by Ecma International as ECMA-424, maintained by Ecma Technical Committee 54, with CycloneDX v1.7 – released 21 October 2025 – forming the basis of the standard’s second edition, adopted by the Ecma General Assembly in December 2025. That progression matters in practice, not just as a credential. A CBOM built to a specification maintained by an international standards body is portable across scanning tools, SBOM platforms, and auditors in a way a proprietary export format never is – and it’s part of why CycloneDX, rather than SPDX, has become the default choice specifically for cryptographic inventory. SPDX remains the other NTIA-recognised SBOM format, but it doesn’t yet have an equivalent native model for cryptographic assets.
What this means for a migration programme
The practical implication is a narrower gap than it first appears between two things that are often run as separate initiatives: software supply chain compliance and post-quantum readiness. If cryptographic inventory is expressed in the same schema, and increasingly the same tooling ecosystem, as the SBOMs an organisation may already be producing for procurement or regulatory reasons, it stops being a parallel programme competing for the same engineering time. Quantum Sentinel’s living Enterprise CBOM is built to align with this same CycloneDX cryptographic-asset model, so what Enterprise PQC Discovery finds is portable by design rather than locked into a proprietary export.
Further reading: what a CBOM actually contains, cryptographic discovery and CBOM, and our whitepaper on why every organisation needs a CBOM.