What Is a CBOM and Why Your Organization Needs One

You cannot migrate what you cannot see. This is the fundamental premise behind the Cryptographic Bill of Materials (CBOM) -- a structured inventory of every cryptographic asset in your organization's infrastructure. As the post-quantum migration accelerates, the CBOM has become an essential artifact for security teams, compliance officers, and executive leadership. Without one, you are planning a migration with no map.

What Is a CBOM?

A CBOM is a machine-readable inventory that catalogs every cryptographic algorithm, protocol, certificate, key, and library used across your systems. Think of it as a Software Bill of Materials (SBOM), but focused specifically on cryptography. Where an SBOM tells you what software components are in your application, a CBOM tells you what cryptographic primitives those components use and whether they are quantum-safe.

A well-constructed CBOM answers critical questions:

What algorithms are we using across all systems?
Which of those algorithms are quantum-vulnerable?
Where are our RSA, ECDSA, and ECDH implementations?
What certificates need to be reissued with post-quantum algorithms?
Which third-party libraries and dependencies include cryptographic code?
What is our overall quantum risk exposure?

Without a CBOM, organizations are flying blind. Most enterprises have thousands of cryptographic assets scattered across applications, infrastructure, and third-party services. A mid-size company might have 500+ TLS certificates, dozens of SSH key pairs, hundreds of API tokens signed with HMAC or RSA, and unknown numbers of cryptographic library calls embedded in application code. Manual audits cannot capture this complexity at scale.

The CycloneDX Standard

The industry-standard format for CBOMs is CycloneDX, maintained by OWASP. Version 1.7 introduced dedicated support for cryptographic assets with a structured schema that enables machine-readable classification of every cryptographic component in your infrastructure.

What CycloneDX 1.7 Captures

Algorithm declarations: Each algorithm in use is recorded with its name, variant, key size, and quantum safety classification. For example, a declaration might specify RSA-2048 for key exchange with a quantum safety status of "vulnerable" and a recommended migration target of ML-KEM-768.

Certificate inventory: X.509 certificates are cataloged with their issuer, subject, expiration date, signature algorithm, key type, and key size. This enables you to identify every certificate that uses a quantum-vulnerable signature algorithm (ECDSA, RSA) and plan reissuance with ML-DSA.

Protocol configurations: TLS versions, cipher suites, and key exchange mechanisms are recorded for every endpoint. This tells you exactly which servers are still negotiating RSA key exchange and which have upgraded to hybrid ML-KEM.

Key material metadata: Key sizes, creation dates, rotation policies, and storage locations are tracked without exposing actual key material. This helps identify keys that are overdue for rotation or stored in systems that do not support PQC algorithms.

Dependency mapping: Each cryptographic asset is linked to the applications and services that depend on it. This is critical for understanding the blast radius of a migration -- if you change the cipher suite on a load balancer, the CBOM tells you which 47 applications behind it will be affected.

Format and Integration

CycloneDX CBOMs can be exported as JSON or XML and integrated into existing security tooling:

json

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.7",
  "serialNumber": "urn:uuid:3e671687-395b-41f5-a30f-a58921a69b79",
  "version": 1,
  "components": [
    {
      "type": "cryptographic-asset",
      "name": "TLS Key Exchange",
      "cryptoProperties": {
        "assetType": "algorithm",
        "algorithmProperties": {
          "primitive": "ke",
          "parameterSetIdentifier": "P-256",
          "executionEnvironment": "server",
          "cryptoFunctions": ["keygen", "keyagree"],
          "nistQuantumSecurityLevel": 0,
          "classicalSecurityLevel": 128
        },
        "oid": "1.2.840.10045.3.1.7"
      }
    }
  ]
}

This structured format enables automated vulnerability scanning, compliance reporting, and migration tracking. Security orchestration tools can ingest the CBOM and flag quantum-vulnerable assets, generate migration tickets, and track remediation progress over time.

Why You Need One Now

Regulatory Mandates Are Here

