Cryptographic Bill of Materials (CBOM): The Complete Guide for 2026

What Is a Cryptographic Bill of Materials (CBOM)?

A Cryptographic Bill of Materials (CBOM) is a structured, machine-readable inventory of all cryptographic assets within an application, system, or organization. It catalogs the algorithms, protocols, certificates, keys, and cryptographic libraries used across your technology stack, providing complete visibility into your cryptographic posture.

Think of it as a detailed manifest — similar to how a Software Bill of Materials (SBOM) enumerates software components, a CBOM enumerates cryptographic components. But while an SBOM tells you what software you’re running, a CBOM tells you how that software protects data.

A comprehensive CBOM includes:

• Algorithms in use: RSA-2048, AES-256-GCM, SHA-256, ECDSA P-256, etc.
• Protocol versions: TLS 1.2, TLS 1.3, SSH v2, IPsec configurations
• Certificates: X.509 certificates, their chains, expiration dates, and key types
• Key material metadata: Key lengths, generation methods, storage locations
• Libraries and implementations: OpenSSL 3.x, BoringSSL, Bouncy Castle, Windows CNG
• Configuration details: Cipher suites, mode of operation, padding schemes

Why CBOM Matters Now

The urgency behind CBOM adoption stems from three converging forces:

1. The quantum computing threat: Cryptographically relevant quantum computers (CRQCs) will break RSA, ECC, and other asymmetric algorithms. Organizations need to know exactly where these vulnerable algorithms exist before they can migrate.

2. Regulatory mandates: CNSA 2.0 requires U.S. National Security Systems to complete quantum-safe migration by 2033. PCI DSS 4.0 mandates cryptographic inventory management. Executive Order 14028 demands software transparency including cryptographic components.

3. Operational complexity: A typical enterprise uses hundreds of cryptographic configurations across thousands of systems. Without a CBOM, you’re operating blind — unable to assess risk, plan migrations, or respond to vulnerabilities like the next Heartbleed.

How CBOM Differs from SBOM

While SBOM and CBOM share a common philosophy of transparency and inventory management, they serve fundamentally different purposes and capture different data.

Aspect	SBOM	CBOM
Focus	Software components and dependencies	Cryptographic assets and configurations
Primary use case	Vulnerability management, license compliance	Quantum readiness, crypto compliance
Contents	Package names, versions, licenses, suppliers	Algorithms, key sizes, protocols, certificates
Standards	CycloneDX, SPDX, SWID	CycloneDX (crypto extensions)
Discovery method	Dependency scanning, manifest analysis	Binary analysis, network inspection, code scanning
Update trigger	New software release or dependency change	Algorithm deprecation, policy change, key rotation
Regulatory drivers	EO 14028, FDA, EU CRA	CNSA 2.0, PCI DSS 4.0, DORA, NIS2

Why SBOM Alone Is Insufficient

An SBOM might tell you that your application uses OpenSSL 3.1.4, but it won’t tell you:

• Which cipher suites are configured
• Whether RSA-2048 or RSA-4096 is being used for key exchange
• How many certificates chain to a quantum-vulnerable root CA
• Whether deprecated algorithms like SHA-1 or 3DES persist in fallback paths
• What the actual cryptographic risk posture looks like

For quantum readiness specifically, an SBOM cannot answer the fundamental question: “Which of our systems will break when quantum computers arrive?” Only a CBOM provides that answer.

The CycloneDX CBOM Standard

The OWASP CycloneDX project introduced formal CBOM support in version 1.6, establishing the first widely-adopted machine-readable format for cryptographic inventories. This built upon earlier cryptographic extensions and formalized the data model.

CycloneDX v1.6 Crypto Components

CycloneDX defines cryptographic components using dedicated types:

{
  "type": "crypto-asset",
  "cryptoProperties": {
    "assetType": "algorithm",
    "algorithmProperties": {
      "primitive": "ae",
      "variant": "AES",
      "parameterSetIdentifier": "256",
      "mode": "gcm",
      "implementationPlatform": "software",
      "certificationLevel": ["fips140-3-l1"]
    }
  }
}

The standard supports these crypto asset types:

• algorithm: Specific cryptographic algorithms with parameters
• certificate: X.509 and other certificate types
• protocol: Cryptographic protocols (TLS, SSH, IPsec)
• related-crypto-material: Keys, IVs, nonces, seeds
• crypto-implementation: Libraries and hardware modules

