From Discovery to Action: How a Cryptographic Bill of Materials Turns Inventory into Intelligence

This is Part 2 of a two-part series. Part 1 covers the cryptographic discovery problem and the five-layer framework for building a complete inventory.

In Part 1, we established why cryptographic discovery requires five distinct layers, why existing tools leave structural blind spots, and why the compliance deadlines under DORA and PCI DSS 4.0 are not approaching; they are already here. But discovery on its own is not enough.

The output of a cryptographic inventory is only as useful as what you do with it. Most teams that reach this point fall into one of two traps: they treat the findings as a list to be triaged in a spreadsheet, or they wait until the full inventory is complete before starting any remediation. Both approaches create the same problem; they delay the point at which discovery actually translates into reduced risk.

This blog covers the second half of the challenge: what a Cryptographic Bill of Materials (CBOM) is, why it is fundamentally different from a findings list, and how to use it to drive the generation of compliance evidence, risk prioritization, and post-quantum migration planning.

What a CBOM Is, and What It Is Not

The output of cryptographic discovery is not a list of problems to be managed in a spreadsheet. It is a CBOM, a living, continuously maintained, queryable data set that serves as the single source of truth for every cryptographic asset across your estate.

The distinction between a CBOM and a findings list is not semantic. A findings list tells you what is wrong. A CBOM tells you what exists, who owns it, what risk it carries, what data it protects, and what needs to happen to it. And it tells you all of that continuously, not as a point-in-time snapshot that is already aging from the moment it is produced.

CycloneDX ECMA-424 is the established standard format for CBOMs. It has been adopted by OWASP, referenced in NIST NCCoE post-quantum migration guidance, and used as the basis for Santander’s open-source CBOM data model. Each entry in a properly structured CBOM captures:

• Algorithm identifier and OID
• Key size
• Protocol context
• Library name and version
• Certificate reference
• Data sensitivity classification
• Quantum vulnerability status
• Migration status
• Named owner
• Vendor dependency flag

That last cluster of fields, data sensitivity classification, quantum vulnerability status, named owner, and vendor dependency, is precisely what makes a CBOM entry actionable rather than merely informational. Consider the difference:

A finding that says RSA-2048 in a TLS context is an observation.

A finding that says RSA-2048 in a TLS context on a payment processing API handling long-retention PAN data, owned by the payments infrastructure team, with a vendor HSM dependency whose FIPS 203 roadmap is Q3 2026, is a work item, with a known owner, a defined risk context, and a concrete constraint on when remediation can realistically begin.

One entry sits in a backlog. The other drives a plan.

The Four Risk Dimensions That Drive Prioritization

Not all cryptographic vulnerabilities carry the same urgency, and a CBOM that does not reflect risk context will generate an undifferentiated list of findings that overwhelms remediation teams and leads to the wrong items being prioritized first.

Effective risk scoring across your CBOM should account for four distinct dimensions:

1. Harvest Now, Decrypt Later (HNDL) exposure: Adversaries are actively collecting encrypted traffic today to decrypt once capable quantum computers arrive, a documented strategy, not a theoretical risk. Data most at risk stays sensitive when that hardware lands: long-retention financial records, protected health information, government communications, and trade secrets. Systems protecting it face a materially shorter remediation window than those handling transient session data.
2. Time to No Longer Feasible (TNFL): How long before the scheme protecting an asset becomes practically breakable? RSA-2048 estimates run 10–15 years under optimistic quantum timelines, narrowing as hardware advances. Enterprise migrations routinely take three to five years for any complex programme. The gap between TNFL and migration time is your actual risk window, and it is shrinking.
3. Regulatory exposure: DORA, PCI DSS 4.0, and NIS2 each set compliance deadlines independent of the quantum timeline; a deprecated cipher suite on a payment processing API carries regulatory risk today, regardless of when quantum becomes a practical threat. Tag CBOM entries against specific regulatory requirements so compliance gaps stay visible as a distinct dimension alongside the underlying technical vulnerability.
4. Remediation feasibility: A vulnerability on a system with a vendor HSM dependency lacking FIPS 203, 204, or 205 support cannot be remediated until the vendor ships it. That constraint belongs in the CBOM entry alongside the finding, because it defines the earliest possible remediation start date and must feed directly into migration timeline planning.

