Cryptographic Bill of Materials (CBOM) Fundamentals

What Is a Cryptographic Bill of Materials?

A Cryptographic Bill of Materials (CBOM) is a structured inventory of every cryptographic asset in a system. It records which algorithms protect your data, what key sizes are deployed, which certificates secure your connections, and where cryptographic libraries are embedded in your software stack.

Think of it as a complete map of your cryptographic landscape. Just as a Software Bill of Materials (SBOM) catalogs software components and dependencies, a CBOM catalogs the cryptographic primitives those components rely on.

Every organization uses cryptography. TLS certificates protect web traffic. SSH keys secure server access. Code signing certificates verify software integrity. Encryption algorithms protect data at rest and in transit. A CBOM captures all of these assets in a single, queryable inventory.

Without this inventory, security teams operate blind. They cannot answer basic questions: How many RSA-2048 certificates exist in production? Which services still use SHA-1? Where does TLS 1.1 persist? A CBOM answers these questions with structured, machine-readable data.

The CycloneDX CBOM Standard

The OWASP CycloneDX project defines the open standard for CBOMs. CycloneDX already supports SBOMs, VEX (Vulnerability Exploitability eXchange), and hardware BOMs. The cryptographic extension adds fields specific to cryptographic assets.

A CycloneDX CBOM entry includes:

• Algorithm identifier: The specific algorithm in use (RSA-2048, ECDSA P-256, AES-256-GCM, ML-KEM-768).
• Key size and parameters: Key length, curve parameters, or security level.
• Certificate metadata: Subject, issuer, validity period, serial number, and chain depth.
• Protocol version: TLS 1.2, TLS 1.3, SSH v2, IPsec IKEv2.
• Library reference: The cryptographic library providing the implementation (OpenSSL 3.x, BoringSSL, AWS-LC).
• Compliance status: Whether the asset meets current standards (FIPS 140-3, CNSA 2.0, PCI DSS 4.0).

The standard supports JSON and XML formats. This machine-readability enables automation. Security tools can parse CBOM data, flag non-compliant assets, and generate migration reports without manual review.

CycloneDX CBOMs integrate with existing DevSecOps pipelines. CI/CD systems can generate CBOMs during builds. Vulnerability scanners can cross-reference CBOM data against known weaknesses. Compliance platforms can audit cryptographic posture continuously.

Why CBOM Matters for Post-Quantum Migration

Post-quantum migration demands replacing every quantum-vulnerable algorithm in your infrastructure. ML-KEM (FIPS 203) replaces RSA key transport and ECDH key agreement. ML-DSA (FIPS 204) replaces RSA and ECDSA digital signatures. SLH-DSA (FIPS 205) provides a hash-based signature alternative.

This replacement cannot happen without a complete inventory. Consider the scope:

• TLS certificates on web servers, load balancers, and API gateways use RSA or ECDSA signatures.
• SSH keys on thousands of servers use RSA or ECDSA key pairs.
• Code signing certificates use RSA or ECDSA to verify software packages.
• VPN tunnels use ECDH for key exchange and RSA for authentication.
• Database encryption uses RSA key wrapping for data-at-rest protection.
• Email encryption uses RSA or ECDH for S/MIME and PGP.

Each of these systems needs a migration plan. Each plan requires knowing exactly which algorithms are deployed, where they run, and what depends on them. A CBOM provides this data.

Without a CBOM, migration planning relies on manual audits. Teams search configuration files, inspect certificate stores, and review code repositories one system at a time. This approach misses embedded cryptography in third-party libraries, firmware, and legacy systems. It scales poorly across large enterprises with thousands of services.

A CBOM automates this discovery. It scans infrastructure, catalogs cryptographic assets, and produces a structured report that migration teams can act on immediately.

CBOM and QCecuring’s Roadmap

CBOM is QCecuring’s next planned offering. It builds on the cryptographic visibility that QCecuring’s existing platforms already provide.

QCecuring’s CLM platform discovers and manages TLS/SSL certificates across cloud, on-premises, and hybrid environments. It already tracks certificate algorithms, key sizes, and expiration dates. CBOM extends this visibility beyond certificates to cover all cryptographic assets — keys, algorithms, protocols, and libraries.

QCecuring’s SSH KLM discovers and governs SSH keys across server infrastructure. It tracks key types, sizes, and access relationships. CBOM will unify this SSH key data with certificate data and broader cryptographic asset information in a single inventory.

