Cryptographic Bill of Materials (CBOM): Architectural Overview, Standards & Enterprise Implementations

• Sunday November 8, 2026

Cryptographic Bill of Materials (CBOM): Architectural Overview, Standards & Enterprise Implementations

Comprehensive Technical Guide  |  September 2026

1. Overview & Policy Imperative

In the United States and globally, regulatory mandates emphasize comprehensive cryptographic inventories as an essential prerequisite for migrating to Post-Quantum Cryptography (PQC). On May 4, 2022, the White House issued the National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems (NSM-10). This landmark directive requires federal agencies and enterprise partners to transition toward zero-trust cybersecurity principles, driven by the realization that quantum computing will compromise widely deployed public-key primitives.

1.1 Definition of CBOM

As defined by OMB Memorandum M-23-02, a Cryptographic Bill of Materials (CBOM) is a structured inventory of software or hardware implementations of cryptographic algorithms that provide one or more key security services:

• Key Creation & Exchange: Algorithms and protocols establishing symmetric secrets (e.g., ECDH, RSA-KEM, ML-KEM).
• Encrypted Connections: Secure communication primitives across network interfaces (e.g., TLS 1.3, IPsec, SSH, MACsec).
• Digital Signatures: Creation and validation of digital signatures for identity verification and software integrity (e.g., RSA, ECDSA, ML-DSA, SLH-DSA).

A complete CBOM enumerates algorithms (including key sizes, modes, padding, and parameters), cryptographic libraries and modules, X.509 digital certificates, keys and related material, and active network protocols, mapping their precise dependencies to calling software/hardware components.

1.2 Quantum Readiness & Relation to SBOM

Because large-scale quantum computers running Shor’s algorithm will breach classical public-key cryptography (RSA, ECC, Diffie-Hellman), organizations face multi-year migration roadmaps. CBOMs enable this migration by identifying quantum-vulnerable primitives, prioritizing high-impact systems, and tracking replacement implementations over time.

While complementary, a CBOM is functionally distinct from a Software Bill of Materials (SBOM):

• Software Bill of Materials (SBOM): Lists general software components and their specific version strings (e.g., OpenSSL v3.0.8).
• Cryptographic Bill of Materials (CBOM): Focuses explicitly on the cryptographic capabilities enabled within those components—identifying exact algorithms, key lengths, parameter sets, X.509 certificate chains, and operational runtime configurations (e.g., RSA-2048, ECDH P-256, AES-256-GCM, FIPS certification status, and quantum resistance levels).

1.3 CERT-In National Guidelines

Recognizing the systemic necessity of cryptographic visibility, India’s national cyber authority, CERT-In (Indian Computer Emergency Response Team), published technical guidelines for formal CBOM adoption alongside SBOM, AIBOM, HBOM, and QBOM standards.

2. CycloneDX 1.6 Standard Specification

OWASP CycloneDX Version 1.6 (released in 2024) formalized the industry standard for machine-readable CBOM structures. Supporting both JSON and XML serialization, CycloneDX provides an extensible data model compatible with existing SBOM vulnerability workflows without licensing restrictions.

2.1 Document Top-Level Schema

A standard CycloneDX CBOM JSON/XML payload incorporates the following required and recommended structural fields:

2.2 Primary Cryptographic Asset Types

CycloneDX 1.6 defines five primary asset classes under component type crypto-asset:

• Algorithm: Primitive details including variant, key size, mode, padding, classical security level, and NIST quantum level.
• Certificate: X.509 metadata (Subject, Issuer, Validity boundaries, Signature Algorithm Ref, Subject Public Key Ref).
• Protocol: Protocol type (TLS, IPsec, SSH), protocol version, configured ciphersuites, and key exchange references.
• Related Cryptographic Material: Keys (public, private, secret), IVs, nonces, seeds, salts, tags, and shared secrets.
• Cryptographic Implementation: Software libraries (e.g., OpenSSL, BoringSSL) or hardware security modules (HSM/TPM).

2.3 NIST Quantum Security Level Mapping

CycloneDX represents quantum vulnerability via the nistQuantumSecurityLevel attribute (integer 0–5):

3. Enterprise Discovery & Management Tools

Automated scanning tools digest raw enterprise environments to generate normalized CycloneDX CBOM outputs:

• IBM CBOMkit: Open-source suite maintained under the Post-Quantum Cryptography Alliance (PQCA). Features CBOMkit Hyperion for scanning code repositories (Java/Python) and CBOMkit Theia for detecting cryptographic modules inside container images.
• QCecuring: Enterprise-grade active and passive discovery platform across distributed infrastructure. Scans C/C++ code, Active Directory/LDAP cert stores, HSMs, network devices, and cloud key stores (AWS ACM, Azure Key Vault). Automates quantum risk scoring and CycloneDX output generation.
• Cryptagion: Focuses heavily on European regulatory compliance (DORA, NIS2, EU Cyber Resilience Act). Performs on-premise static code analysis and live TLS handshake scanning, generating 0–100 quantum risk scores, board-level PDFs, 4-wave migration roadmaps, and CI/CD pull-request blocking rules.