Risk scoring that accounts for all four dimensions produces a prioritized, sequenced remediation queue, not just an inventory of everything that eventually needs to change, but a plan that reflects what can actually be done now, what is blocked on external dependencies, and what carries the most urgent HNDL or regulatory exposure.

How a CBOM Supports Compliance Evidence Generation

DORA Article 7.4 and PCI DSS Requirement 12.3.3 both mandates documented, continuously maintained cryptographic inventories. Critically, the compliance evidence obligation is not a one-time audit deliverable; it is an ongoing requirement that must reflect the estate’s current state at any point in time.

An organization that assembles compliance evidence manually ahead of each audit cycle carries two structural liabilities. First, the manual assembly process consumes time that most security teams do not have available. Second, the resulting documentation reflects a point-in-time state that may already be stale by the time it reaches the reviewer.

A CBOM structured against the CycloneDX ECMA-424 schema eliminates both problems by enabling compliance-ready output generation on demand:

• DORA Article 7.4 certificate register: Every certificate entry in the CBOM, with ownership, issuance date, expiration date, issuing CA, and associated ICT asset, updated continuously as new certificates are discovered through CT log monitoring and certificate scanning.
• PCI DSS 12.3.3 cipher suite inventory: Every algorithm and protocol entry in the CBOM, with per-entry business justification, last-reviewed date, and documented response status for any flagged vulnerabilities, ready for examiner review without manual pre-assembly.

The practical implication for audit readiness is significant: instead of a multi-week evidence collection effort before each review cycle, compliance evidence becomes a query against the current, continuously maintained CBOM state. The operational burden shifts from assembly to maintenance, and, when done correctly, maintenance is a far lighter ongoing lift.

Using the CBOM to Drive PQC Migration Planning

Post-quantum migration is not a single project with a start date and an end date. It is a portfolio of interdependent remediation workstreams, each constrained by different factors, vendor delivery timelines, application dependency chains, HSM upgrade cycles, regulatory deadlines, and the HNDL exposure window of the data being protected.

Without a CBOM, PQC migration planning is largely an exercise in educated guessing about scope, timeline, and dependency chains. With one, the migration plan can be grounded in actual system states rather than assumptions derived from incomplete asset records.

Three planning inputs that flow directly from CBOM data are worth calling out specifically:

• Vendor dependency mapping: The Applied Quantum PQC Migration Framework identifies vendor dependency as the longest segment on the critical path for most enterprise PQC migration programs. If a vendor’s FIPS 203, 204, or 205 GA date is 18 months out, dependent systems cannot migrate until the vendor ships, no matter how much internal work you complete. Every month of delay in opening that conversation pushes the far end of your timeline out by a month. CBOM entries flagged with vendor dependency give you the exact list of vendors to engage before formal planning begins.
• Application-level scope quantification: Layer 2 static analysis findings, aggregated across the CBOM, give you the full count of deprecated cryptographic calls in your codebase: hashlib.sha1() calls, RSA key generation with undersized parameters, and hardcoded keys embedded in application logic. Each is a code change, build, test, and deployment. Knowing the count before committing to a timeline is the difference between a realistic plan and one repeatedly revised as scope becomes clear.
• HNDL triage: Not all workstreams carry the same urgency, and migrating everything at once is rarely feasible. CBOM entries tagged with data sensitivity and quantum vulnerability status support a triage pass that separates systems protecting long-retention sensitive data, those with active HNDL exposure, and those driven mainly by regulatory deadlines. That distinction is critical for sequencing when capacity and vendor timelines constrain what can run in parallel.

The CBOM Is Not a deliverable, It’s a Capability