The planned CBOM capability will:

• Discover cryptographic assets automatically across your infrastructure, including embedded cryptography in third-party dependencies.
• Classify assets by quantum vulnerability — flagging RSA, ECDSA, ECDH, and other algorithms that Shor’s algorithm threatens.
• Generate CycloneDX-compliant CBOM reports in JSON and XML formats for integration with existing security tooling.
• Prioritize migration targets based on algorithm vulnerability, data sensitivity, and system criticality.
• Track migration progress as teams replace quantum-vulnerable algorithms with ML-KEM, ML-DSA, and SLH-DSA.

This positions CBOM as the discovery and planning layer for PQC migration, while CLM and SSH KLM handle the operational execution of certificate and key transitions.

Visit the CBOM product page to learn more about what is planned.

Building a CBOM: What to Inventory

A comprehensive CBOM covers five categories of cryptographic assets:

Algorithms in use. Document every cryptographic algorithm deployed in production. This includes key exchange algorithms (ECDH, RSA, DH), signature algorithms (RSA, ECDSA, EdDSA), encryption algorithms (AES-GCM, ChaCha20-Poly1305), and hash functions (SHA-256, SHA-384, SHA-512).

Keys and key material. Record all cryptographic keys — their types, sizes, locations, and rotation schedules. This covers TLS private keys, SSH key pairs, API signing keys, encryption keys for data at rest, and key encryption keys (KEKs) in key management systems.

Certificates and certificate chains. Catalog every X.509 certificate in your infrastructure. Include the signature algorithm, key size, issuing CA, validity period, and subject alternative names. Track certificate chains to identify root CAs that may need PQC-capable replacements.

Protocols and cipher suites. Document which protocol versions and cipher suites are negotiated in production. TLS 1.2 cipher suites using RSA key exchange are quantum-vulnerable. TLS 1.3 cipher suites using ECDHE are also vulnerable. Record where each protocol version is active.

Cryptographic libraries and dependencies. Identify which cryptographic libraries your applications use. OpenSSL, BoringSSL, AWS-LC, and other libraries will release PQC-capable versions on different timelines. Knowing your library dependencies determines your upgrade path.

CBOM in the Migration Lifecycle

CBOM fits into the first two phases of PQC migration: inventory and assessment.

During inventory, CBOM scans your infrastructure and produces a complete catalog of cryptographic assets. This answers the foundational question: what cryptography do we use, and where?

During assessment, CBOM classifies each asset by quantum vulnerability. RSA-2048 certificates are flagged as vulnerable. AES-256 encryption is marked as quantum-resistant (with Grover’s caveat). ECDH key exchanges are flagged for replacement with ML-KEM.

The assessment output feeds directly into migration planning. Teams can sort assets by risk — prioritizing systems that protect long-lived secrets or face regulatory deadlines. They can estimate the scope of migration work by counting vulnerable assets per system, per team, or per business unit.

QCecuring’s CLM platform then executes the certificate migration. When post-quantum certificate authorities begin issuing ML-DSA certificates, CLM automates the renewal and deployment process. The combination of CBOM for discovery and CLM for execution creates an end-to-end PQC migration workflow.

Getting Started Before CBOM Ships

Organizations do not need to wait for automated CBOM tooling to begin building cryptographic inventories. Start with the assets you can see today.

Use QCecuring’s CLM to inventory certificates. CLM discovers certificates across your infrastructure and reports their algorithms and key sizes. This gives you immediate visibility into your certificate-based cryptographic posture.

Audit SSH keys with QCecuring’s SSH KLM. SSH KLM discovers key pairs, tracks their types and sizes, and identifies orphaned or over-privileged keys. This covers the SSH portion of your cryptographic inventory.

Review TLS configurations on public-facing services. Tools like SSL Labs and testssl.sh report which cipher suites your servers negotiate. Document the results as the protocol layer of your CBOM.

Check cryptographic library versions in your dependency manifests. Package managers (npm, pip, Maven, NuGet) list your dependencies. Identify which packages provide cryptographic functionality and track their PQC readiness roadmaps.

These manual steps build the foundation that automated CBOM tooling will later extend and maintain. Starting now means your organization has a head start when QCecuring’s CBOM capability launches — and when regulatory deadlines for PQC migration arrive.