A CBOM Is Not Enough: Building a Causal Map for Post-Quantum Migration

The first problem in post-quantum cryptography is visibility. Most organizations cannot produce a reliable answer to a deceptively simple question: where does cryptography live across the enterprise?

The answer is rarely contained in one source. Cryptographic evidence is distributed across repositories, cloud accounts, certificate authorities, key-management services, databases, APIs, endpoints, network paths, containers, load balancers, and embedded devices. A source-code scanner may find an RSA call. A cloud connector may find a KMS key. A certificate inventory may show an expiring leaf certificate. Each finding is useful, but none explains the operating system around it.

That is why a Cryptographic Bill of Materials, or CBOM, should be treated as the beginning of a migration program—not its conclusion.

Discovery must span the cryptographic estate

QuantumGenie approaches discovery as a cross-surface evidence problem. CipherScan^™ is designed to collect and normalize cryptographic evidence from approved sources such as:

• source-code platforms and repositories;
• cloud infrastructure and cloud-native security services;
• relational and non-relational databases;
• certificates, public-key infrastructure, managed keys, and secrets;
• compute, storage, containers, and workloads; and
• authorized endpoint and network telemetry supplied through CipherEdge^™.

The output is not merely a list of strings that resemble algorithm names. A useful inventory distinguishes a stable cryptographic object—such as a certificate or managed key—from a cryptographic usage occurrence observed in a repository, file, line, workload, protocol, or data-processing path. It also preserves provenance so an operator can inspect where each assertion came from.

CycloneDX provides a portable structure for representing cryptographic assets and their properties. A standards-aligned CBOM can describe algorithm families, parameters, evidence occurrences, cryptographic functions, object identities, and dependencies. That interoperability is important: cryptographic inventory should not become trapped inside another proprietary dashboard.

But representation alone does not establish business impact. For that, the inventory needs relationships.

From an ingredient list to a causal model

During a recent technical briefing, one of our co-founders described the Causal Security Engine^™ with a supply-chain analogy:

“In fact, that’s our secret sauce. We take one encrypted packet or a data object and we go all the way down to where it is produced. I like to give this analogy: suppose you are baking a cake, and your encrypted data is a cake which has egg, flour, chocolate, and sugar. You trace the encryption—which is the chocolate—all the way back to the farm. Maybe it was produced in Colombia, on a certain farm, from a certain plant, down to the seed. So we identify the exact seed where it was produced.”

In this analogy, the packet or encrypted data object is the finished cake. Its applications, services, libraries, protocols, keys, and other technical inputs are the ingredients. Chocolate represents the cryptographic operation we want to trace. The investigation moves backward from the finished object, through the processing path and implementation, to the technical origin that introduced the cryptography.

The “seed” is therefore the earliest attributable technical origin supported by the available evidence: the service, pipeline, repository, file, and source location that produced or transformed the object. The purpose of the analogy is not to claim magical certainty. It explains the desired evidence path—from an observed cryptographic signal back through the systems that caused it, while preserving the confidence and provenance of each connection.

This changes the questions an enterprise can ask. Instead of stopping at “RSA-2048 exists,” a causal view can help investigate:

• Which service invokes the algorithm?
• Which repository and source location contain the implementation?
• Which application, API, queue, or database receives the resulting data?
• Which certificate or key protects the route?
• Which external library, vendor dependency, or platform constrains migration?
• Which business process would be affected by a change?

As the same co-founder put it:

“So every line is kind of a causal mapping.”

Those mappings form a graph. CryptoSphere^™ and the Security World Model^™ provide QuantumGenie’s connected view for exploring that graph across repositories, services, data stores, infrastructure, endpoints, certificates, keys, and findings. The Causal Security Engine^™ supplies attribution and dependency evidence; the Security World Model^™ makes the resulting topology navigable.

The distinction matters. A flat inventory tells a security team what exists. A causal model helps explain what depends on it, why it matters, and where intervention should begin.

Certificates and keys cannot be remediated like source code

Automated source-code remediation is attractive because the change can be generated, reviewed, tested, and proposed through an ordinary engineering workflow. CipherNova^™ can organize a finding, recommend a supported migration pattern, prepare a proposed change, and place human approval before merge and deployment.

Certificates and managed keys require a different workflow. They have issuers, private-key custody, validity periods, deployment targets, trust chains, service bindings, renewal processes, and outage risk. A certificate rotation that ignores those relationships may be technically correct and operationally dangerous.

The governing question is simple:

