Why a Cryptography Bill of Materials (CBOM) is Essential Now More Than Ever: Enterprise PQC Guidance

We live in an increasingly interconnected world where digital security is paramount. Every click, every transaction, and every piece of data relies on cryptography. Yet, as our software systems grow increasingly complex and powerful new computing technologies emerge, truly understanding and managing all the hidden cryptographic pieces within our digital tools has become a significant challenge. If you cannot see it, you cannot truly protect it. A Cryptography Bill of Materials (CBOM) is the answer: it is a machine-readable inventory that maps every cryptographic algorithm, key size, certificate, protocol, and library across your systems, providing the visibility required for quantum risk assessment, regulatory compliance, and PQC migration. Two major regulations, DORA Article 9 and PCI DSS Requirement 12.3.3, have required documented cryptographic inventories as enforceable obligations since early 2025. The recommended action: build a continuously maintained CBOM now, because PQC migration cannot begin without knowing what quantum-vulnerable algorithms are deployed and where. For the cryptographic discovery methodology that feeds a CBOM, see You Can’t Secure What You Can’t See.

Quick Answer: What Is a CBOM and Why Is It Required Now?

A CBOM (Cryptography Bill of Materials) is a structured, machine-readable inventory of every cryptographic asset in an organization’s environment: algorithms, key sizes, certificates, protocols, and library implementations. It is required now because DORA Article 9.2 has mandated a documented cryptographic asset register since January 17, 2025; PCI DSS Requirement 12.3.3 has mandated a continuously maintained cipher suite inventory since March 31, 2025; and PQC migration under NIST FIPS 203, 204, 205 and CNSA 2.0 deadlines cannot be planned without it. The CBOM is the foundation that every compliance requirement and every migration initiative depends on. For PQC migration context, see Essential Steps for Post-Quantum Cryptography Readiness.

What Exactly Is a CBOM?

You would not buy a complex product without knowing what is inside. A CBOM applies the same principle to your software’s security. It is a highly detailed, machine-readable inventory that meticulously maps out every cryptographic component embedded within your applications, systems, or products. It does not just broadly state that encryption is in use. Instead, a CBOM provides specifics such as:

• The Exact Algorithms and Their Specifics: This means identifying not just AES, but its precise variant, such as AES-128-GCM. This level of detail distinguishes quantum-safe algorithms from quantum-vulnerable ones, and correctly implemented algorithms from weakly configured ones.
• Key Strengths: Knowing the strength of your keys (for example, a 2048-bit RSA key) directly indicates the resilience of your encryption against both current and quantum-capable adversaries. RSA-2048 is designated for deprecation by 2030 under NIST IR 8547.
• Your Digital Credentials: A CBOM lists all digital certificates, detailing who issued them, their validity periods, the algorithms they use, and their format. This enables proactive expiration monitoring and shadow certificate identification via Certificate Transparency logs.
• Security Protocols and Rules: It specifies the secure communication protocols your software follows, such as TLS 1.3, and the specific cipher suites active for each connection. A server configured to support TLS 1.3 may still negotiate TLS 1.1 with legacy endpoints; the CBOM captures what is actually negotiated, not just what is configured.
• Quantum Vulnerability Status: Each CBOM entry should carry a quantum vulnerability rating tied to whether the algorithm is broken by Shor’s algorithm (RSA, ECC, DH all are), resistant to known quantum attacks (AES-256, SHA-3, ML-KEM are), or under review (algorithms still under NIST evaluation).
• Ownership and Compliance Mapping: Each asset should map to an owner or team responsible for remediation and to the regulatory requirements that govern it, enabling DORA Article 9, PCI DSS 12.3.3, and CNSA 2.0 compliance evidence to be generated directly from the inventory.

This granular detail provides unparalleled transparency. It allows you to swiftly identify outdated or weakly configured security components and ensure your implementations meet current standards. It is about proactive security management, not reacting to incidents after they occur.

CBOM vs SBOM: What Is the Difference?