Quantum Readiness Classification

CycloneDX CBOM supports quantum readiness scoring through algorithm classification:

• quantum-safe: Algorithms resistant to quantum attack (ML-KEM, ML-DSA, SLH-DSA)
• quantum-vulnerable: Algorithms broken by Shor’s algorithm (RSA, ECC, DH)
• unknown: Algorithms requiring further analysis

Cryptographic Discovery Methods

Generating a comprehensive CBOM requires multiple discovery approaches because cryptographic usage is distributed across code, binaries, configurations, and network traffic.

1. Static Code Analysis

Scans source code for cryptographic API calls, library imports, and algorithm references.

Strengths: Catches hardcoded algorithms, finds usage patterns early in development Limitations: Cannot detect runtime crypto selection, misses dynamic configurations

# Example: Static analysis would identify this RSA usage
from cryptography.hazmat.primitives.asymmetric import rsa
private_key = rsa.generate_private_key(
    public_exponent=65537,
    key_size=2048  # Quantum-vulnerable key size detected
)

2. Binary Analysis

Examines compiled applications and libraries to identify cryptographic implementations without access to source code.

Strengths: Works on third-party software, detects compiled-in crypto Limitations: Obfuscation can hamper detection, may produce false positives

3. Network Traffic Inspection

Monitors live network traffic to identify cryptographic protocols and parameters negotiated during connections.

Strengths: Shows actual crypto in production, catches misconfigurations Limitations: Requires network access, cannot inspect encrypted payloads

4. Configuration Scanning

Analyzes system configurations, policy files, and infrastructure-as-code for cryptographic settings.

Strengths: Identifies policy-level crypto decisions, catches drift Limitations: Configuration may differ from runtime behavior

5. Certificate and Key Discovery

Scans certificate stores, key management systems, HSMs, and cloud KMS services to enumerate all certificates and keys.

Strengths: Comprehensive certificate inventory, identifies expiration risks Limitations: Requires privileged access to all key stores

6. Runtime Instrumentation

Instruments running applications to observe actual cryptographic operations in real time.

Strengths: Captures actual behavior, detects runtime algorithm negotiation Limitations: Performance overhead, requires deployment access

Quantum Risk Scoring

A CBOM becomes actionable when combined with quantum risk scoring — the process of assigning risk levels to each cryptographic asset based on its vulnerability to quantum attack.

Risk Factors

Factor	Description	Impact
Algorithm vulnerability	Is this algorithm broken by quantum computers?	Critical
Key size	Larger keys offer marginal time advantage	Moderate
Data sensitivity	Classification level of protected data	High
Data retention period	How long must this data remain confidential?	High
System criticality	Impact of compromise on business operations	High
Remediation complexity	Difficulty of migrating this specific usage	Moderate
HNDL exposure	Is ciphertext being intercepted and stored?	Critical

Scoring Example

Consider an RSA-2048 key used for:

• Protecting classified government communications (high sensitivity)
• Data retained for 25 years (exceeds quantum timeline)
• Core infrastructure system (high criticality)
• Potential nation-state HNDL targeting (high exposure)

This asset receives a critical quantum risk score — migration must be prioritized immediately.

Integration with CBOM

QCecuring CBOM integrates risk scoring directly into the bill of materials, enriching each cryptographic asset with:

• Quantum vulnerability classification
• Composite risk score based on organizational context
• Recommended migration action and timeline
• Mapping to CNSA 2.0 compliance requirements

Compliance Frameworks Requiring CBOM

CNSA 2.0 (NSA Commercial National Security Algorithm Suite)

CNSA 2.0 mandates specific quantum-safe algorithms for National Security Systems:

• Key Encapsulation: ML-KEM-1024 (FIPS 203)
• Digital Signatures: ML-DSA-87 (FIPS 204) for software/firmware, LMS/XMSS for stateful hash-based signatures
• Symmetric Encryption: AES-256
• Hashing: SHA-384 or SHA-512

Key Deadlines:

• January 2027: New system acquisitions must support quantum-safe algorithms
• 2033: Full transition to quantum-safe cryptography for all NSS

Without a CBOM, meeting these deadlines is effectively impossible — you cannot migrate what you haven’t inventoried.

