What a CBOM Is — and Why an SBOM Won't Answer the Quantum Question

The industry is currently engaged in a critical, time-sensitive shift toward Post-Quantum Cryptography (PQC), driven by the eventual threat posed by quantum computers capable of decrypting current encrypted data ("harvest now, decrypt later"). A key challenge stalling this migration across many organizations is the lack of comprehensive visibility into their cryptographic assets. Traditional Software Bills of Materials (SBOMs) list software components but are insufficient because they do not detail *how* those components use cryptography—such as specific algorithms, key sizes, or bundled certificates.
To address this gap, the concept of a Cryptography Bill of Materials (CBOM), standardized in OWASP CycloneDX 1.6 and ECMA-424, provides a machine-readable inventory mapping cryptographic assets to the software components that provide them. While SBOMs remain necessary for tracking component versions and licenses, CBOMs are vital for identifying specific quantum-vulnerable elements like RSA or ECC embedded deep within third-party libraries or closed-source systems where source code cannot be inspected. NIST has finalized initial PQC standards (FIPS 203, 204, 205), moving the focus from *what* to adopt toward the difficult task of discovering *where* the vulnerabilities currently reside across operational software.

Every post-quantum cryptography roadmap requires an inventory of current cryptography algorithms.
The hardest cryptographic assets are often located inside third-party and closed-source software.
A Cryptography Bill of Materials (CBOM) is a machine-readable inventory of cryptographic assets and their component relationships.
CBOM was standardized in OWASP CycloneDX 1.6, released April 2024, and ratified as ECMA-424.
CycloneDX 1.7 added standardized algorithm families to aid PQC readiness assessments (October 2025).
A CBOM records assets such as algorithms, certificates, protocols, and cryptographic material (keys).
An SBOM lists components and dependencies but lacks details on algorithm usage or key sizes.
NIST finalized three post-quantum standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA).
NIST IR 8547 proposes deprecating widely used RSA and ECC key sizes after 2030, with a total prohibition by 2035.
CISA, NSA, and NIST recommend automated discovery across network protocols and applications for quantum readiness.

The core tension explored here is the procedural mismatch between an impending technological deadline (quantum decryption capability) and the current operational visibility of software systems. The narrative pivots on reframing "risk assessment" from a binary choice ("vulnerable vs. safe") to an inventory-driven process. By elevating the CBOM as a necessary companion to the SBOM, the analysis seeks to move organizations past paralysis—the initial stall described when cryptographic discovery becomes too complex.
The unstated paradigm driving this concern is the opacity of modern software supply chains. Most crucial cryptography isn't self-authored; it’s buried in compiled binaries and vendor SDKs. This pushes responsibility onto vendors, a system that relies on attestations rather than provable evidence, creating an inherent trust deficit in critical infrastructure security planning. Furthermore, the emphasis on *discovery* before *adoption* suggests that governance frameworks are currently ahead of executable capability, mandating foundational data gathering (the CBOM) as the highest priority administrative act.
The real agency cost here is time. The "harvest now, decrypt later" threat implies a zero-sum race against adversarial storage capabilities. The benefit accrues to organizations achieving resilient infrastructure sooner, while the cost bears down heavily on entities unable to map their dependencies before deadlines set by NIST and NCSC arrive.
What assumptions underpin this urgency? That vendor disclosure is insufficient proof of compliance. What perspective minimizes the role of business context—the value chain risk associated with a specific piece of deprecated cryptography versus its mere presence in an inventory? If discovery tools are inherently limited to what ships, how much risk remains anchored outside measurable software artifacts (e.g., undocumented cloud services or proprietary protocol implementations)?
Patterns detected: ARC-0024 Ambiguity