A CBOM is a specialized extension of an SBOM (Software Bill of Materials), not a replacement for it. An SBOM provides a high-level inventory of all software components in an application or product. A CBOM adds the cryptographic layer: rather than simply listing that a component is present, it documents the specific algorithm and parameter set the component uses, the key size and key type, the certificate details, and the security protocol version and cipher suite configuration. For the full comparison, see How CBOM Differs from SBOM.

Attribute	SBOM	CBOM
Scope	All software components	All cryptographic components specifically
Granularity	Component name, version, license, dependency tree	Algorithm, parameter set, key size, certificate details, protocol version, cipher suite
Quantum relevance	Does not address quantum vulnerability	Includes quantum vulnerability status per asset
Compliance use	NTIA SBOM minimum requirements, Executive Order 14028	DORA Article 9, PCI DSS 12.3.3, CNSA 2.0, NIST IR 8547
PQC migration use	Cannot drive PQC prioritization	Required foundation for PQC migration planning

Why a CBOM Is Essential for Your Organization Today

The need for a CBOM is growing rapidly, driven by significant shifts in the digital security environment:

1. Compliance Is Already Mandatory

   Two major regulations require documented cryptographic inventories as enforceable obligations. DORA Article 9.2 requires financial entities to maintain an up-to-date register of all information assets including cryptographic assets for all ICT systems supporting critical or important functions. DORA Article 7.4 further requires the register to include all digital certificates and the devices on which they are stored. Both provisions have been enforceable since January 17, 2025. PCI DSS Requirement 12.3.3 requires a documented, continuously maintained inventory of all cryptographic cipher suites and protocols in use, with a business justification per entry, active viability monitoring, and a documented response strategy for identified cryptographic vulnerabilities. This requirement has been enforceable since March 31, 2025. An organization that cannot produce the required documentation during a supervisory review has a gap in an active enforcement obligation, not a future roadmap item.

2. PQC Migration Requires It

   NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 designates RSA-2048 and ECC P-256 for deprecation by 2030 and full disallowance by 2035. NSA CNSA 2.0 sets binding deadlines for National Security Systems starting January 2027. Knowing which algorithms to migrate to is only half the problem. The other half is knowing which systems are running RSA, ECDH, ECDSA, and Diffie-Hellman, in what context, and with what hardware and software dependencies. A CBOM provides that mapping. PQC migration planning without a CBOM is guesswork, and migration projects consistently take twice as long as planned when started without a baseline inventory.

3. The Harvest Now, Decrypt Later Threat Is Active Today

   Attackers are capturing encrypted data today and archiving it until a cryptographically relevant quantum computer arrives to decrypt it. Any data that must remain confidential beyond the point at which a capable quantum computer could realistically exist is already at risk. A CBOM provides the precise map needed to identify which systems are carrying Harvest Now, Decrypt Later (HNDL) exposure: those transmitting data with long-term confidentiality requirements encrypted under RSA or ECDH. Those systems require earliest migration. Without a CBOM, there is no systematic way to identify them.

4. Cryptographic Agility Requires Visibility

   The cybersecurity environment is dynamic. New vulnerabilities emerge, and stronger algorithms are developed. Cryptographic agility, the ability to quickly and efficiently change cryptographic algorithms, is vital. A comprehensive CBOM makes it far easier and faster to adapt your systems when new threats or updated standards arise. NIST is still finalizing FIPS 206 (FN-DSA based on FALCON) and HQC. An organization without a CBOM cannot assess the impact of a new algorithm addition or a standard revision on its environment.

5. Accelerated Incident Response

   Imagine a critical security flaw is discovered in a widely used encryption algorithm. Without a CBOM, identifying whether and where you are using that vulnerable algorithm could take days or even weeks of manual searching. With a CBOM, you can immediately query the affected algorithm, return every system that uses it along with the owner and compliance context, assess the scope of exposure, and begin remediation in priority order. The same capability applies to certificate expiration emergencies: a CBOM that tracks certificate validity periods and owners eliminates the reactive fire drills that certificate outages cause at enterprise scale.

