What is a Cryptographic Bill of Materials (CBOM)?

Most organizations cannot list, off the top of their head, every place they rely on RSA or elliptic-curve cryptography — it’s buried in TLS configs, signing pipelines, libraries, certificates, and third-party components. That’s a problem, because those are exactly the algorithms a future quantum computer threatens, and you can’t plan a migration around assets you haven’t enumerated.

A Cryptographic Bill of Materials (CBOM) is the answer to “what crypto do we actually have?” — an inventory you build once and keep current, so migration becomes a tracked project instead of a guess.

A CBOM extends the familiar idea of a Software Bill of Materials (SBOM) — a list of the components in your software — to cryptography specifically. It’s a machine-readable inventory of cryptographic assets: the algorithms in use, the keys and certificates, and the protocols, each annotated with its purpose, the standard it implements, and its status.

The CycloneDX specification defines a standard CBOM format, so the inventory is a portable artifact rather than a one-off spreadsheet. A single entry might read: primitive ML-DSA-87, standard FIPS 204, role “answer-signing,” status finalized.

Two forces make CBOMs timely. NIST’s finalized post-quantum standards mean migration is now a concrete task, not a someday — and the inventory is step one. In parallel, SBOM requirements from CISA and others are normalizing the expectation that organizations can produce a machine-readable list of what’s inside their systems, with cryptography an increasingly explicit part of that.

A CBOM is also useful as evidence: it’s the kind of technical documentation an auditor or regulator can actually check, and publishing one is a credible signal that you know your own cryptographic posture.

Practically, a CBOM does three jobs. It scopes your migration (which primitives, where, in what priority). It tracks progress (what’s moved to post-quantum, what hasn’t). And it serves as documentation you can hand to a third party — mapped to standards, so claims are checkable rather than asserted.

Throndar publishes its own CBOM: every primitive it uses, mapped to its NIST standard and role, so the cryptographic claims on the site are inspectable rather than marketing.