4. Firewall Implementations & Migration Architectures

Network firewalls serve a dual role in CBOM architecture: auditing internal cryptographic configurations and acting as network sensors monitoring inline transit security.

4.1 NIST Post-Quantum Standards & Primary Mechanisms

NIST FIPS standards define three primary post-quantum algorithms:

• ML-KEM (FIPS 203): Module-Lattice-Based Key-Encapsulation Mechanism replacing classical Diffie-Hellman / ECDH key exchanges.
• ML-DSA (FIPS 204): Module-Lattice-Based Digital Signature Algorithm replacing RSA and ECDSA signatures.
• SLH-DSA (FIPS 205): Stateless Hash-Based Digital Signature Algorithm providing a non-lattice fallback standard.

4.2 Cisco Secure Firewall PQC Roadmap

Cisco has announced a structured migration roadmap across Secure Firewall Threat Defense (FTD) 10.5 and ASA 9.25:

• Pre-Shared Key Mixing in IKEv2 (RFC 8784): Incorporate Post-Quantum Pre-Shared Keys (PPK) into IKEv2 key derivation (Available since ASA 9.18).
• Multiple Key Exchanges in IKEv2 (RFC 9242 / RFC 9370): Hybrid key exchange combining classical ECDH with post-quantum algorithms (Available since ASA 9.19).
• Secure Key Integration Protocol (SKIP): Draft RFC protocol for securely importing third-party distributed keys / Quantum Key Distribution (QKD) devices into FTD 10.5 / ASA 9.25.
• Native ML-KEM & ML-DSA: ML-KEM key exchange arriving late 2026 (FTD 10.5/ASA 9.25); ML-DSA & SLH-DSA signing targeted for H2 2027 (FTD/ASA 11.0). Static Device CBOM feature is currently in beta.

4.3 Palo Alto Networks Live / Real-Time CBOM Architecture

Palo Alto Networks utilizes Next-Generation Firewalls (NGFWs) and Prisma Access cloud security tools as active network sensors:

• Telemetry Ingestion: NGFWs, Prisma Access, SSL/TLS decryption logs, and tunnel inspection logs stream live traffic telemetry to the Strata Logging Service.
• Real-Time CBOM Assembly: Cryptographic analysis engines passively build a Live CBOM mapping active transit cipher suites, certificate chains, and tunnel parameters.
• Exposure & Risk Assessment: Identifies active sessions vulnerable to “Harvest Now, Decrypt Later” attacks or using deprecated ciphers.
• Cipher Translation Proxy: PAN-OS 12.1+ integrates cipher translation proxies to dynamically terminate weak ciphers and enforce post-quantum compliant tunnels inline.

5. Static vs. Dynamic CBOM Implementation Paradigms

Implementing a comprehensive CBOM posture across network environments requires combining two distinct paradigms:

• Static (Device) CBOM: Audits internal software, firmware binaries, and static configuration files on the device itself. It generates a deterministic inventory of native cryptographic libraries (e.g., embedded OpenSSL builds) and hardcoded key materials. (Example: Cisco’s upcoming device CBOM beta feature).
• Dynamic (Live / Real-Time) CBOM: Deploys inline deep packet inspection (DPI) and decryption logging engines to passively audit network traffic in motion. This dynamically discovers active cipher negotiations, ephemeral keys, and runtime protocol compliance across transient connections. (Example: Palo Alto Networks Live CBOM architecture).

5.1 Multilayer Information Sources

To construct a complete enterprise CBOM, telemetry must be gathered across four core architectural layers:

• Build-Time / Static Code: Static analysis of source repos discovering direct function calls (e.g., EVP_SHA256() in C/C++).
• Configuration Files: Parsing administrative definitions (e.g., TLS min version 1.3, DH group 20, IPsec AES-256 settings).
• Certificate & Key Stores: Inspecting X.509 cert files, PEM stores, and HSM key attributes (e.g., RSA-2048, SHA-256 signature).
• Runtime Subsystem State: Active dynamic state monitoring (e.g., active IKEv2 hybrid sessions using ML-KEM-768 + X25519).

References & Key Standards

[1] White House, “National Security Memorandum on Promoting United States Leadership in Quantum Computing While Mitigating Risks to Vulnerable Cryptographic Systems (NSM-10),” May 2022.

[2] CERT-In, “Technical Guidelines on SBOM, QBOM, CBOM, AIBOM & HBOM Version 2.0,” Govt of India.

[3] OWASP CycloneDX, “Authoritative Guide to Cryptographic Bill of Materials (CBOM),” CycloneDX v1.6 Specification, 2024.

[4] Post-Quantum Cryptography Alliance (PQCA), “CBOMkit: Essentials of Cryptographic Bill of Materials,” GitHub Repository.

[5] NIST, “FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA) Post-Quantum Cryptography Standards,” 2024.

[6] Cisco Systems, “Cisco Secure Firewall Post-Quantum Cryptography Migration Roadmap,” Technical Whitepaper, 2026.

[7] Palo Alto Networks, “The Cryptographic Reset: Building Future-Ready Trust and Resilience with PAN-OS Live CBOM,” 2026.