CBOM and Current Standards: What Your Inventory Must Track

A CBOM is not useful as a generic component list. It must be structured to support the specific compliance and migration decisions that depend on it. The following table maps the current standards and deadlines that a CBOM must enable:

Standard / Requirement	What the CBOM must track	Deadline / Status
NIST IR 8547 (RSA/ECC deprecation)	Every RSA and ECC key and certificate; key size and expiration date	Deprecation by 2030; disallowance by 2035
FIPS 203 (ML-KEM)	Which key exchange operations currently use RSA or ECDH and must migrate to ML-KEM	Finalized August 2024
FIPS 204 (ML-DSA)	Which signing operations currently use RSA or ECDSA and must migrate to ML-DSA	Finalized August 2024
CNSA 2.0 (NSS supply chain)	All asymmetric algorithms in NSS-adjacent systems; compliance against CNSA 2.0 algorithm requirements	New acquisitions: January 2027; exclusive use: 2030-2033
DORA Article 9.2 and 7.4	All cryptographic assets including certificates and the devices that hold them for ICT systems in scope	Enforceable since January 17, 2025
PCI DSS Requirement 12.3.3	All cipher suites and protocols with business justification, viability monitoring, and response strategy	Enforceable since March 31, 2025

Building and Governing Your CBOM: Key Steps

Implementing a CBOM is a proactive and strategic step. Building one requires discovery across multiple layers, because no single tool surfaces all cryptographic assets:

• Passive network traffic analysis: reveals what cryptographic protocols are actually being negotiated in production traffic, not just what configurations say should be available.
• Static code analysis: finds hardcoded key values, deprecated library imports, and algorithm choices fixed in application logic that cannot be changed without a code change and redeployment.
• Certificate scanning including CT log queries: surfaces every certificate ever issued for your domains, including shadow certificates that were never registered in your managed certificate inventory.
• Runtime and binary analysis: assesses cryptographic posture of vendor appliances, OT systems, and firmware where no source code is available.
• Manual investigation: captures custom protocols, proprietary encryption schemes, and undocumented integrations that automated tools miss.

In essence, a CBOM is an advanced, specialized version of a standard software component list. While a general list (often called an SBOM) gives you a good overview, a CBOM adds the crucial, deep layer of cryptographic detail. It provides the X-ray vision for your digital security. The CBOM must be continuously maintained, not produced as a one-time snapshot. PCI DSS Requirement 12.3.3 explicitly requires continuous maintenance. DORA Article 9.2 requires an up-to-date register. Both requirements are satisfied by a continuously maintained CBOM and are not satisfied by a point-in-time assessment that ages without update.

How Encryption Consulting Can Help

We are a globally recognized leader in applied cryptography, offering PQC Advisory Services designed to help organizations gain full visibility and control over their cryptographic environment. Our services are built on a structured, end-to-end approach:

• PQC Assessment: We perform cryptographic discovery and inventory to locate all your keys, certificates, algorithms, and dependencies across all environments. This delivers a clear quantum threat assessment and a quantum readiness gap analysis that highlights your vulnerabilities, urgent priorities, and compliance gaps against DORA, PCI DSS 12.3.3, and CNSA 2.0.
• CBOM Secure: CBOM Secure is Encryption Consulting’s automated cryptographic discovery and inventory platform. It executes all five discovery layers (passive network, static code, certificate scanning, runtime analysis, and manual investigation) as a single integrated capability. Every CBOM entry is automatically enriched with quantum vulnerability status, ownership routing, and regulatory compliance gap tagging, so your team is always working from a prioritized, contextualized picture of the estate.
• PQC Strategy and Roadmap: Based on your inventory data, we develop a custom, phased migration strategy aligned with NIST standards and CNSA 2.0 deadlines, incorporating a cryptographic agility framework to prepare you for future changes.
• Vendor Evaluation and PoC: We help you identify, evaluate, and validate PQC and cryptographic management solutions through rigorous proof-of-concepts to ensure they fit your critical systems.
• Implementation and Integration: We seamlessly integrate PQC-ready algorithms and hybrid cryptographic models into your PKI and security ecosystem for a secure, disruption-free transition.

