# You Cannot Rotate What You Cannot See: Crypto-Agility and the Cryptographic Bill of Materials
> The hard part of post-quantum is not the new algorithms -- it is finding the old ones. A field guide to crypto-agility, discovery, and the CycloneDX CBOM.
*Published: 2026-07-14*
*Canonical: https://paragmali.com/blog/you-cannot-rotate-what-you-cannot-see-crypto-agility-and-the*
*© Parag Mali. All rights reserved.*
---
Post-quantum migration is two problems wearing one name: being able to ROTATE your cryptography, and being able to SEE where it all lives. The new algorithms are the easy part -- ML-KEM is a `pip install` away and already ships inside Windows. The hard part is finding the old RSA, ECDH, and ECDSA, which is "typically buried deep within components." Crypto-agility (RFC 7696, 2015) is the design-time discipline for rotating. The Cryptography Bill of Materials (CBOM), upstreamed into CycloneDX v1.6 in April 2024, is the machine-readable substrate for seeing: it models cryptography as a first-class asset with `implements` and `uses` dependencies you can prioritize as a graph. Executive Order 14412 makes the stack binding -- key establishment by 2030, signatures by 2031 -- and directs CISA to define CBOM's minimum elements. But both halves have a provable ceiling: complete automated discovery is undecidable, and long-lived signatures, trust anchors, and firmware cannot be rotated after the fact. This is the field guide to both verbs, and to why you cannot rotate what you cannot see.
## 1. You Cannot Rotate What You Cannot See
In November 2022, the White House told every federal civilian agency to do something that sounds almost trivial: make a list. OMB Memorandum M-23-02 directed each agency to produce a *prioritized inventory* of the cryptographic systems most vulnerable to a future quantum computer, to submit the first version by May 4, 2023, and to keep it current every year through 2035 [@omb-m2302]. Not to migrate anything yet. Just to write down where the vulnerable cryptography was, and to name a migration lead within thirty days to own the effort [@omb-m2302].
Agencies discovered they could not do it. They could not reliably answer the question "where does our RSA-2048 actually live?" -- because, as IBM's own documentation for the Cryptography Bill of Materials puts it, cryptography "is typically buried deep within components that are used to compose and build systems and applications" [@ibm-cbom]. The mandate assumed a list any competent organization could produce. The list turned out to be the hard part.
Now the deadlines are real. Executive Order 14412, signed June 22, 2026, orders agencies to move their high-value and high-impact systems to post-quantum key establishment by December 31, 2030 and to post-quantum digital signatures by December 31, 2031 [@eo14412]. And here is the asymmetry that reframes the entire migration: **the new algorithm is the easy part.** NIST finalized the replacements in FIPS 203, 204, and 205 on August 13, 2024 [@fips203].
ML-KEM, the standardized replacement for the key exchange that Shor's algorithm dooms, is a `pip install` away in Python and already ships inside Windows' SChannel and SymCrypt [@pyca-changelog] [@ms-pqc-windows], as the sibling posts in this series show.The two "migrate to what" endpoints are covered in companion posts: ML-KEM arriving in the default `pyca/cryptography` wheels, and ML-KEM plus ML-DSA landing in Windows SChannel and SymCrypt. This article is deliberately the other half -- finding the old cryptography, not adopting the new.
You can adopt the replacement this afternoon. What you cannot do this afternoon -- or this quarter, or perhaps by the deadline -- is enumerate every place your organization still relies on the cryptography it replaces.
> **Note:** FIPS 203, 204, and 205 were finalized in August 2024 [@fips203], and quantum-safe primitives now ship in mainstream libraries and operating systems [@pyca-changelog] [@ms-pqc-windows]. Yet the 2030 and 2031 deadlines are hard [@eo14412]. The binding constraint is not availability. It is visibility -- knowing where the quantum-vulnerable cryptography is.
Post-quantum migration is really two problems wearing one name. One is being *able to change* your cryptography -- the discipline of **crypto-agility**, which the field has refined since the 1990s and formalized in 2015. The other is *knowing where your cryptography is* -- the inventory problem, which almost nobody was forced to take seriously until a mandate arrived with a deadline attached.
The two-verb diagnostic runs through everything that follows. **ROTATE:** can a system change its algorithms at all, without being re-architected? **SEE:** does the organization actually know where its RSA, ECDH, and ECDSA are deployed? The thesis of this field guide is one line: *you cannot rotate what you cannot see.*
Why does the split matter so precisely, and why do the two deadlines differ by a year? Because the threat driving the confidentiality deadline is not a quantum computer that exists today. It is an adversary recording your encrypted traffic today to decrypt it later, once a capable quantum machine is built.
The threat model in which an adversary records encrypted data today and stores it, intending to decrypt it once a sufficiently capable quantum computer exists. Because captured ciphertext can be broken retroactively, HNDL makes confidentiality and key establishment urgent *now* -- even before any quantum computer is built. It does not threaten digital signatures, which cannot be forged retroactively, which is why Executive Order 14412 dates key establishment (2030) ahead of signatures (2031) [@eo14412].
A quantum computer large and reliable enough to run Shor's algorithm against deployed RSA and elliptic-curve key sizes. No CRQC is known to exist yet; its uncertain future arrival date is the quantity a migration plan races against, and the term that anchors the prioritization math introduced later in this guide.
The ability to swap an algorithm is the half the field spent thirty years perfecting. Knowing where every algorithm lives is the half it avoided until a deadline made avoidance impossible. To see how the discipline got so lopsided, start where the pain began: with cryptography that could not be changed at all.
## 2. Algorithm Rigidity as Original Sin
Long before anyone worried about quantum computers, migrating a single cryptographic algorithm was already agony -- and the reason was structural, not mathematical. The 2030 deadline is a decade-long emergency, not a weekend of `pip install` commands, because changing one algorithm has always been so hard that it takes decades.
Start with why a migration is coming at all. In 1994, Peter Shor showed that a quantum computer could factor large integers and compute discrete logarithms in polynomial time [@shor1994]. That single result put RSA, Diffie-Hellman, elliptic-curve Diffie-Hellman, and ECDSA on notice: the mathematical problems they rely on become tractable to a sufficiently large quantum machine.
The internals of Shor's algorithm and the lattice math that replaces these primitives belong to the companion posts in this series. For this guide, one fact is enough: the public-key cryptography holding up most of the internet has a known expiration condition, and the field has known it for three decades.
Knowing an algorithm will eventually fall is not the same as being able to replace it. The deeper problem is that early protocols baked a single primitive directly into their design. There was no algorithm identifier on the wire, so a peer could not announce which cipher it intended to use, and there was no clean seam at which to substitute a different one.
RFC 7696, the IETF's 2015 best-current-practice document on the subject, describes the consequence precisely: without an algorithm identifier, transitioning "from one algorithm to another" requires "the protocol version number or some other major change" [@rfc7696]. Swapping a cipher meant revising the protocol itself.
The design-time property that, in RFC 7696's words, "Algorithm agility is achieved when a protocol can easily migrate from one algorithm suite to another more desirable one, over time" [@rfc7696]. In plain terms: the ability to change cryptographic algorithms without re-architecting the systems that depend on them. It is a property you build in before you need it -- and it says nothing about discovering cryptography you have already deployed.
The canonical worked example is slow, symmetric, and instructive. RFC 7696 notes that "the transition from DES to Triple-DES to AES took place over decades, causing a shift in symmetric block cipher strength from 56 bits to 112 bits to 128 bits" [@rfc7696].That 56-to-112-to-128-bit progression over roughly a quarter century is the template the public-key world is now rerunning against RSA and elliptic curves, except compressed into a single mandated decade. The symmetric transition had no hard federal deadline; this one does. Decades, for a change every cryptographer agreed was necessary. And the reason was not that AES was hard to implement. It was that thousands of systems had hardcoded the old cipher with no seam at which to change it.
This is the original sin, and it compounds. RFC 7696 opens with the blunt observation that "cryptographic algorithms age; they become weaker with time," so protocol designers "need to assume that advances in computing power or advances in cryptoanalytic techniques will eventually make any algorithm obsolete" [@rfc7696]. If aging is certain and the algorithm is welded in place, then every cryptographic break becomes an estate-wide re-architecture. The field lived this repeatedly: DES and Triple-DES, MD5, RC4, and SHA-1 each had to be ripped out of deployed systems at enormous cost.
RC4 was so entrenched that removing it required the IETF to publish an entire standard, RFC 7465, whose sole job was to command that "TLS clients and servers never negotiate the use of RC4 cipher suites when they establish connections" [@rfc7465].Adding an algorithm is easy; removing one is so hard that it can take a dedicated standards-body prohibition. RFC 7465 exists only to say "stop using RC4" -- a one-line policy that needed the weight of a published RFC because the cipher was wired into too many implementations to retire quietly [@rfc7465].
timeline
title From Shor to a federal deadline
1994 : Shor's algorithm dooms RSA, DH, and ECC in theory
1990s-2001 : DES to Triple-DES to AES over decades
2015 : RFC 7696 turns agility into a discipline
2022 : NSM-10 and OMB M-23-02 mandate a prioritized inventory
2023 : NIST NCCoE SP 1800-38 preliminary draft on discovery
2024 : CBOM upstreamed into CycloneDX v1.6
2025 : NIST CSWP 39 restates agility as risk management
2026 : Executive Order 14412 sets the 2030 and 2031 deadlines
Notice the character of this failure. It is not that the cryptography computed the wrong answer. DES still encrypts; MD5 still hashes. The failure is one of operability: the algorithm runs fine, but the system cannot move off it. That distinction matters, because it means the fix is not a better algorithm. The fix is a better *design* -- one that stops welding the primitive in place.
The obvious such fix is to put a name on the wire and let the peers choose. That fix has a name of its own, cipher-suite negotiation, and for a while it looked like the whole answer. It was not.
## 3. Negotiation and the Spreadsheet
Each half of the problem got a first-generation answer. Both were reasonable. Both under-delivered, and in almost the same instructive way. If you can negotiate algorithms at connection time and audit the results into a spreadsheet, what could possibly be left to solve?
**The rotate half's first answer was negotiation.** Instead of welding one cipher into the protocol, carry an identifier for the algorithm -- or for a whole suite of them -- on the wire, back it with an IANA registry of code points, and let the two endpoints agree on the best option they both support. TLS cipher suites, IKE and IPsec transforms, the [X.509](/blog/a-perfect-signature-for-a-certificate-that-should-never-have/) `AlgorithmIdentifier`, and the JOSE and COSE object formats all work this way.
RFC 7696 blesses the approach while carefully bounding its importance: "The inclusion of an algorithm identifier is a minimal step toward cryptographic algorithm agility" [@rfc7696]. Minimal is the operative word.
Negotiation is necessary, and it is nowhere near sufficient, for three documented reasons. First, negotiation you do not integrity-protect can be turned against you. RFC 7696 warns that an unprotected negotiation "will be subject to a downgrade attack" [@rfc7696], and the field has the scars to prove it. The 2015 Logjam attack "allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography" [@weakdh], steering two peers who both support strong [Diffie-Hellman](/blog/nobody-broke-the-discrete-log-a-field-guide-to-diffie-hellma/) down to a key size a well-resourced attacker can break [@weakdh-pdf]. FREAK and POODLE are cousins in the same family [@freak] [@poodle].
Second, negotiation encourages *ossification*: because dropping an option can break some peer somewhere, "flawed algorithms are supported for far too long" [@rfc7696] -- which is exactly why retiring RC4 needed its own prohibiting standard [@rfc7465].
Third, every additional negotiable option is additional attack surface and additional code to get right [@rfc7696].
> **Note:** Being able to negotiate a strong cipher does two things it is easy to conflate with a solved migration, and neither is one. Unprotected negotiation invites downgrade attacks -- Logjam, FREAK, and POODLE all forced peers onto weak-but-supported options [@weakdh] [@freak] [@poodle]. And selecting AES at connection time tells you nothing about *where* the weak algorithm still lives. Negotiating AES on one server says nothing about which of your ten thousand other servers still negotiate RC4.
That last point is the decisive one for this guide. Negotiation lets a system *select* among options both peers pre-agreed to support. It gives you no ability to *remove* an algorithm across your estate, and -- this is the part everyone misses -- no ability to *know where a given algorithm is deployed in the first place*.
A protocol that can negotiate its way onto AES has told you nothing about the inventory of RC4, RSA-1024, or SHA-1 scattered across your servers, firmware, and stored certificates. Agility at the connection is not visibility across the estate.
The two negotiation styles are both legitimate and opposite. IPsec and IKEv2 carry a separate identifier for each algorithm; TLS carries one identifier per whole suite. RFC 7696 explicitly blesses both -- "some approaches carry one identifier for each algorithm ... other approaches carry one identifier for a full suite of algorithms" [@rfc7696] -- trading a combinatorial explosion of options against coarser, less flexible suites. There is no single right answer, only a design choice.
**The see half's first answer was the spreadsheet.** Manual audits, one-off certificate scans, a cryptography inventory maintained by hand. It is the natural first move, and it fails for reasons that have nothing to do with effort. A spreadsheet does not scale to an estate of thousands of applications and millions of certificates. It is stale the moment it is written, because code ships and certificates rotate daily.
It is not machine-actionable: you cannot run a query against it, diff it against last quarter, or check it automatically against a 2030 deadline. And it cannot be propagated -- when a vendor updates a library, nothing in your spreadsheet knows. It is a document, not a queryable system.
The one semi-automated technique in wide use, certificate discovery, is genuinely useful but sees only the public-key infrastructure surface: the certificates, not the code that calls them or the protocols that carry them.
To name the shape of the answer that eventually arrives, borrow the idea the software supply chain had already converged on.
A machine-readable inventory of the components inside a piece of software and the dependencies among them, published in a standard format such as CycloneDX or SPDX so that tools -- not people -- can query, diff, and act on it [@owasp-cdx16]. An SBOM is to software components what a later chapter's Cryptography Bill of Materials is to cryptographic assets: the crypto version is a specialized extension of exactly this idea.
Both first answers failed for the same underlying reason: they treated agility and inventory as afterthoughts to bolt on, rather than disciplines to design for. The difference in what happened next is the whole story of the next section. The rotate half got its discipline first, compressed into a single 2015 document that turned "agility" from a slogan into an engineering checklist. The see half got nothing comparable -- until someone with a deadline *made* organizations solve it.
## 4. From Slogan to Discipline, and the Inventory Forced Into the Open
This is where the two lineages split, mature on separate tracks, and then -- years later -- get forced back together by a mandate. It also poses the sharpest question in the whole story: if algorithm agility became a real engineering discipline in 2015, why were federal agencies still helpless in front of a simple inventory in 2022?
**The rotate half got its discipline in a single document.** In November 2015, Russ Housley published RFC 7696, "Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms," as IETF Best Current Practice 201 [@rfc7696]. It turned a slogan into a checklist. Register your algorithm identifiers. Keep the set of algorithms every implementation must support small, and -- the load-bearing idea -- put that set in a *companion* document so it can change "without updating the base protocol specification" [@rfc7696]. Integrity-protect your negotiation so it cannot be downgraded [@rfc7696].
And heed two cautions that sound paradoxical until you have lived them: section 3.2 is titled "Too Many Choices Can Be Harmful," and section 3.3 is titled "Picking One True Cipher Suite Can Be Harmful" [@rfc7696]. Too many negotiable options is attack surface; exactly one is a single point of failure with no in-band recovery. The discipline lives in the tension between them.
The small set of algorithms every conformant implementation of a protocol is required to support, so that any two implementations are guaranteed to share at least one. RFC 7696 recommends keeping the MTI set in a separate companion document precisely so the required algorithms can change "without updating the base protocol specification" when one weakens [@rfc7696] -- agility applied to the requirements themselves.
Here is the limit that makes 2015 insufficient for 2022. RFC 7696 is *design-time and forward-looking*. It helps every system you build *after* you adopt it, and it says nothing about *discovering* the cryptography you already deployed across a legacy estate. An organization can adopt RFC 7696 wholesale for all new development and still be completely unable to answer "where does RSA-2048 live in what we already run?" The discipline hardens the rotate half. It never touched the see half.
**The see half was forced open by a mandate.** In May 2022, National Security Memorandum 10 set the strategy: inventory the government's quantum-vulnerable cryptography [@nsm10]. That November, OMB M-23-02 operationalized it, directing every agency to submit a *prioritized* cryptographic inventory, to designate a cryptographic inventory and migration lead within thirty days, and to repeat the inventory annually [@omb-m2302]. The order was not "migrate." It was merely "tell us what you have, worst things first."
And it exposed the binding constraint immediately: agencies could not enumerate their own quantum-vulnerable cryptography, because -- as IBM's CBOM documentation states -- it "is typically buried deep within components that are used to compose and build systems and applications" [@ibm-cbom]. The manual method the mandate inherited did not scale to the estate it was pointed at. This, not any algorithm milestone, is the real turning point of the field: thirty years of perfecting the rotate half had left the see half genuinely unsolved.
"Cryptography is typically buried deep within components that are used to compose and build systems and applications." -- IBM CBOM documentation, on why an inventory is the hard part [@ibm-cbom]
**Automation answered the scale problem, and revealed a deeper one.** CISA responded with a strategy for Automated Cryptography Discovery and Inventory tools, describing their purpose as "the use of ACDI tools to support a FCEB agency in its creation of an inventory of its information systems and assets that contain CRQC-vulnerable cryptography," where "the inventory tools automate the collection of the cryptographic characteristics required for the inventory" [@cisa-acdi]. NIST's National Cybersecurity Center of Excellence supplied a reference architecture in the SP 1800-38 practice guide, which remains a preliminary draft rather than a finalized standard [@sp1800-38-guide].
Automation gave the see half the scale a spreadsheet never had. But it exposed a subtler gap: a scanner emits a *pile of tool-specific findings*, not a queryable inventory. "Component X contains AES" carries no distinction between the algorithm family and the specific variant, and no dependency structure connecting the library that implements an algorithm to the application that uses it. Automation delivered scale without a data model.
CISA's term for tools that automatically enumerate an organization's cryptographically relevant, quantum-vulnerable assets across its systems, collecting "the cryptographic characteristics required for the inventory" rather than relying on manual audits [@cisa-acdi]. ACDI supplies the scale a manual inventory lacks -- but on its own it produces findings, not a structured, prioritizable model.
> **Key idea:** Post-quantum migration is two verbs, not one: ROTATE, the design-time discipline of being able to change your cryptography, and SEE, the run-time practice of knowing where it all lives. The field perfected the rotate half over thirty years -- rigidity to negotiation to RFC 7696 -- and only closed the see half under a federal deadline. You cannot rotate what you cannot see.
The two lineages, and their eventual meeting point, look like this when you draw them on one page.
flowchart TD
subgraph ROT["ROTATE lane -- design-time agility"]
R1[Hardcoded rigidity] --> R2[Cipher-suite negotiation]
R2 --> R3[RFC 7696 discipline]
R3 --> R4[NIST CSWP 39 risk guidance]
end
subgraph SEE["SEE lane -- run-time inventory"]
G1[Manual spreadsheet] --> G2[Federal mandate NSM-10 and M-23-02]
G2 --> G3[Automated discovery ACDI]
end
R4 --> CBOM["CycloneDX CBOM, crypto as a first-class asset"]
G3 --> CBOM
CBOM --> EO["Executive Order 14412 makes the stack binding"]
The condensed history of both lanes fits in one table.
| Generation | Era | Key idea | Why it was superseded, or its limit | Status |
|---|---|---|---|---|
| 1. Hardcoded rigidity | pre-2000s | One primitive baked in, no wire identifier | Every break forced an estate-wide re-architecture | Obsolete |
| 2. Cipher-suite negotiation | 1990s-2010s | Algorithm or suite identifiers, IANA registry, negotiate | Downgrade attacks and ossification; selects but cannot see or remove | Necessary, insufficient |
| 3. Agility as discipline (RFC 7696) | 2015 | Registered IDs, MTI in a companion doc, protected negotiation | Design-time and forward-looking only; blind to deployed crypto | Current (rotate half) |
| 4. Manual inventory under mandate | 2022 (NSM-10 / M-23-02) | Order a prioritized cryptographic inventory | Spreadsheet does not scale, stale, not machine-actionable | Superseded by automation |
| 5. Automated discovery (ACDI) | 2022-2025 | Tools auto-collect cryptographic characteristics | A pile of tool-specific findings, no shared data model | Current (scale) |
| 6. CBOM substrate | 2024 (CycloneDX 1.6) | Model crypto as a first-class asset with dependencies | Only as complete as the scanners that populate it | Current (see half) |
Design-time agility was, by 2024, a solved discipline. Run-time inventory finally had scale, but no shape. The missing piece was never another scanner. It was a way to model cryptography *itself* as an asset you could query, prioritize, and pass down a supply chain. That piece arrived on April 9, 2024.
## 5. The Breakthrough: Cryptography as a First-Class Asset
The breakthrough was not a better scanner. It was a decision to model cryptography the way the software supply chain already models its components -- as inventoried assets with dependencies you can query. To see why that is a genuine shift and not a rebranding, ask what a raw scan finding is missing. What does "component X contains AES" need to carry before it becomes something you can actually act on?
On April 9, 2024, that question got an answer with a standard behind it. IBM Research's Cryptography Bill of Materials was upstreamed into OWASP CycloneDX v1.6 [@owasp-cdx16]. CBOM was carried into the current CycloneDX v1.7 (October 2025), published as the Ecma International standard ECMA-424, which extended the cryptography model further [@cdx-spec-17]. The design choice that matters most is the quietest one: a CBOM is an *extension of the same CycloneDX BOM document*, not a separate schema [@ibm-cbom]. Your cryptographic inventory can live in the same file as your software inventory, produced by the same tools, consumed by the same pipelines. CBOM did not invent a parallel supply chain. It taught the existing one to describe cryptography.
Its design answers four specific ways a raw finding falls short [@ibm-cbom]. First, it models the *asset types* that matter -- algorithms, protocols, certificates, and "related crypto material like keys, tokens, secrets or passwords." Second, it captures the property that makes a finding actionable: the difference between a family and a variant. As the CBOM documentation puts it, "it makes a difference if one knows the algorithm family (e.g. AES) or the specific variant ... (e.g. AES-128-GCM) ... SHA1 vs. HMAC-SHA1 also makes a difference" [@ibm-cbom]. A report of "AES" is not actionable. "AES-128-GCM at file X, line 51" is.
An extension of the CycloneDX BOM document that models an organization's cryptographic assets -- algorithms, protocols, certificates, and related key material -- together with their properties and the dependencies among them [@ibm-cbom]. At the field level, a crypto-asset is a component of type `cryptographic-asset` carrying `cryptoProperties` (whose `assetType` is one of algorithm, certificate, protocol, or related-crypto-material) and `evidence.occurrences` recording where it was found [@cdx-cbom-cap] [@cdx-cbom-guide]. It is the first open standard purpose-built to describe cryptography as an inventoried, dependency-aware asset.
The third design goal is the one that turns a list into a graph. CBOM "differentiates between 'implements' and 'uses' dependencies ... (e.g. TLS 1.3 uses ECDH/secp256r1)" [@ibm-cbom]. A library *implements* an algorithm; an application *uses* it. That single distinction is the edge type that lets you answer the question the whole migration turns on: which applications transitively depend on a quantum-vulnerable primitive? Fourth and finally, the model applies uniformly across applications, libraries, firmware, and files, so the same representation describes source code, a shipped container, and an embedded device.
CBOM's two crypto-asset relationship types. A component *implements* a cryptographic asset when it provides the algorithm (a library implements ECDH/secp256r1); a component *uses* an asset when it consumes it (TLS 1.3 uses ECDH/secp256r1, and an application uses TLS 1.3) [@ibm-cbom]. Distinguishing the two turns a flat inventory into a directed graph -- and makes "which applications are exposed to this weak primitive?" a graph traversal rather than a guess.
Model each crypto-asset with `cryptoProperties` and connect them with `implements` and `uses` edges, and the inventory stops being a list and becomes a directed graph. The CycloneDX capability documentation describes exactly this: the format "enables detailed representation of cryptographic assets within a system," including "algorithms, keys, certificates, and their relationships to software components" [@cdx-cbom-cap]. On a graph, prioritization is a traversal -- and a traversal over $V$ assets and $E$ dependencies costs $O(V + E)$, cheap enough to run over an entire estate.
flowchart TD
APP["Application (payments-api)"] -->|uses| TLS["TLS 1.3"]
TLS -->|uses| ECDH["ECDH secp256r1, quantum-vulnerable"]
LIB["Library (openssl)"] -->|implements| ECDH
LIB -->|implements| AES["AES-128-GCM"]
The graph reads directly. The application `payments-api` uses TLS 1.3, which uses ECDH over secp256r1 -- a key-exchange primitive Shor's algorithm defeats. Follow the `uses` edges and the exposure is explicit: this application is on the 2030 list. The `implements` edges tell you where to fix it: `openssl` provides that primitive, so the remediation targets that library. The same two edge types that describe the estate also route the work.
| CBOM concept | What it captures | Example |
|---|---|---|
| `assetType: algorithm` | A cryptographic algorithm or primitive | ML-KEM, RSA-2048, ECDH/secp256r1, AES-128-GCM |
| `assetType: certificate` | An X.509 certificate as an inventoried asset | A TLS server certificate expiring in 2029 |
| `assetType: protocol` | A protocol that consumes cryptography | TLS 1.3, SSH, IKEv2 |
| `assetType: related-crypto-material` | Keys, tokens, secrets, passwords | A stored private key or API token |
| Family vs variant | The property that makes a finding actionable | AES vs AES-128-GCM; SHA-1 vs HMAC-SHA1 |
| `implements` edge | A library provides an algorithm | `openssl` implements ECDH/secp256r1 |
| `uses` edge | An application or protocol consumes an algorithm | TLS 1.3 uses ECDH/secp256r1 |
| `evidence.occurrences` | Where the asset was actually found | File path and line number |
Here is the traversal made concrete. The snippet below parses a miniature CBOM and walks its `uses` edges to flag every application transitively exposed to a quantum-vulnerable primitive.
{`
// Pedagogical, not production -- use a vetted tool such as CBOMkit.
// A tiny CycloneDX-style CBOM: crypto-assets plus implements/uses edges.
const cbom = {
components: [
{ ref: "app:payments-api", type: "application" },
{ ref: "proto:tls-1.3", type: "cryptographic-asset", assetType: "protocol" },
{ ref: "alg:ecdh-secp256r1", type: "cryptographic-asset", assetType: "algorithm", quantumVulnerable: true },
{ ref: "alg:aes-128-gcm", type: "cryptographic-asset", assetType: "algorithm", quantumVulnerable: false },
{ ref: "lib:openssl", type: "library" }
],
dependencies: [
{ ref: "app:payments-api", dependsOn: ["proto:tls-1.3"], kind: "uses" },
{ ref: "proto:tls-1.3", dependsOn: ["alg:ecdh-secp256r1"], kind: "uses" },
{ ref: "lib:openssl", dependsOn: ["alg:ecdh-secp256r1", "alg:aes-128-gcm"], kind: "implements" }
]
};
// Adjacency map built from the "uses" edges only.
const usesEdges = {};
for (const d of cbom.dependencies) {
if (d.kind === "uses") usesEdges[d.ref] = d.dependsOn;
}
const vulnerable = new Set(
cbom.components.filter(c => c.quantumVulnerable).map(c => c.ref)
);
// Depth-first: does this component transitively use a vulnerable primitive?
function reachesVulnerable(ref, seen) {
seen = seen || new Set();
if (seen.has(ref)) return false;
seen.add(ref);
for (const next of (usesEdges[ref] || [])) {
if (vulnerable.has(next) || reachesVulnerable(next, seen)) return true;
}
return false;
}
const apps = cbom.components.filter(c => c.type === "application");
for (const app of apps) {
const verdict = reachesVulnerable(app.ref) ? "EXPOSED" : "clear";
console.log(app.ref + " -> " + verdict);
}
`}
> **Key idea:** CBOM's breakthrough is not discovery power -- it is a data model. Model each crypto-asset with the property that makes it actionable (family versus variant) and its `implements` and `uses` dependencies, and a pile of tool-specific scan findings becomes a prioritizable graph you can query with a single traversal.
"CBOM is the first open standard to describe an organizations' cryptographic assets inventory, and their dependencies." -- Michael Osborne, CTO, IBM Quantum Safe [@owasp-cdx16]
One caution keeps this honest, and a later section pays it off in full. A CBOM is a data model, not a discovery method. It is only ever as complete as the scanners that populate it [@ibm-cbomkit-blog]. Modeling cryptography as a graph is necessary, and it does not make the cryptography any easier to find.CycloneDX v1.6 shipped Attestations (CDXA) alongside CBOM -- machine-readable "attestations to the veracity and completeness of those claims" [@owasp-cdx16]. That plumbing is what the open problem of *completeness attestation*, discussed later, is built on: a way to state not just what you found, but how thoroughly you looked.
With cryptography finally modeled as a queryable, prioritizable graph, the remaining pieces could be assembled into a real pipeline: discipline at design time, discovery across every surface, roll-up into a CBOM, and prioritization against a deadline. By 2026, that pipeline has a definite shape.
## 6. The Discovery-to-Migration Stack (2026)
The state of the art in 2026 is not a product. It is a layered pipeline, and its governing rule is that no single layer is complete. Read from the top, it takes a legacy estate and produces a prioritized, deadline-aware migration plan.
**The design-time layer is crypto-agility as discipline.** RFC 7696 did not stay an IETF document. In December 2025, NIST published Cybersecurity White Paper 39, "Considerations for Achieving Cryptographic Agility: Strategies and Practices" (updated as CSWP 39-upd1 in June 2026), restating algorithm agility as national risk-management guidance [@cswp39]. The author list closes a thirty-year loop: Russ Housley, who wrote RFC 7696, appears alongside the leaders of NIST's post-quantum standardization such as Dustin Moody and Lily Chen, and William Newhouse, who leads the NCCoE inventory work [@cswp39].
The people who standardized the new algorithms, the person who formalized agility, and the person building the inventory practice signed the same page. Agility sits at the top of the stack because it is what makes the eventual swap cheap.
**The discovery layer is five surfaces, and each is blind exactly where another sees clearly.** This is the heart of the see half, and the reason the outputs must be merged rather than chosen among.
- *Static source analysis* reads owned source code and reports cryptographic calls with file-and-line precision. CBOMkit-Hyperion and its Sonar Cryptography plugin do this today, generating a CBOM directly from source and covering Java's JCA and Python's pyca/cryptography libraries [@sonar-crypto] [@ibm-cbomkit-blog]. It is precise and cheap in continuous integration -- and blind to third-party binaries it cannot see the source of, and to algorithms selected through dynamically constructed names.
- *Binary and container analysis* reaches what static analysis cannot: shipped binaries, container images, and firmware. CBOMkit-Theia scans these artifacts [@cbomkit]. It reaches code you did not build -- and is defeated by packing and obfuscation, which can make cryptographic code indistinguishable from anything else.
- *Passive network monitoring* observes the algorithms actually negotiated on live links, giving ground-truth on what is really in use. It is blind to data at rest and to systems that are simply idle during the capture window.
- *Active probing* connects to listening services and enumerates the algorithms they will agree to negotiate, producing a capability census. It reaches only services that are listening, and says nothing about internal batch jobs or stored data.
- *Certificate and key-store analysis* is the most mature surface and feeds the 2031 signature deadline most directly, but it sees only the public-key infrastructure: certificates, keys, and signature algorithms, not the code or protocols around them.
> **Note:** No single surface is complete, so the operational rule is to run several and merge them, then budget a permanent manual-validation pass over the residual. This is not a workaround; it is what CISA's ACDI strategy and NIST's SP 1800-38 practice guide prescribe -- a method mix feeding a human-checked inventory, never one tool trusted to see everything [@cisa-acdi] [@sp1800-38-guide].
The five surfaces do not rank; they tile. Draw them feeding one merge-and-validate step, and the architecture is clear.
flowchart TD
SRC[Static source scan] --> MERGE
BIN[Binary and container scan] --> MERGE
NET[Passive network sensor] --> MERGE
PROBE[Active probing census] --> MERGE
CERT[Certificate and key-store scan] --> MERGE
MERGE[Merge and manual validation] --> CBOM[CycloneDX CBOM]
| Discovery surface | What it sees | Scaling | Primary blind spot | Best suited for |
|---|---|---|---|---|
| Static source | Crypto calls in owned source, with file and line | High, runs in CI | Third-party binaries, dynamic names | Owned codebases |
| Binary / container | Crypto in shipped binaries, containers, firmware | Medium | Packing and obfuscation | Third-party and embedded artifacts |
| Passive network | Algorithms actually negotiated on the wire | High | Data at rest, idle systems | Live ground-truth |
| Active probing | Capabilities of listening services | Medium | Non-listening and internal-only services | External posture census |
| Certificate / key-store | Certificates, keys, signature algorithms | High | Anything outside the PKI | The 2031 signature deadline |
The table names each surface's blind spot. Understanding *why* those blind spots exist -- and why they are not gaps a future release will quietly close -- means looking at how a scanner actually finds cryptography, because on the two hardest surfaces the detection mechanism and the blind spot turn out to be one fact seen from two sides.
**Static source analysis lifts a library call to a normalized identity and its OID.** A source scanner does not understand cryptography; it recognizes calls into catalogued cryptographic-library APIs and resolves each to a canonical algorithm.
CBOMkit-Hyperion and its Sonar Cryptography plugin walk the parsed syntax tree, spot a call into a known provider API -- Java's `MessageDigest.getInstance("SHA-256")`, or a `pyca/cryptography` constructor -- and map it to the algorithm, its variant, and its object identifier, the dotted-decimal name the registries use [@sonar-crypto] [@ibm-cbomkit-blog]. `SHA-256` normalizes to the OID `2.16.840.1.101.3.4.2.1`, in the NIST Computer Security Objects Register arc [@oidref-sha256].The SHA-256 OID `2.16.840.1.101.3.4.2.1` is the machine-mergeable identity a static scanner lifts an API call to: two tools that print "SHA-256" and "SHA256" collapse to one crypto-asset the moment both resolve to it [@oidref-sha256].
A globally unique, dotted-decimal name for an algorithm or other object, assigned under a registration hierarchy. SHA-256 is `2.16.840.1.101.3.4.2.1` in the NIST Computer Security Objects Register arc [@oidref-sha256]. A static scanner resolves a recognized API call to its OID, and because two tools that spell an algorithm differently agree the instant both resolve to the same OID, the OID is the machine-mergeable identity the CBOM roll-up is built on.
The OID is what lets two tools' findings merge into one graph, and it also fixes the surface's exact reach. Recognition runs against a fixed catalog of call patterns -- a decidable restriction -- so an algorithm name assembled at runtime, a call made through reflection, a language the ruleset does not cover, or a hand-rolled primitive presents no catalogued API to match and is simply never seen. The precision of static analysis and its blindness to dynamic names are the same design decision.
**Binary and container analysis recovers a primitive with no symbols at all, from constants and from behavior.** A stripped artifact still exposes two things a detector can key on. The first is its constants: block ciphers and hashes embed fixed, algorithm-specific tables -- an AES S-box, SHA round-constant tables, DES permutation tables -- and matching those known tables names the primitive with no function symbol present, the structural technique of Gröbert, Willems, and Holz in their 2011 RAID paper [@grobert-raid2011].
The second is its behavior: where the constants are absent or rewritten, the detector runs the code and tests the output for cryptographic signatures -- high Shannon entropy, and the avalanche effect, in which flipping one input bit flips roughly half the output bits, a property real ciphers have and ordinary arithmetic does not. Later work such as Hill and Bellekens' CryptoKnight names the same problem of recognizing primitives in compiled code [@hill-bellekens].
This mechanism is exactly why packing is a blind spot rather than a bug to be patched. Packing or white-box obfuscation removes or rewrites the very constant tables the structural matcher depends on, and can make an implementation indistinguishable by construction from non-cryptographic code -- the worst-case form of a limit the section after next proves is fundamental.
The behavioral fallback then meets a coverage wall: it can only judge the paths it actually executes, so cryptography on an unexecuted branch stays dark. The blind spot is not a defect in the tool; it is the shadow the detection mechanism casts.
flowchart LR
subgraph STATIC["Static source lane"]
A1["Recognize catalogued library API call"] --> A2["Resolve to algorithm and variant"]
A2 --> A3["Look up object identifier, the OID"]
end
subgraph BINARY["Binary lane, no symbols"]
B1["Match S-box and round-constant tables"] --> B3["Name the primitive"]
B2["Run it, measure entropy and avalanche"] --> B3
end
A3 --> OID["Crypto-asset keyed by OID"]
B3 --> OID
OID --> NODE["Mergeable CBOM node"]
Both lanes converge on the same object: a crypto-asset named by its OID, ready to merge with every other tool's findings. That shared identity is what makes the next layer possible.
**The substrate layer rolls every surface up into a CycloneDX CBOM** -- the graph from the previous section, now populated from five directions. (SPDX 3.0 is the parallel choice, and the next section weighs it.)
**The prioritization layer turns the graph into a ranked queue using Mosca's inequality.** You cannot migrate everything at once, so you order the work by exposure.
A triage rule attributed to Michele Mosca (IACR ePrint 2015/1075): begin migrating a system *now* if $x + y > z$, where $x$ is how long the data must stay confidential, $y$ is how long the migration will take, and $z$ is the time until a cryptographically relevant quantum computer exists [@mosca-eprint]. When the exposure window $x + y$ exceeds the time to a CRQC, harvest-now-decrypt-later already threatens that data, so waiting is a loss [@gri-mosca].
Applied over the CBOM graph, Mosca's inequality converts an inventory into a sorted migration queue, and it maps cleanly onto the executive order's split: confidentiality and key establishment, where $x$ can be decades, come due in 2030, while signatures, which cannot be forged retroactively, come due in 2031 [@eo14412]. The decision, per asset, looks like this.
flowchart TD
X[Data shelf-life x] --> SUM["Exposure window x + y"]
Y[Migration time y] --> SUM
Z[Time to a CRQC z] --> D
SUM --> D{"x + y exceeds z?"}
D -->|yes| NOW[Migrate now, harvest-now-decrypt-later already applies]
D -->|no| DEFER[Defer, but keep monitoring z]
The same rule expressed as code sorts a real inventory by how little slack it has left.
{`
// Pedagogical, not production. Mosca's inequality: migrate now when x + y > z.
const yearsToCRQC = 12; // z: uncertain estimate of time to a capable quantum computer.
const assets = [
{ name: "root-CA-signing", shelfLifeYears: 20, migrationYears: 3 },
{ name: "payments-TLS", shelfLifeYears: 10, migrationYears: 2 },
{ name: "internal-metrics", shelfLifeYears: 1, migrationYears: 1 },
{ name: "archival-backups", shelfLifeYears: 25, migrationYears: 4 }
];
function triage(a) {
const exposure = a.shelfLifeYears + a.migrationYears; // x + y
return {
name: a.name,
exposure: exposure,
slack: yearsToCRQC - exposure, // negative slack means already exposed
migrateNow: exposure > yearsToCRQC
};
}
const ranked = assets.map(triage).sort((p, q) => p.slack - q.slack);
for (const r of ranked) {
const flag = r.migrateNow ? "MIGRATE NOW" : "monitor";
console.log(r.name + " exposure=" + r.exposure + "y slack=" + r.slack + "y -> " + flag);
}
`}
**The binding-policy layer is what makes the stack mandatory rather than aspirational.** CISA's ACDI strategy defines the automated-discovery goal [@cisa-acdi]; NIST's SP 1800-38 practice guide, the deliverable of the NCCoE's Migration to Post-Quantum Cryptography project, supplies the reference architecture, as a preliminary draft [@sp1800-38-guide] [@sp1800-38-project]; and Executive Order 14412 attaches the dates and, within 270 days of signing, directs CISA to publish the "minimum elements for a cryptographic bill of materials" that "enable the automated assessment of the cryptographic assets" [@eo14412]. The policy layer literally names the substrate the rest of the stack produces.
This stack works, up to a point. "Run every surface and roll it up" quietly assumes the surfaces can, together, see everything. They cannot, and no substrate choice changes that. Before confronting that ceiling, though, there is an honest comparison to make: CBOM is not the only way to inventory cryptography.
## 7. CBOM Is Not the Only Way to Inventory Cryptography
A claim that CBOM is *the* substrate has to survive its rivals. There are three real axes of competition, and on each, the honest answer is "it depends." Steelmanning the alternatives is not a detour from the thesis; it is how the thesis earns the word "substrate."
**The schema choice: CycloneDX CBOM versus SPDX 3.0.** SPDX is the other major machine-readable bill-of-materials standard, with an ISO/IEC 5962 lineage, and its 3.0 revision added a Security profile [@spdx-spec]. That profile is oriented toward vulnerability and VEX communication -- expressing whether a component is affected by a known vulnerability -- rather than toward modeling cryptographic assets in their own right [@spdx-security].VEX, the Vulnerability Exploitability eXchange, is a machine-readable statement about whether a given vulnerability actually affects a product. It answers "are we exploitable?", which is a different question from "what cryptography do we run?" -- which is why an inventory built around VEX is a different tool from one built around crypto-assets. CBOM, by contrast, ships purpose-built `cryptographic-asset` types and the `implements` versus `uses` edges that make the inventory a graph [@ibm-cbom].
The practical read: if you are inventorying cryptography to prioritize a migration, CBOM is the crypto-native choice, and it is the artifact Executive Order 14412 names by title [@eo14412]. If your organization is already standardized on SPDX and VEX workflows, SPDX 3.0 can carry crypto information at a coarser grain and keep you on one toolchain. Both, importantly, live in the same document as your SBOM, so this is a modeling choice, not a parallel-infrastructure choice.
| Dimension | CycloneDX CBOM | SPDX 3.0 |
|---|---|---|
| Steward | OWASP CycloneDX | Linux Foundation / SPDX (ISO/IEC 5962 lineage) |
| Crypto-asset modeling | Purpose-built `cryptographic-asset` types | Security profile, less crypto-specialized |
| Dependency semantics | `implements` versus `uses` edges | General relationships, VEX-oriented |
| Primary orientation | Cryptographic inventory | Vulnerability and VEX communication |
| Executive Order 14412 alignment | Named target artifact | Not named |
**The tooling choice: open versus commercial.** The open reference implementation is CBOMkit, an IBM and Post-Quantum Cryptography Alliance suite whose modules cover source scanning (Hyperion), binary and container scanning (Theia), viewing (Coeus), compliance (Themis), and repository storage (Mnemosyne) [@cbomkit] [@ibm-cbomkit-blog]. Open tooling wins on transparency, on integrating into continuous integration, and on being the reference producer of the exact CBOM format the policy layer names.
It struggles outside its rule set -- languages or libraries it does not yet recognize -- and on completeness when it lacks build context. CBOMkit's own documentation is candid about the second limit: scanning without a full build "potentially reduces completeness and accuracy of the findings since some Java symbols may not be resolved" [@cbomkit].
The commercial alternative is the category of cryptographic-posture-management platforms: closed, multi-surface products that add correlation to business services and data flows. They win on breadth and on tying a raw finding to "which revenue-bearing service is this?" They cost money, keep their data models proprietary, and -- this is the part no budget fixes -- run into the exact same theoretical ceiling as the open tools.
| Dimension | Open (CBOMkit) | Commercial cryptographic-posture management |
|---|---|---|
| Discovery surfaces | Source, plus binary and container; extensible | Multi-surface breadth out of the box |
| Output format | CycloneDX CBOM (the reference producer) | Often proprietary, typically exports CBOM |
| Correlation to business services | Limited | A primary selling point |
| Cost | Free and open | Licensed |
| Completeness ceiling | Bounded by rule set and build context | The same theoretical ceiling |
**The discovery-method choice** is the five surfaces from the previous section, and the honest summary bears repeating: each is genuinely strong somewhere and genuinely blind somewhere else, and none is complete alone. Static analysis owns your source; binary analysis owns your firmware; passive monitoring owns live traffic; probing owns external posture; certificate scanning owns the PKI. The right answer is never "pick one." It is "run several and merge."
> **Note:** There is no independent, peer-reviewed benchmark that ranks these schemas or tools by recall and precision on a shared corpus of real systems. The comparisons above are by design and coverage profile, not by measured performance numbers -- and any vendor deck that quotes a precise detection percentage is quoting itself. Treat coverage claims as architecture, not as evidence.
Every one of these choices trades coverage for cost, or specialization for breadth, and not one of them escapes a deeper problem they all share. Whatever schema you standardize on and whatever tools you buy or build, there is a hard limit on how complete your inventory can ever be -- and, with unsettling symmetry, a second hard limit on how much of your cryptography you can rotate at all.
## 8. Two Ceilings the Hard Problem Cannot Lift
Here is the uncomfortable core of the whole subject -- the most important idea in this guide after the thesis itself. Complete visibility into your cryptography is not merely expensive. It is impossible. And so, separately, is complete agility. Each verb has its own independent, provable ceiling, and the two ceilings have different shapes. Ask the budget question directly: with unlimited money and every tool on the market, could you reach 100 percent? No -- and the reasons you cannot are not the same for the two halves.
**The SEE ceiling is undecidability.** The question at the center of discovery is not the tidy one it first appears. What a scanner must answer, for arbitrary deployed code, is *does this program use cryptographic primitive C somewhere inside it?* -- think of a network daemon that happens to call AES while going about its ordinary work. That is the operative question, and it is provably unanswerable in general.
So is its stricter cousin, *does this program compute C?* -- is the program's entire input-output behavior the AES map itself? The two are undecidable for different reasons, and keeping them apart is the difference between a slogan and a proof.
Two distinct computability results cap automated discovery. Whether a program *computes* a given primitive -- whether its input-output function is, say, the AES map -- is a non-trivial semantic property of the function the program computes, so it is undecidable directly by Rice's theorem, which holds that every non-trivial property of the function a program computes is undecidable [@rice1953]. But the question discovery actually asks -- whether a program *uses* a primitive C internally while computing something else -- is not a property of the program's external function at all, because two programs with identical outputs can differ in whether they call C. Rice's theorem therefore does not apply directly; that case's undecidability follows instead from a reduction to the halting problem. Either way, no algorithm decides it for all programs.
The applied cryptography-detection literature reaches the same wall from the practical side, and it supplies the third leg of the attribution. Gröbert, Willems, and Holz, in their 2011 RAID paper on identifying cryptographic primitives in binary programs, show that binary crypto detection is fundamentally best-effort, and that no detector defeats arbitrary obfuscation: sufficiently transformed code can be made indistinguishable from non-cryptographic code [@grobert-raid2011].
Put the three arguments together -- Rice's theorem for *computes C*, the halting-problem reduction for *uses C internally*, and Gröbert for *survives obfuscation* -- and the conclusion is firm: 100 percent automated cryptographic discovery is not achievable in the general case.The attribution is deliberately three-part. *Does P compute C?* is undecidable by Rice's theorem [@rice1953]. The operative *does P use C internally?* is a halting-problem reduction, not Rice, because it is not a property of P's external function. And *no detector defeats arbitrary obfuscation* is Gröbert, Willems, and Holz at RAID 2011 [@grobert-raid2011]. Three different arguments, one conclusion. It is not a tooling gap that a better scanner will someday close. It is a computability limit.
This is the rigorous reason automated discovery must always be paired with human validation, and it instantiates in every messy corner of a real estate -- obfuscated and packed binaries, hand-rolled cryptography, dynamically loaded modules, firmware and operational-technology devices with decade-long lifetimes, and third-party or SaaS systems you simply cannot reach to scan.
**The ROTATE ceiling is irreversibility.** Suppose, impossibly, you had perfect visibility. Some cryptography still cannot be rotated, because it was committed to the world in a form that cannot be recalled. RFC 7696 states the canonical case precisely: the digital signature on an intermediate certification authority certificate "is often expected to last decades, which hinders the transition away from a weak signature algorithm," and once a long-lived certificate is issued under a given algorithm, relying parties "cannot stop supporting it without invalidating all of the subordinate certificates" [@rfc7696].
The same irreversibility applies to every long-lived signature already emitted, to trust anchors and root stores embedded in devices, to firmware and hardware with parameters fixed at manufacture, and to protocols that shipped with no negotiation mechanism at all. These are not discovery failures. You can see them perfectly. The *rotate* half is simply, structurally impossible for them after the fact.
flowchart TD
PQM[Post-quantum migration] --> SEE["SEE, run-time inventory"]
PQM --> ROT["ROTATE, design-time agility"]
SEE --> U["Ceiling, undecidability (halting reduction, Rice's theorem, RAID 2011)"]
ROT --> I["Ceiling, irreversibility (RFC 7696 section 2.6)"]
U --> UEX["Obfuscated binaries, hand-rolled crypto, SaaS opacity"]
I --> IEX["Long-lived signatures, trust anchors, firmware"]
The undecidability ceiling is easy to feel with a five-line example. A naive static detector greps for a known cipher name. It catches the direct call and misses the identical algorithm the moment the name is assembled at runtime.
{`
// Pedagogical illustration, not a proof and not production.
// A naive static detector: it scans source for a known cipher literal.
function naiveDetect(source) {
const known = ["aes-128-gcm", "aes-256-gcm", "chacha20-poly1305"];
return known.filter(name => source.includes('"' + name + '"'));
}
// Case 1: the algorithm is named directly. The detector sees it.
const direct = 'const c = crypto.createCipheriv("aes-128-gcm", key, iv);';
// Case 2: the SAME algorithm, selected through a name built at runtime.
const hidden = [
'const parts = ["aes", "128", "gcm"];',
'const alg = parts.join("-");',
'const c = crypto.createCipheriv(alg, key, iv);'
].join(" ");
console.log("direct ->", naiveDetect(direct)); // ["aes-128-gcm"] found
console.log("hidden ->", naiveDetect(hidden)); // [] missed
`}
A real scanner is far cleverer than this, and a determined obfuscator is far cleverer still. The demo is not a proof of undecidability -- it is a picture of why the problem is undecidable: any fixed detector can be evaded by a program that constructs its cryptography in a way the detector does not model.
> **Note:** A certificate scan is not a cryptographic inventory. Neither is a network scan. Each sees exactly one surface -- the PKI, or the wire -- and even the union of all five surfaces is provably bounded below complete coverage. Anyone who hands you a single-surface scan and calls it "our crypto inventory" has confused a slice for the whole.
So the attainable optimum is not a complete inventory and never was. It is a high-coverage, multi-surface, human-validated approximation whose residual incompleteness is acknowledged rather than hidden.You can push coverage upward asymptotically by adding surfaces and manual review, but never to a *proven* 100 percent. The mature deliverable is therefore bounded assurance -- a statement of how thoroughly you looked -- not a bare list that silently claims a completeness it cannot possibly guarantee. Coverage rises toward the ceiling; it never touches it.
If completeness is provably out of reach, then the goal cannot be a bare list that claims a coverage it cannot back. It has to be *bounded assurance*: a statement of which surfaces were scanned, with which tools, under which caveats. Building that -- along with everything else this young discipline has not finished -- is where the live research sits.
## 9. Where the Research and Standardization Are Still Live
The substrate exists and the deadline is fixed, but the discipline is young, and several load-bearing pieces are still under construction. The question that organizes the frontier is simple: what has to be solved before a CBOM can be trusted the way a mature SBOM is trusted today?
**Trustworthy attestation of completeness is the flagship open problem.** A CBOM asserts what a set of tools *found*. Nothing in it attests to what they *missed* -- and the previous section proved that what they miss can never be driven to zero. So a consumer of your CBOM needs something more honest than a list: *bounded assurance*, a signed statement of how far the inventory was actually pushed.
Concretely, a standard completeness-attestation profile would pin down four minimum elements: **surface coverage** (which of the five discovery surfaces were actually run against this target, and which were not); **tools and versions** (which discovery tools, at which versions and rule packs, since a surface's recall is bounded by the specific catalog it matches against); **coverage and exclusion caveats** (unscanned repositories, un-executed binary paths, unsupported languages, unreachable air-gapped or SaaS systems, the scanned-without-build-context case); and **residual manual-validation scope** (what a human reviewed, and what still awaits review).
The striking part is that the plumbing to carry all four already ships. CycloneDX Attestations (CDXA) landed in the same v1.6 line as CBOM, providing machine-readable "attestations to the veracity and completeness of those claims" [@owasp-cdx16] [@cdx-attestations].
Its object model maps onto the profile almost one-to-one: a top-level `declarations` object whose `targets` name the CBOM the claim is about; `claims` that each carry a `predicate` (for example, "all five surfaces scanned for target T"), its `reasoning`, linked `evidence`, and -- decisively -- `counterEvidence`, the schema's native field for *what undercuts the claim*, which is exactly where the blind spots the last section says can never be zero would be recorded; `evidence` items with `created` and `expires` timestamps, which also give an inventory's assurance an explicit shelf-life; and `assessors` carrying a `thirdParty` boolean that separates self-assessment from an independent audit, the whole declaration closed with an `affirmation` and an enveloped `signature` [@cdx-16-json].CDXA already carries completeness claims: `claims.counterEvidence` records what undercuts a claim, and `evidence.expires` gives the assurance a shelf-life [@cdx-16-json]. So the gap is a missing standard *profile* -- an agreed catalog of which claims a CBOM must assert -- not missing plumbing.
So the gap is not missing machinery; it is a missing *standard profile* -- an agreed, named set of claims a CBOM must assert to count as completeness-attested -- plus the absence of any shared, peer-reviewed benchmark against which a tool's recall and precision could be measured.The absence of a public discovery benchmark is why no honest vendor can quote you a real recall number. There is no shared corpus of representative systems with a known ground-truth inventory to measure against, so "we detect 98 percent of cryptography" is, at present, an unfalsifiable claim rather than a measured result.
> **Note:** The most consequential unsolved problem in cryptographic inventory is not building a more powerful scanner. It is being able to state, verifiably, how thorough a given inventory is. Bounded assurance -- an honest account of coverage and its gaps -- is worth more to a downstream consumer than a longer list that silently overclaims what it saw. Attestation is the direct answer to the undecidability ceiling.
**Four more problems are visibly in motion.** *Schema convergence:* ACDI tools still emit tool-specific shapes, and CBOM and SPDX 3.0 coexist with no agreed crosswalk between their cryptographic representations [@ibm-cbom] [@spdx-spec]. A real crosswalk is not a field-rename -- it has to preserve crypto-asset identity, the family-versus-variant distinction, and the dependency semantics, so that CycloneDX's `provides` and `dependsOn` edges are not flattened into a mapping that collapses "this library *contains* X" into "this application *uses* X" [@cdx-16-json].
*Continuous versus point-in-time inventory:* a CBOM is stale the instant code ships, a certificate rotates, or traffic shifts; continuous inventory is practical for source and network surfaces and much harder for binary, firmware, and SaaS, so most inventories today are snapshots that begin aging immediately.
*Correlation to business context:* "AES-128-GCM at file X, line 51" does not tell you which service depends on it, which data it protects, or how long that data must stay secret -- yet that is precisely the input $x$ and the business priority that Mosca's inequality needs, so the gap between a technical finding and a risk decision is still bridged by humans.
*Supply-chain propagation:* most of an application's cryptography lives in its transitive dependencies, and while the data model supports composition -- via BOM-Link references between documents, enveloped signatures for provenance, and merge and de-duplication keyed on a stable identity such as OID plus package URL plus `bom-ref` -- the practice of publishing, signing, and merging upstream CBOMs the way SBOMs are beginning to flow is still nascent [@cdx-16-json].
**And one problem loops straight back to the theory.** Signature- and rule-based detectors recognize only cryptography they already have a rule for. Early post-quantum hybrids, experimental constructions, and hand-rolled primitives evade the catalog -- which is the undecidability ceiling of the previous section wearing everyday clothes [@grobert-raid2011]. Taken together, these open problems share a theme: the model for cryptography is settled, and the practices that make the model trustworthy, current, and composable are still being written.
None of this is a reason to wait, because the deadline will not. The research frontier and the compliance clock run in parallel, which means the practitioner's job is not to wait for the discipline to mature. It is to build the best inventory achievable now, bound it honestly, and improve it continuously. Here is how to start this quarter.
## 10. Doing It This Quarter
Strip away the theory and the policy, and a concrete, deadline-aware workflow remains -- one any team on the 2030 hook can start now. Five steps, each tied to one of the two verbs.
**Step 1 -- Build agility in (ROTATE, forward).** For everything you build from here on, apply the RFC 7696 patterns: put an indirection layer between your application and its cryptography, use registered algorithm identifiers, hardcode no primitives, and keep your mandatory-to-implement set in a companion configuration so it can change without a rebuild [@rfc7696]. Done well, the eventual post-quantum swap becomes a configuration change rather than a re-architecture. This step does not touch your legacy estate -- it stops that estate from growing.
**Step 2 -- Run multi-surface discovery (SEE).** Not one tool. A mix, matched to the surfaces from earlier: a static scan of owned source in continuous integration with CBOMkit-Hyperion and its Sonar Cryptography plugin [@sonar-crypto] [@ibm-cbomkit-blog]; a binary and container scan with CBOMkit-Theia for third-party artifacts and firmware [@cbomkit]; passive network monitoring for live ground-truth; active probing for an external capability census; and certificate and key-store scanning first if you are triaging the 2031 signature deadline. Then budget a permanent manual-validation line item for the residual the tools cannot reach -- because, as established, that residual never reaches zero [@nextgov-cisa].
**Step 3 -- Emit a CBOM (SEE, substrate).** Roll the merged findings into a CycloneDX CBOM of the current line -- CBOM was introduced in v1.6 and carried into v1.7 -- validate it, and store it as an artifact right next to your SBOM [@owasp-cdx16] [@cdx-spec-17]. Version it over time so you can diff this quarter against last, and keep the history in a repository such as CBOMkit-Mnemosyne [@cbomkit].
**Step 4 -- Prioritize (SEE to decision).** Run Mosca's inequality over the graph. Rank by harvest-now-decrypt-later exposure and timing, $x + y > z$, and map the result onto the mandated dates: confidentiality and key establishment toward December 31, 2030, signatures toward December 31, 2031 [@gri-mosca] [@eo14412]. The output is a queue, not a wish list.
**Step 5 -- Migrate to algorithms that already ship (ROTATE, execute).** The endpoints of the queue are the subject of the companion posts in this series: [ML-KEM arriving in a `pip install`](/blog/the-thirty-year-migration-ships-in-a-pip-install-how-post-qu/), [ML-KEM and ML-DSA in Windows SChannel and SymCrypt](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/), and the [twenty-year SChannel algorithm-agility story](/blog/rotating-every-cipher-schannel-and-the-twenty-year-algorithm/) that shows the rotate half working at scale in one real TLS stack. The replacement primitives are finished and shipping -- FIPS 203, 204, and 205 since August 2024 [@fips203] [@pyca-changelog] [@ms-pqc-windows]. The entire stack above exists to produce the prioritized list those endpoints execute against.
flowchart TD
A[Build agility into new code] --> B[Run multi-surface discovery]
B --> C[Emit and validate a CycloneDX CBOM]
C --> D{"x + y exceeds z?"}
D -->|yes| E[Migrate now to shipping PQC algorithms]
D -->|no| F[Queue and keep monitoring z]
E --> G[Re-scan and version the CBOM]
F --> G
| Step | Method | Effort | Best suited for |
|---|---|---|---|
| Build agility in | RFC 7696 patterns in new code | Design-time, low ongoing | Greenfield and active codebases |
| Discover owned source | Static scan in CI (Hyperion / Sonar) | Low, continuous | Code you wrote |
| Discover third-party and firmware | Binary and container scan (Theia) | Medium | Artifacts you did not build |
| Discover live traffic | Passive network plus active probing | Medium | Ground-truth and external posture |
| Discover the PKI | Certificate and key-store scan | Low | The 2031 signature deadline |
| Prioritize | Mosca's inequality over the CBOM | Low | Ordering the migration queue |
| Migrate | Adopt shipping PQC (companion posts) | High | The assets the queue surfaces first |
> **Note:** If you remember a single operational rule, make it this: run a mix of surfaces, roll the results up into one CBOM, and validate the residual by hand. Every common failure in this space is a shortcut around that rule -- trusting one tool, one surface, or one snapshot.
The pitfalls are predictable, and each is a shortcut past something earlier in this guide. Scanning Java source without building it leaves symbols unresolved and findings incomplete, exactly as CBOMkit's documentation warns [@cbomkit]. Treating a certificate scan, or a network scan, as a finished inventory mistakes one surface for the estate. Collapsing family into variant -- recording "AES" instead of "AES-128-GCM" -- throws away the property that makes a finding actionable [@ibm-cbom]. Losing the `implements` versus `uses` distinction flattens the graph back into a list. And citing a stale CycloneDX version number invites a reviewer to distrust the rest.
A concrete starting move, before any of the harder surfaces: build one representative service, run a static CBOM scan of it in your CI pipeline with CBOMkit-Hyperion and the Sonar Cryptography plugin, and commit the resulting CycloneDX CBOM next to that service's SBOM [@sonar-crypto]. You will have a real, validated, versioned crypto inventory for one service by Friday -- and a template for the next hundred. Start where you have source and build context, because that is the surface where the tools are strongest.
Do all five steps and you have converted an impossible-sounding mandate into a bounded, prioritized, machine-actionable program -- and, in the process, confronted the one truth the whole field converged on. That truth is worth stating plainly, alongside the misconceptions that keep tripping teams up.
## 11. Misconceptions, Questions, and the One Truth
Almost every misconception in this space is a shortcut past one of the two verbs. "Post-quantum cryptography is the hard part" skips the SEE half -- the new algorithms are finished and shipping [@fips203] [@pyca-changelog] [@ms-pqc-windows]; discovery is the bottleneck. "CBOM is a separate schema from CycloneDX or the SBOM" misreads the substrate -- it is the v1.6 extension of the same document, and can live in the same file [@owasp-cdx16].
"SP 1800-38 is a finalized NIST standard" over-reads a preliminary draft [@sp1800-38-guide]. "Executive Order 14412 binds everyone" over-reads its scope -- federal agencies and covered contractors are mandated, critical infrastructure is encouraged, and EO 14412 is not EO 14413 [@eo14412]. "We can just scan the network" trusts one surface for the whole estate. And "a spreadsheet of our certificates is a cryptographic inventory" mistakes a stale, single-surface document for a machine-actionable, dependency-aware graph. Each error is a verb half-done.
No. FIPS 203, 204, and 205 were standardized in August 2024 [@fips203], and ML-KEM is now a `pip install` away and built into Windows [@pyca-changelog] [@ms-pqc-windows]. The binding constraint is discovering where the quantum-vulnerable algorithms already live across your estate. You cannot rotate what you cannot see.
No. The Cryptography Bill of Materials is an extension of the same CycloneDX BOM document, introduced in v1.6 in April 2024 [@owasp-cdx16]. A CBOM can live in the same file as your SBOM, produced and consumed by the same tools [@ibm-cbom].
No. It is a preliminary, initial public draft NCCoE practice guide [@sp1800-38-guide]. Use it for its discovery reference architecture, which is genuinely useful, but state its draft status rather than citing it as a finalized standard.
Only if you are a federal agency or a covered federal contractor; critical infrastructure operators are encouraged, not mandated [@eo14412]. Note also that EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks") is not EO 14413, a separate order on quantum innovation [@eo14412].
No. Passive and active network discovery see only cryptography that transits an observed link. They miss data at rest, embedded and operational-technology devices, internal-only applications, and SaaS you cannot reach. A network scan is one surface, not an inventory.
Not a maintainable one. It is stale the moment it is written, it is not machine-actionable, it cannot be prioritized as a graph, and a certificate list sees only the public-key infrastructure surface. A CycloneDX CBOM is the machine-actionable substitute [@ibm-cbom].
No, and not because the tools are immature. Complete automated cryptographic discovery is undecidable in general: the operative question -- whether a program *uses* a primitive internally -- reduces to the halting problem, and Gröbert, Willems, and Holz (RAID 2011) show no detector defeats arbitrary obfuscation. So manual validation is a permanent complement, and the honest deliverable is bounded assurance [@grobert-raid2011] [@nextgov-cisa].
So here is the whole argument in one breath. Post-quantum migration is two verbs, not one. You must be able to ROTATE your cryptography, and you must be able to SEE where it all lives. The replacement algorithms are finished and shipping -- FIPS 203, 204, and 205 since August 2024 [@fips203], a `pip install` away and built into Windows [@pyca-changelog] [@ms-pqc-windows] -- yet the 2030 and 2031 deadlines are hard [@eo14412]. The field completed the ROTATE lineage decades before it closed the SEE lineage: rigidity gave way to negotiation, negotiation hardened into RFC 7696, and RFC 7696 was restated as national risk-management guidance in NIST CSWP 39 [@rfc7696] [@cswp39] -- while the inventory half sat unsolved through the spreadsheet era until a 2022 mandate forced it open, automated discovery gave it scale, and CBOM finally gave it a data model [@omb-m2302] [@ibm-cbom]. CBOM is where the two verbs meet: cryptography modeled as a first-class, machine-readable, dependency-aware asset, now named in federal law [@eo14412].
And the two ceilings keep the claim honest. Undecidability caps what you can see; irreversibility caps what you can rotate [@grobert-raid2011] [@rfc7696]. So the mature goal is never a bare 100 percent. It is bounded assurance for the seeing, and structural honesty about the un-rotatable. The algorithms, it turns out, were the easy part.
The algorithms were the easy part. You cannot rotate what you cannot see.