PCI DSS 4.0

PCI DSS 4.0 (Requirement 12.3.3) mandates:

“A cryptographic inventory is maintained, including algorithms, protocols, key strength, cryptographic functions, and key usage periods.”

This is essentially mandating a CBOM for payment card environments. Organizations must maintain current inventories and review them annually.

EU Digital Operational Resilience Act (DORA)

DORA requires financial entities to maintain comprehensive ICT risk management frameworks, explicitly including cryptographic risk assessment and inventory capabilities.

NIS2 Directive

The EU’s NIS2 directive requires essential and important entities to implement appropriate security measures, including cryptographic policies and procedures with full inventory capabilities.

CBOM Tools and Solutions

QCecuring CBOM Platform

QCecuring provides an enterprise-grade CBOM platform that automates cryptographic discovery across complex environments. The platform combines multiple discovery methods — static analysis, binary scanning, network inspection, and certificate discovery — into a unified cryptographic inventory.

Key capabilities:

• Automated discovery across cloud, on-premises, and hybrid environments
• CycloneDX v1.6 compliant CBOM generation
• Integrated quantum risk scoring with CNSA 2.0 alignment
• Continuous monitoring for cryptographic drift
• Policy enforcement and compliance reporting
• Integration with existing security toolchains (SIEM, GRC, vulnerability management)

Organizations deploying QCecuring CBOM gain immediate visibility into their cryptographic posture, enabling data-driven prioritization of post-quantum migration efforts.

IBM CBOMkit

IBM’s open-source CBOMkit focuses on Java application analysis, detecting cryptographic usage through static analysis and generating CycloneDX-compliant CBOMs. It integrates with CI/CD pipelines for continuous crypto monitoring.

Other Tools

• SandboxAQ AQtive Guard: Network-focused crypto discovery with ML-based detection
• InfoSec Global AgileSec: Enterprise crypto management platform
• Crypto4A QxEDGE: Hardware-integrated crypto inventory and migration

Implementing CBOM: A Step-by-Step Approach

Phase 1: Scope Definition (Weeks 1-2)

Define the boundaries of your CBOM initiative:

1. Identify critical systems and data flows
2. Determine which environments to scan (production, development, cloud, on-premises)
3. Establish stakeholder responsibilities (security, engineering, compliance, operations)
4. Define success criteria and reporting requirements

Phase 2: Discovery and Inventory (Weeks 3-8)

Execute cryptographic discovery across your defined scope:

1. Deploy discovery tools (QCecuring CBOM or equivalent)
2. Run static analysis on application codebases
3. Scan network traffic for protocol and cipher suite enumeration
4. Inventory all certificates, keys, and trust stores
5. Analyze infrastructure-as-code and configuration files
6. Document all findings in CycloneDX CBOM format

Phase 3: Risk Assessment (Weeks 9-12)

Evaluate the quantum risk of each discovered asset:

1. Classify algorithms by quantum vulnerability
2. Map data sensitivity levels to cryptographic protections
3. Calculate HNDL exposure for long-lived data
4. Score each asset using your risk methodology
5. Identify critical path items requiring immediate attention

Phase 4: Remediation Planning (Weeks 13-16)

Develop migration plans for vulnerable assets:

1. Prioritize based on risk score and compliance deadlines
2. Identify hybrid deployment opportunities (classical + PQC)
3. Plan algorithm replacements aligned with CNSA 2.0
4. Estimate resource requirements and timelines
5. Define testing and validation procedures

Phase 5: Continuous Monitoring (Ongoing)

Maintain CBOM accuracy over time:

1. Integrate CBOM generation into CI/CD pipelines
2. Configure alerts for new quantum-vulnerable algorithm introductions
3. Track migration progress against compliance deadlines
4. Report posture improvements to leadership
5. Update risk scores as quantum computing timelines evolve

CBOM Best Practices

Automation First

Manual cryptographic inventories are immediately outdated. Automate discovery and CBOM generation to maintain accuracy across rapidly changing environments.

Start with Crown Jewels

Don’t try to inventory everything at once. Begin with systems protecting your most sensitive, longest-lived data — these face the highest HNDL risk.

Integrate with Existing Workflows

CBOM should feed into existing security operations:

• Vulnerability management: Treat quantum-vulnerable crypto as vulnerabilities
• Change management: Require CBOM updates for cryptographic changes
• Compliance: Map CBOM data to regulatory requirements automatically
• Incident response: Use CBOM to assess breach impact on encrypted data

Maintain Context

A list of algorithms alone isn’t actionable. Enrich your CBOM with:

• Business context (what system, what data, what purpose)
• Ownership information (who maintains this, who approves changes)
• Dependency mapping (what breaks if this algorithm changes)
• Migration status (planned, in-progress, complete, verified)

Plan for Evolution

The CBOM standard and quantum threat landscape continue evolving. Design your CBOM processes to accommodate:

• New algorithm approvals from NIST
• Updated CNSA 2.0 guidance
• Emerging regulatory requirements
• New discovery methods and tools

CBOM and the Post-Quantum Migration Connection

CBOM is not just a compliance artifact — it is the operational foundation for successful post-quantum cryptography migration. Here’s how CBOM connects to each phase of the PQC transition:

Phase Connection Map

Migration Phase	CBOM Role
Discovery	CBOM is the output — the comprehensive cryptographic inventory
Risk Assessment	CBOM provides the inputs for quantum risk scoring per asset
Prioritization	Risk-enriched CBOM data drives migration wave assignment
Planning	CBOM identifies dependencies and interrelationships between crypto assets
Execution	CBOM tracks which assets have been migrated vs. remaining
Verification	Updated CBOM confirms no quantum-vulnerable crypto remains

Measuring Migration Progress with CBOM

Organizations use CBOM metrics to track PQC migration progress:

• Quantum-vulnerable percentage: (Vulnerable assets / Total assets) × 100 — should decrease over time
• Risk score reduction: Aggregate quantum risk score declining quarter-over-quarter
• Compliance coverage: Percentage of CNSA 2.0-scoped systems meeting algorithm requirements
• Migration velocity: Rate of assets migrated per month
• Regression detection: New quantum-vulnerable assets introduced (should be zero)

CBOM as Continuous Compliance Evidence

For ongoing compliance with CNSA 2.0, PCI DSS 4.0, and emerging quantum regulations, CBOM serves as living evidence:

• Auditors can query the CBOM to verify algorithm compliance at any point in time
• Historical CBOM versions demonstrate progress toward deadlines
• Automated CBOM generation proves the inventory is current, not stale
• Risk scoring within CBOM shows that prioritization follows a documented methodology

Common CBOM Challenges

Challenge 1: Shadow Cryptography

Developers often implement cryptographic functions without central visibility — hardcoded keys, custom encryption wrappers, or undocumented algorithm choices. Comprehensive scanning (including binary analysis) helps surface these hidden usages.

Challenge 2: Third-Party Black Boxes

Commercial software and SaaS services may use cryptography internally without exposing details. Network inspection and vendor questionnaires help fill these gaps.

Challenge 3: Dynamic Environments

Cloud-native, containerized environments change constantly. CBOM generation must integrate with container registries, orchestration platforms, and infrastructure-as-code to stay current.

Challenge 4: Scale

Large enterprises may have millions of cryptographic assets across thousands of systems. Automated tools like QCecuring CBOM handle this scale through distributed scanning and intelligent aggregation.

Challenge 5: Accuracy vs. Completeness

Balancing false positives (noise) against false negatives (missed crypto) requires tuning discovery tools and validating results iteratively.

Key Takeaways

• CBOM is the foundation of quantum readiness — you cannot migrate cryptography you haven’t inventoried
• SBOM is not sufficient — it tells you about software components but not their cryptographic behaviors
• CycloneDX v1.6 provides the standard — machine-readable, interoperable CBOM format
• Multiple discovery methods are required — no single technique captures all cryptographic usage
• Risk scoring makes CBOM actionable — prioritize migration based on vulnerability, sensitivity, and exposure
• Compliance mandates CBOM — CNSA 2.0, PCI DSS 4.0, DORA, and NIS2 all require cryptographic inventory capabilities
• Automation is essential — manual inventories cannot keep pace with modern infrastructure
• Start now — CNSA 2.0’s January 2027 acquisition gate is approaching fast, and cryptographic discovery takes time
• QCecuring CBOM accelerates the journey — automated discovery, risk scoring, and compliance mapping in a single platform