“Here we list out all the certificates, and for each certificate we show how many services are bound to it. If you nudge any certificate, which services might get disturbed? What is the sensitivity and severity of that action? That is what we plan out here.”

This is the operational difference between detecting an obsolete certificate and migrating it safely. The certificate is not an isolated file; it may terminate traffic for several public services, authenticate internal workloads, sit behind a load balancer, or depend on a particular certificate authority and private-key custody process. The migration plan must make those dependencies and consequences visible before a replacement is issued or deployed.

A responsible certificate migration flow therefore needs more than a “replace” button. It should expose:

1. Discovery: certificate identity, issuer, algorithm, key size, validity, location, owner, and evidence source.
2. Relationship mapping: private-key custody, CA chain, load balancers, gateways, applications, clusters, secrets, and other dependent services.
3. Migration planning: recommended target profile, compatibility constraints, maintenance requirements, expected impact, confidence, and rollback conditions.
4. Generation and issuance: an approved certificate signing request and, where supported, controlled interaction with the relevant CA or cloud certificate service.
5. Staged deployment: installation into the intended target without silently redirecting production dependencies.
6. Validation: handshake testing, chain validation, application health checks, and confirmation that dependent services still respond correctly.
7. Cutover and retirement: service remapping, observation, rollback availability, and eventual retirement of the legacy certificate.

This is the model behind guided certificate migration in CipherNova^™: discovery, plan, generate, deploy, validate, cut over, and retire—each with evidence and human control.

Managed keys need equivalent care. A KMS key may protect multiple databases, buckets, queues, volumes, or application secrets. The absence of a recorded relationship is not proof that a key is unused; it may indicate that evidence collection or provider metadata is incomplete. Migration decisions should make that uncertainty visible.

Causal Risk Triage^™ converts findings into an order of work

Large inventories create a second problem: prioritization. A severe algorithm finding in an isolated test utility may be less urgent than a moderately scored certificate that protects a public payment path and is bound to several production services.

Causal Risk Triage^™ is designed to score and order findings using more than the algorithm label. Relevant signals can include:

• cryptographic weakness and quantum class;
• confidence and evidence quality;
• dependency count and causal reach;
• public exposure and data sensitivity;
• certificate lifecycle and key state;
• business criticality and environment;
• available migration pattern; and
• validation, downtime, and rollback constraints.

The result is not an unquestionable AI verdict. It is a transparent, reviewable starting point for sequencing work. Operators still need to confirm scope, ownership, exceptions, and business context.

Compliance views should expose evidence, not declare victory

Standards and governance frameworks help organizations structure their programs. NIST FIPS 203, 204, and 205 define the first finalized U.S. post-quantum standards for key encapsulation and digital signatures. NIST Cybersecurity Framework 2.0 and the NIST SP 800 family provide broader risk-management and control context.

A product should not convert a few scanner results into a blanket claim of compliance. It can, however, make the underlying evidence easier to inspect:

• what cryptographic assets were observed;
• which sources and environments were covered;
• which algorithms are classical, post-quantum, hybrid, or unknown;
• which certificates and keys have confirmed relationships;
• which scopes were blocked or not assessed;
• which findings have approved migration plans;
• which changes were validated; and
• when the evidence was last refreshed.

This is a stronger basis for governance than a static percentage. It preserves both coverage and uncertainty.

The operating loop: discover, connect, prioritize, remediate, verify

Post-quantum readiness is not a one-time replacement exercise. Applications change, certificates renew, devices reconnect, new services are deployed, and vendor dependencies evolve. The CBOM must therefore become a living control plane.

QuantumGenie’s product model joins five activities:

1. CipherScan^™ discovers cryptographic objects and usage evidence across approved enterprise surfaces. Its open-source repository scan shows how repository evidence can become an inspectable cryptographic inventory.
2. CipherEdge^™ observes authorized endpoint, device, disk, and network posture where connector-based inventory is insufficient.
3. The Causal Security Engine^™ attributes signals to services, repositories, source locations, data paths, and dependencies.
4. The Security World Model^™ visualizes the resulting relationship topology across the cryptographic estate.
5. CipherNova^™ plans and assists remediation, preserving approvals, deployment stages, validation evidence, and rollback paths.

The public Harvest Now, Decrypt Later demonstration illustrates why the exposure window begins before a cryptographically relevant quantum computer exists. Readers can also explore the QuantumGenie Knowledge Base for technical concepts or compare approaches in the PQC competition matrix.

The value is not in having the longest list of cryptographic findings. It is in maintaining a defensible chain from observation to impact, decision, change, and proof.