A Cryptography Bill of Materials (CBOM) is the document a post-quantum migration is planned from. It lists the cryptography a system actually uses: the algorithms, the keys and certificates, the protocols that negotiate them, and where each one is used. CycloneDX, the OWASP standard that became ECMA-424 in 2024, carries it as a first-class part of a bill of materials, and the federal migration guidance assumes you have one. This article is about reading one: which fields answer which question, and what changes when the document is live rather than generated once.
One component type, four kinds of asset
In CycloneDX a CBOM entry is a component of type cryptographic-asset. Its cryptoProperties block says which of four kinds it is: an algorithm, a certificate, a protocol, or related cryptographic material such as a key, a token or a secret. Everything else in the document hangs off those four.
Algorithm entries carry the properties a migration planner needs first: the primitive (a key-encapsulation mechanism, a signature scheme, a block cipher, a hash), the parameter set (RSA-2048, P-256, ML-KEM-768, AES-256-GCM), the cryptographic functions it is used for (key generation, encapsulation, signing, verification), the execution environment and, since the 1.6 specification, the NIST quantum security level the parameter set claims. That one field, read across the whole inventory, is the first sort of a migration plan.
Certificate entries record subject and issuer, the validity window, the signature algorithm and the public key the certificate binds, each as a reference to its own algorithm entry. Protocol entries record the protocol type and version (TLS 1.2, TLS 1.3, SSH, IPsec) and the cipher suites offered or negotiated, each suite resolving to the algorithm entries it is built from. Related cryptographic material records the kind of material (private key, public key, secret key, token, nonce, salt), its size, its lifecycle state and dates, the algorithm it belongs to and how it is itself secured.
The references are the point
A CBOM is a graph, not a list. The certificate points at its signature algorithm; the TLS protocol entry points at its cipher suites, which point at their key-exchange, signature, cipher and hash algorithms; the dependency section records which component provides which cryptographic capability to which service. Reading a CBOM means following those references: start from a system you care about, find the protocols it speaks, resolve them to algorithms, and read the quantum security level and the key sizes you arrive at. If a protocol entry says TLS 1.3 and its cipher suites resolve to X25519 key exchange and ECDSA P-256 signatures, the system is quantum-vulnerable in both key establishment and authentication, and both deadlines in OMB M-26-15, post-quantum key establishment by the end of 2030 and post-quantum signatures by the end of 2031, apply to it.
Evidence: how each fact was obtained
The field most often skipped on first reading is evidence. CycloneDX lets each component carry the technique that produced it (source-code analysis, binary analysis, manifest analysis, instrumentation, dynamic analysis and attestation, among others) and a confidence value for the identification. In a CBOM this is what separates an inventory from a claim. An Endpoint Client that performed a TLS handshake itself has stronger evidence for the negotiated suite than an observer inferring it from traffic, and neither is the same as a signed Certificate Transparency entry or a direct read from a key store. QuantaView writes the technique and the confidence onto every component in its export and states unknowns explicitly in a three-state model: unknown to the author, structurally not applicable, or withheld by policy. A blank field in a CBOM should make you ask which of those three it is.
Integrity: who asserts the document
A CBOM is used to decide what to change in production, so the question of who produced it and whether it has been altered is not academic. Signed exports answer it. QuantaView exports every CycloneDX 1.7 CBOM as a bundle that can carry the exact document bytes, a detached FIPS 204 ML-DSA-65 signature and the signer certificate, chaining to a tenant root that uses ML-DSA-87, verifiable with stock OpenSSL. The signature is post-quantum on purpose: a document about leaving RSA should not be protected with an RSA signature. The document also states its own revision, using the tenant's export sequence as the BOM version, so two CBOMs can be ordered without comparing their contents.
What a live CBOM changes about remediation planning
Most CBOMs are generated once. A certificate rotates, a library updates, a service ships, and the document is wrong without anyone knowing. A live CBOM is maintained as state and re-derived every discovery cycle, and that changes how a remediation plan is built and measured.
Prioritization is measured, not estimated. Quantum-risk scoring runs on the current inventory: harvest-now, decrypt-later exposure, weak keys and expiring certificates, scored per asset, so the plan starts with the systems that carry long-lived sensitive data over quantum-vulnerable key exchange.
Change is one approval at a time. The platform prepares the change for one recommendation, a person approves it, the job applies it with a rollback point and a validation check, and a signed attestation records what was done. Remediation is one-click, human-approved and fully reversible; there is no automatic change to production cryptography.
The inventory verifies the fix. The next discovery cycle re-derives state independently. If a fix did not hold, the asset returns as a finding, with evidence; if it did, the CBOM, the risk score and the compliance posture move together. Progress against the 2030 and 2031 dates is read from the document, not from a tracker beside it.
Where the standards sit
CycloneDX publishes the CBOM capability and the specification; the 2024 edition is ECMA-424. NIST's National Cybersecurity Center of Excellence covers cryptographic discovery and inventory in SP 1800-38, and NIST SP 800-131A sets the algorithm and key-length transitions a CBOM is read against. The federal calendar is OMB M-26-15. EnQuanta's own research on the threat the inventory is being built against, "A Scenario-Based Evaluation of CRQC+AI Vulnerability Spectrum for TLS 1.3 Cryptographic Dependencies" (Grover, Haile, Pedersen, Uner and Erickson, arXiv:2608.23785), grades quantum and AI-accelerated risk to each TLS 1.3 primitive by the evidence behind it: it finds no known break of ML-KEM, ML-DSA, SLH-DSA or AES-256, while RSA risk crosses its modeled 50 percent line between 2030 and 2032.
The short version: read the asset types first, follow the references, check the evidence and the signature, and insist that the document is live before you plan from it. A CBOM you can read is the first half of a post-quantum migration. A CBOM that stays true while you remediate is the second.