The White House Executive Order on quantum computing and OMB Memorandum M-23-02 require federal agencies to inventory their cryptographic systems and submit migration plans. The NSA's CNSA 2.0 guidance establishes specific timelines for migrating National Security Systems. While these mandates apply directly to government agencies, the regulatory cascade has begun:

Financial services: The SEC and OCC have issued guidance on quantum risk disclosure. PCI-DSS 5.0 is expected to include quantum readiness requirements. Banks and payment processors are being asked about their PQC posture during regulatory examinations.
Healthcare: HIPAA's long-term confidentiality requirements (patient records must be protected for the patient's lifetime) make healthcare organizations particularly vulnerable to HNDL attacks. HHS has issued guidance recommending cryptographic inventories.
Critical infrastructure: CISA has published quantum readiness guidance for critical infrastructure operators. Energy, water, and telecommunications companies are expected to demonstrate PQC migration planning.
Defense industrial base: Defense contractors handling CUI (Controlled Unclassified Information) under CMMC are expected to align with CNSA 2.0 timelines.

Having a current CBOM is rapidly becoming a compliance baseline, not a nice-to-have.

Migration Planning Requires a Starting Point

You cannot build a migration roadmap without knowing your starting point. A CBOM tells you exactly how many systems need to transition from RSA to ML-KEM, from ECDSA to ML-DSA, and from SHA-1 to SHA-256. It quantifies the scope of work and enables realistic timeline planning.

Without a CBOM, migration planning devolves into guesswork. "We probably have a lot of RSA" is not a migration plan. "We have 1,247 TLS endpoints using ECDH-P256 for key exchange, 89 using RSA-2048 key transport, and 3,412 certificates signed with ECDSA-P256" is a migration plan. The CBOM transforms the first statement into the second.

This precision is also essential for Mosca Inequality calculations. Your migration timeline (X) depends directly on the scope of work, which the CBOM quantifies.

Risk Quantification at Scale

A CBOM enables precise risk scoring. Instead of estimating that "some systems use RSA," you can state that "347 endpoints use RSA-2048 for key exchange, protecting data with a 20-year confidentiality requirement, resulting in an HNDL risk score of 78." This precision transforms vague quantum risk into actionable metrics that boards and executives can understand.

The CBOM feeds directly into HNDL Score calculations. Factors 5 (Cryptographic Posture) and 6 (Deployment Breadth) in the HNDL model cannot be accurately scored without a comprehensive cryptographic inventory.

Continuous Monitoring and Drift Detection

Cryptographic posture is not static. New applications are deployed, dependencies are updated, certificates are renewed, and configurations drift. A CBOM that is generated once and never updated is nearly useless. The real value comes from continuous, automated CBOM generation integrated into your CI/CD pipeline and infrastructure monitoring.

Common drift scenarios that continuous CBOM monitoring catches:

A developer deploys a new microservice with a default TLS configuration that uses RSA key exchange instead of the organization's mandated hybrid ML-KEM.
A dependency update pulls in a new version of a cryptographic library that changes default algorithm selections.
A certificate renewal process reissues a certificate with ECDSA instead of ML-DSA because the CA template was not updated.
A load balancer configuration change removes the ML-KEM cipher suite from the negotiation order.

Without continuous monitoring, these regressions go undetected until the next audit -- which could be months or years later.

How to Build a CBOM: A Step-by-Step Process

Step 1: Network Scanning

Scan all network endpoints to identify TLS configurations, cipher suites, and certificate chains. This is the broadest and fastest way to establish your baseline.

What to scan:

All internet-facing services (web servers, APIs, mail servers)
Internal services (microservices, databases, message brokers)
VPN concentrators and SSH gateways
Load balancers and reverse proxies
Cloud service endpoints

For each endpoint, record the TLS version, supported cipher suites, negotiated key exchange algorithm, server certificate details (signature algorithm, key type, key size, issuer, expiration), and any client certificate requirements.

Step 2: Application Analysis

