You Cannot Rotate What You Cannot See: Crypto-Agility and the Cryptographic Bill of Materials

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 ^[1]. 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 ^[1].

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" ^[2]. 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 ^[3]. 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 ^[4].

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 ^{[5] [6]}, 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.

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 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 ^[7]. 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" ^[8]. Swapping a cipher meant revising the protocol itself.

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" ^[8]. 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" ^[8]. 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" ^[9]. 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 ^[9].

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 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" ^[8]. 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" ^[8], 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" ^[10], steering two peers who both support strong Diffie-Hellman down to a key size a well-resourced attacker can break ^[11]. FREAK and POODLE are cousins in the same family ^{[12] [13]}.

Second, negotiation encourages ossification: because dropping an option can break some peer somewhere, "flawed algorithms are supported for far too long" ^[8] -- which is exactly why retiring RC4 needed its own prohibiting standard ^[9].

Third, every additional negotiable option is additional attack surface and additional code to get right ^[8].

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 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.

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 ^[8]. 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" ^[8]. Integrity-protect your negotiation so it cannot be downgraded ^[8].

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" ^[8]. 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.

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 ^[15]. 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 ^[1]. 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" ^[2]. 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 ^[2]

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" ^[16]. 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 ^[17].

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.

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.

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 ^[14]. 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 ^[19]. 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 ^[2]. 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 ^[2]. 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" ^[2]. A report of "AES" is not actionable. "AES-128-GCM at file X, line 51" is.

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)" ^[2]. 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.

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" ^[20]. 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.

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);
}

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 ^[14]

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 ^[22]. 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" ^[14]. 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 ^[23]. 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 ^[23].

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 ^{[24] [22]}. 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 ^[25]. 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.

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]

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 ^{[24] [22]}. SHA-256 normalizes to the OID 2.16.840.1.101.3.4.2.1, in the NIST Computer Security Objects Register arc ^[26]. ※ 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 ^[26].

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 ^[27].

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 ^[28].

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.

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 ^[3]. 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 ^[16]; 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 ^{[17] [31]}; 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" ^[3]. 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 ^[33]. 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 ^[34]. ※ 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 ^[2].

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 ^[3]. 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.

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) ^{[25] [22]}. 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" ^[25].

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.

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."

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.

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 ^[27].

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 ^[35]. 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 ^[27]. 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" ^[8].

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.

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" ^{[14] [37]}.

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 ^[38]. ※ CDXA already carries completeness claims: claims.counterEvidence records what undercuts a claim, and evidence.expires gives the assurance a shelf-life ^[38]. 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.

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 ^{[2] [33]}. 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" ^[38].

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 ^[38].

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 ^[27]. 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 ^[8]. 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 ^{[24] [22]}; a binary and container scan with CBOMkit-Theia for third-party artifacts and firmware ^[25]; 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 ^[36].

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 ^{[14] [19]}. Version it over time so you can diff this quarter against last, and keep the history in a repository such as CBOMkit-Mnemosyne ^[25].

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 ^{[30] [3]}. 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, ML-KEM and ML-DSA in Windows SChannel and SymCrypt, and the twenty-year SChannel algorithm-agility story 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 ^{[4] [5] [6]}. 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

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 ^[25]. 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 ^[2]. 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.

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 ^{[4] [5] [6]}; 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 ^[14].

"SP 1800-38 is a finalized NIST standard" over-reads a preliminary draft ^[17]. "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 ^[3]. "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.

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 ^[4], a pip install away and built into Windows ^{[5] [6]} -- yet the 2030 and 2031 deadlines are hard ^[3]. 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 ^{[8] [23]} -- 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 ^{[1] [2]}. CBOM is where the two verbs meet: cryptography modeled as a first-class, machine-readable, dependency-aware asset, now named in federal law ^[3].

And the two ceilings keep the claim honest. Undecidability caps what you can see; irreversibility caps what you can rotate ^{[27] [8]}. 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.