One of the most consequential mistakes in cryptographic inventory programs is treating the CBOM as a project deliverable: something to be built, signed off on, and handed over. It is not. As the Applied Quantum PQC Migration Framework states directly, continuous discovery is a prerequisite for crypto-agility.

An organization without current visibility into its cryptographic estate cannot verify that algorithm changes have been correctly applied. It cannot detect when systems drift from the intended policy. It cannot respond to a newly disclosed cryptographic vulnerability with any real confidence about the scope of its exposure. And it cannot produce the continuously maintained compliance documentation that DORA and PCI DSS now explicitly require.

The CBOM is not something you build once and archive. It is an ongoing operational capability, a continuously maintained system of record that converts persistent discovery into persistent governance. The initial build effort is substantial. The ongoing maintenance, structured and tooled correctly, is not.

How Encryption Consulting Can Help You Put Your CBOM to Work

Building a CBOM and maintaining it as a living, operational capability requires the right platform: CBOM Secure.

CBOM Secure is designed from the ground up around the principle that discovery and governance must be continuous, not periodic. The platform integrates all five discovery layers, passive network analysis, static code scanning, certificate enumeration, runtime and binary analysis, and manual investigation workflows, into a single, unified CBOM data store. Every entry is automatically enriched with risk scoring across the four dimensions covered in this post: HNDL exposure, TNFL, regulatory gap tagging against DORA, PCI DSS 4.0, and NIS2, and remediation feasibility based on vendor dependency status.

Compliance evidence, the DORA Article 7.4 certificate register, and the PCI DSS 12.3.3 cipher suite inventory with per-entry business justification are generated on demand directly from the current CBOM state. There is no manual pre-assembly before audit cycles. The documentation reflects the estate as it is, not as it was at the last point-in-time snapshot.

CBOM Secure also handles the operational continuity that most inventory programs fail to maintain. As new systems are provisioned, code is deployed, and vendor dependencies shift, the platform continuously updates the CBOM, so your view of the estate never goes stale and your compliance posture never quietly drifts out of alignment between reviews.

What to Do Next

If you are starting from a minimal cryptographic inventory, the practical sequence looks like this:

1. Run a CT log query for your primary domains and compare the results against your certificate management system. Any certificate that appears in CT logs but is absent from your managed inventory is a shadow certificate, live, in regulatory scope, and undocumented. That gap is your most immediate, tangible DORA Article 7.4 finding.
2. Begin Layer 1 and Layer 3 discovery across your managed infrastructure: load balancers, VPN concentrators, reverse proxies. These assets have known owners, are reachable with the tooling you likely already have, and will quickly produce high-value findings.
3. Start building CBOM entries from day one, rather than waiting for comprehensive coverage before doing anything with the data. Risk-score what you have as soon as you have it. Begin remediation on the highest-priority items. Extend discovery coverage in parallel.
4. Identify your strategic vendor dependencies, any vendor-supplied component in your cryptographic estate whose post-quantum upgrade path is unknown or whose FIPS 203/204/205 roadmap has not been formally communicated. Start those conversations immediately. Vendor timelines are outside your control; the only lever you have is when you begin the engagement.
5. Treat the CBOM as a living system, not a project milestone. Assign ownership. Establish a continuous discovery cadence. Connect discovery outputs directly into the CBOM data store so new findings are always visible in context, rather than accumulating in disconnected spreadsheets that no one is responsible for reconciling.

Conclusion

A cryptographic inventory without a governance structure is just a snapshot waiting to go stale. A CBOM without continuous discovery is a document, not a capability. The organizations that treat their cryptographic estate as a living, managed system, rather than a project to be completed and filed, are the ones that will meet their compliance obligations, execute their post-quantum migration on a realistic timeline, and respond to new vulnerabilities with confidence rather than uncertainty.

The SHA-1-to-SHA-256 migration was estimated to take five years. It took more than ten. The post-quantum transition is larger in every dimension, and the compliance obligations are already in force. The window to build this capability before it becomes urgent is narrowing. The organizations that start now, with a governed, continuously maintained CBOM at the center of their cryptographic program, will be ready when it matters most.