With our deep expertise and proven framework, you can build, assess, and optimize your cryptographic infrastructure, ensuring both immediate compliance and long-term readiness against quantum threats.

Conclusion

A CBOM is no longer optional; it is a legal requirement under DORA and PCI DSS, and the technical prerequisite for PQC migration under NIST and CNSA 2.0 deadlines. By providing a transparent, detailed inventory of your cryptographic assets, a CBOM empowers you to identify weaknesses, meet regulatory expectations, prioritize HNDL-exposed systems for earliest migration, and strategically plan for a secure future. The organizations that build their CBOM now will have the visibility to execute PQC migration without disruption. Those that wait will find themselves building the inventory and executing the migration simultaneously under regulatory pressure, compressing a multi-year program into an insufficient window. For the cryptographic discovery methodology that builds a CBOM, see You Can’t Secure What You Can’t See. For the cryptographic inventory as a strategic foundation, see Why Your Cryptographic Inventory Is Your Master Key.

Frequently Asked Questions

What is a CBOM and how does it differ from an SBOM?

A CBOM (Cryptography Bill of Materials) is a machine-readable inventory that identifies every cryptographic algorithm, key size, certificate, protocol, and library in use. An SBOM (Software Bill of Materials) provides a high-level inventory of all software components. The CBOM adds the cryptographic layer: rather than listing a component, it documents the specific algorithm and parameter set, key size, certificate details, and security protocol version. A CBOM is a specialized extension of an SBOM that provides the cryptographic depth needed for quantum risk assessment, compliance documentation, and PQC migration planning.

What compliance regulations currently require a cryptographic inventory?

DORA Article 9.2 has required financial entities to maintain a documented cryptographic asset register since January 17, 2025. DORA Article 7.4 requires the register to include all digital certificates and the devices that hold them. PCI DSS Requirement 12.3.3 has required a continuously maintained cipher suite inventory with business justification and viability monitoring since March 31, 2025. Both are enforceable obligations today, not future roadmap items.

Why is a CBOM essential for post-quantum cryptography migration?

A CBOM is essential for PQC migration because you cannot migrate what you have not mapped. NIST finalized FIPS 203, 204, and 205 in August 2024, but knowing which algorithms to migrate to is only half the problem. The other half is knowing which systems are running RSA, ECDH, ECDSA, and Diffie-Hellman, and in what context, to prioritize them by quantum risk exposure and HNDL sensitivity. Without a CBOM, migration planning is guesswork.

What should a CBOM entry contain for each cryptographic asset?

A complete CBOM entry should contain: the exact algorithm and parameter set; the key size and key type; for certificates, the issuer, validity period, subject, and algorithm; the security protocol version and cipher suite configuration; the system or application where the asset is deployed; the owner or team responsible; the quantum vulnerability status; the compliance relevance; and any existing migration plan or remediation status.

How does a CBOM support incident response?

When a critical vulnerability is discovered in a cryptographic algorithm, a CBOM allows the affected algorithm to be queried instantly, returning every system that uses it along with the owner and business context. Without a CBOM, the same search takes days or weeks of manual effort. The same capability applies to certificate expiration emergencies: a CBOM that tracks certificate validity periods and owners eliminates the reactive fire drills that certificate outages cause at enterprise scale.

What is the difference between a static CBOM and a continuously maintained CBOM?

A static CBOM is a point-in-time snapshot that becomes stale as the environment changes. A continuously maintained CBOM integrates with automated discovery tooling, version control systems, and certificate management infrastructure to update as the environment evolves. PCI DSS Requirement 12.3.3 explicitly requires a continuously maintained inventory. DORA Article 9.2 requires an up-to-date register. Both requirements are satisfied by a continuously maintained CBOM and not by a point-in-time assessment.