Inspect application code and dependencies for cryptographic library usage. This goes deeper than network scanning by identifying cryptographic operations that happen at the application layer.

What to look for:

Direct calls to OpenSSL, BoringSSL, libsodium, and language-specific crypto modules
JWT signing and verification (check the algorithm: RS256 uses RSA, ES256 uses ECDSA)
S/MIME email encryption and signing
XML digital signatures (XMLDSig)
Custom encryption/decryption operations on data at rest
Key derivation functions and password hashing

Static analysis tools can scan codebases for cryptographic API calls. Dynamic analysis can capture actual cryptographic operations during runtime.

Step 3: Certificate Inventory

Export all certificates from your PKI, certificate managers, and cloud providers. Record the signature algorithm, key type, key size, and expiration date for each certificate.

Sources to inventory:

Internal PKI / Certificate Authority
Cloud provider certificate managers (AWS ACM, Azure Key Vault, GCP Certificate Manager)
CDN certificates (Cloudflare, Akamai, Fastly)
Code signing certificates
Document signing certificates
Client certificates (mutual TLS)
S/MIME certificates

Step 4: Configuration Audit

Review configuration files for VPNs, SSH servers, databases, and message brokers. These often contain explicit cipher suite configurations that are not visible through network scanning.

# Example: SSH server configuration with quantum-vulnerable algorithms
/etc/ssh/sshd_config
HostKeyAlgorithms ssh-rsa,ecdsa-sha2-nistp256
KexAlgorithms diffie-hellman-group14-sha256,ecdh-sha2-nistp256
Target state with PQC support:
HostKeyAlgorithms ml-dsa-65@openssh.com,ssh-ed25519
KexAlgorithms mlkem768x25519-sha256@openssh.com,curve25519-sha256

Step 5: Export to CycloneDX

Normalize all findings into CycloneDX 1.7 format. For each asset:

Record the algorithm, key size, and protocol details
Classify by quantum safety status (safe, vulnerable, unknown)
Tag with the recommended migration target (e.g., RSA-2048 -> ML-KEM-768)
Map dependencies to applications and services

Step 6: Establish Baselines and Monitor

Set your initial CBOM as the baseline. Schedule regular scans (weekly or with each deployment) to detect drift, new vulnerabilities, and migration progress. Track key metrics over time:

Total quantum-vulnerable assets (should decrease)
Percentage of endpoints using hybrid PQC key exchange (should increase)
Number of certificates issued with PQC signature algorithms (should increase)
Mean time to remediate newly discovered quantum-vulnerable assets

Common Mistakes to Avoid

Inventorying only TLS. TLS is the most visible use of cryptography, but it is far from the only one. Application-layer encryption, JWT signing, S/MIME, VPN tunnels, database encryption, and disk encryption all have cryptographic dependencies that need to be cataloged.

Ignoring third-party dependencies. Your application might not call RSA directly, but the library it depends on might. SBOM composition analysis tools can identify cryptographic libraries in your dependency tree.

Treating it as a one-time project. A CBOM that is generated once and filed away provides no ongoing value. Cryptographic drift happens continuously, and your CBOM must be updated continuously to remain useful.

Not connecting to risk metrics. A CBOM is most valuable when it feeds into risk scoring and migration tracking. Connect it to your HNDL Score, your Mosca Inequality calculations, and your migration project management. Raw inventory data without risk context is just a spreadsheet.

The Bottom Line

A CBOM is not a nice-to-have -- it is the foundation of every credible post-quantum migration plan. Without it, you are guessing at your exposure. With it, you have the data to prioritize, budget, and execute a migration that protects your organization before quantum computers arrive.

The organizations that will navigate the post-quantum transition smoothly are the ones that know exactly what they have, exactly what needs to change, and exactly how to track their progress. That starts with a CBOM.

Start by inventorying what you have. Use Q by Wentzel's algorithm reference to classify each asset's quantum safety status. Calculate your HNDL Score to quantify the urgency. The rest follows from there.