A cryptographic bill of materials (CBOM) is a structured, machine-readable inventory of every cryptographic asset used by a system — algorithms, key lengths, certificates, protocols, libraries, and the specific code paths or components that invoke them. Think of it as the cryptographic sibling of a software bill of materials (SBOM): where an SBOM tells you which open-source packages and versions live inside your application, a CBOM tells you which encryption algorithms, hash functions, key exchange mechanisms, and digital signature schemes are actually protecting your data, and where they live in your architecture. It captures details like "this microservice negotiates TLS 1.2 with RSA-2048 key exchange" or "this firmware image signs updates with ECDSA P-256." Without that granularity, organizations cannot answer a question that has suddenly become urgent: which systems will break — or become insecure — when quantum computers make today's public-key cryptography obsolete.
What is a cryptographic bill of materials?
A cryptographic bill of materials is a catalog of cryptographic dependencies — algorithms, protocols, key sizes, certificate chains, and the software or hardware components that implement them — mapped to the specific systems and code paths where they're deployed. Formats like CycloneDX's CBOM schema (built on the same standard many teams already use for SBOMs) represent each cryptographic asset as a structured record: the algorithm family (RSA, ECC, AES, SHA), the specific parameters (key size, curve, mode), where it's implemented (a TLS library, an HSM, a custom crypto module), and how it's used (data-at-rest encryption, code signing, session establishment). A CBOM entry isn't just "this app uses OpenSSL" — it's "this app uses OpenSSL 3.0.2 to perform RSA-2048 key exchange for inbound TLS connections on port 443, and that certificate expires in 14 months." That level of specificity is what turns a vague sense of "we use crypto somewhere" into an actionable, queryable inventory.
Why does PQC migration require a CBOM?
Post-quantum cryptography (PQC) migration requires a CBOM because you cannot replace what you cannot find, and quantum-vulnerable algorithms are scattered far more widely than most security teams assume. NIST finalized its first PQC standards in August 2024 — ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for digital signatures — and government mandates like NSA's CNSA 2.0 timeline are pushing agencies and their vendors toward full transition by 2033, with some categories required much sooner. But migration isn't a single "flip the algorithm" switch. RSA, ECDH, ECDSA, and Diffie-Hellman are embedded in TLS stacks, VPN gateways, code-signing pipelines, IoT firmware, database encryption modules, and third-party SDKs that most inventories never touch. A CBOM is what lets a security team scope the actual blast radius: which certificates need reissuing with PQC-safe signatures, which embedded devices can't be patched and need hardware replacement, and which vendor dependencies are silently still using 1024-bit RSA. Attempting PQC migration without this inventory means discovering vulnerable systems during an incident or an audit, rather than on your own schedule.
How does crypto inventory discovery actually work?
Crypto inventory discovery works by combining static and dynamic analysis to find cryptographic usage that manual audits reliably miss. Static analysis scans source code, binaries, and configuration files for cryptographic API calls, hardcoded key material, deprecated library imports, and certificate files. Dynamic analysis observes live network traffic and runtime behavior to catch negotiated protocol versions and cipher suites that static code review can't see — for example, a server configured to prefer TLS 1.3 that still falls back to TLS 1.0 for legacy clients. Effective discovery also has to reach into places teams forget about: build pipelines that sign artifacts, infrastructure-as-code templates that provision KMS keys, container base images with bundled OpenSSL versions, and hardware security modules whose firmware hasn't been touched in years. A real-world illustration: a mid-size payments company assumed its cryptography was centralized in a single gateway service. A discovery pass across its codebase and network traffic turned up SHA-1 certificate signatures still active on three internal admin tools, an ECDSA implementation using a deprecated curve in a partner API client library, and RSA-1024 keys hardcoded in a decade-old batch job nobody had touched since a 2014 migration. None of that showed up in the team's existing asset inventory because that inventory tracked servers and applications, not cryptographic primitives.
What should a CBOM actually contain?
A usable CBOM must contain the algorithm, key length, implementation source, usage context, and lifecycle status for every cryptographic asset — anything less turns into a list that looks complete but can't drive a migration decision. Concretely, that means: the cryptographic primitive and mode (AES-256-GCM, RSA-2048-OAEP, ECDSA-P384); the library or hardware module implementing it (OpenSSL 1.1.1, BoringSSL, a specific HSM firmware version); the certificate chain and expiration dates where applicable; the specific service, endpoint, or code location using it; whether it's quantum-vulnerable, quantum-resistant, or symmetric (and therefore lower-priority under Grover's algorithm's more modest quantum speedup); and ownership — which team or vendor is responsible for remediation. This is also where cryptographic asset management becomes distinct from a one-time inventory exercise. A CBOM that's accurate on the day it's generated and never updated again degrades quickly: certificates rotate, dependencies get upgraded, new services ship with new crypto choices. Treating the CBOM as a living asset — refreshed on every build, tied into CI/CD, and versioned alongside the software it describes — is what separates a compliance checkbox from an operational tool a security team can actually query when a new NIST deprecation notice or CVE drops.
What happens if you migrate to PQC without a CBOM?
Without a CBOM, PQC migration turns into a guessing exercise that either misses vulnerable systems or wastes effort re-securing systems that were never at risk. Teams end up prioritizing based on which applications are top-of-mind rather than which ones actually handle sensitive data with quantum-vulnerable algorithms — meanwhile the "harvest now, decrypt later" threat means adversaries are already capturing encrypted traffic today with the expectation of decrypting it once cryptographically relevant quantum computers exist. A financial services firm without cryptographic asset management might spend a migration cycle rewriting a customer-facing web app's TLS configuration while leaving a batch-processing pipeline that encrypts long-retention customer records — the exact kind of data an adversary would harvest now — sitting on RSA-2048 for another three years because no one knew it was there. Regulators are starting to ask directly: PCI DSS, HIPAA-adjacent guidance, and federal procurement requirements increasingly expect organizations to demonstrate cryptographic agility, and "we don't have a complete list of what encryption we use" is not a defensible answer during an audit. A CBOM converts migration from reactive triage into a scoped, sequenced project with measurable completion criteria.
How Safeguard Helps
Safeguard builds cryptographic bill of materials generation directly into the software supply chain security workflows teams already run for SBOM and vulnerability management, so crypto inventory discovery isn't a separate, one-off audit project. Safeguard scans source repositories, container images, build artifacts, and dependency trees to identify cryptographic libraries, algorithms, key sizes, and certificate usage automatically, then maps each finding to the specific service, package, or deployment where it lives. That inventory is generated continuously as part of CI/CD, not as a point-in-time snapshot, so the CBOM stays accurate as code and dependencies change — the foundation of durable cryptographic asset management rather than a report that's stale within a quarter. Findings are prioritized by exploitability and quantum-vulnerability status, giving security and platform teams a ranked, actionable list of what to migrate first as PQC deadlines approach, rather than a flat inventory they have to triage manually. For organizations under pressure to show auditors and regulators a concrete PQC migration plan, Safeguard's CBOM output doubles as the evidentiary record: a versioned history of what cryptography existed, when it was found, and when it was remediated.