Parag Mali - tag: crypto-agility

How the Whole Stack Would Break: SIDH, Correlated Assumptions, and the Cryptography We Are Betting the Next Thirty Years On

noreply@paragmali.com (Parag Mali) — Sun, 19 Jul 2026 00:00:00 GMT

The security of the post-quantum stack is not the hardness of any single algorithm -- **none of them is proven hard**. It is a deliberately *uncorrelated* portfolio: lattice (ML-KEM, ML-DSA, Falcon), hash (SLH-DSA), and code (HQC, Classic McEliece), chosen so a break of one family leaves the others standing. Shor was the original correlated failure -- factoring and discrete log fell together because they were one bet -- and the 2022 SIDH/SIKE collapse (classical, about ten minutes, no warning) proved a well-vetted family can still vanish overnight. This capstone maps where the surviving bets are genuinely correlated (the lattice cluster, the Module-LWE pair at its center) and argues that, for a science that can prove nothing hard, diversity is the entire defense.

1. Nine Teardowns, One Question

In late July 2022, a key-exchange scheme that had survived eleven years of public cryptanalysis was broken. Not by a quantum computer. Not gradually. It fell on a single laptop core in about ten minutes, using a theorem from pure mathematics published in 1997 [@castryck-decru-2022]. The scheme was SIKE, the instantiation of SIDH first proposed in 2011 [@jao-defeo-2011], and just three and a half weeks earlier NIST had promoted it to the fourth and final round of its post-quantum standardization effort for continued study [@nist-2022-selection].

Read the status carefully, because the precise words carry the whole point. SIKE was never a standard. It was a Round-4 alternate candidate, still under evaluation, key-recovered before any selection was made [@ir-8413]. That makes the collapse worse, not better: this was cryptography failing while under the most intense scrutiny our field knows how to apply.

Two or more cryptographic primitives that fail together because they secretly depend on the same piece of mathematics. The schemes look independent -- different names, different standards, different teams -- but a single advance takes all of them at once. It is the failure mode a diverse portfolio exists to prevent.

This series has spent nine articles taking post-quantum primitives apart one at a time: how ML-KEM would break, how ML-DSA would break, how each candidate meets its mathematical limit. This final part does what none of the nine could do alone: it steps back and asks whether they fail independently. Because a stack is not nine separate bets that each has to be strong. It is one system, and its real question is whether two of those bets might secretly be the same bet.

Key idea: A cryptosystem is a wager that one math problem is hard. A cryptographic stack is a portfolio of such wagers -- and the only thing that ultimately matters is whether the wagers are correlated. The stack is secure not because any assumption is proven hard (none is), but only to the degree that a break of one leaves the others standing.

That is the lens for everything below -- a sentence you will earn by the end.

A cryptographic stack is a portfolio of bets -- and the only thing that ultimately matters is whether the bets are correlated.

Before we map the stack, one boundary. The break we just described was structural: an attack on SIDH's own mathematics, not on a buggy implementation of it.SIDH is not CSIDH. SIDH collapsed classically in 2022; CSIDH is a separate isogeny construction that survives, with its own separately-contested quantum security -- Kuperberg's algorithm applies to CSIDH, never to lattices [@kuperberg-2005]. Never let one family's obituary be read as the other's. That distinction is the boundary every section below holds to.

This capstone analyzes only structural cryptanalysis -- attacks on an algorithm's own mathematics. Side channels, fault and power attacks, implementation bugs, weak randomness, and protocol misuse are real, often easier, and equally capable of sinking a deployment -- but they are a different surface, owned by the sibling track *How It Breaks in Real Life*. One clarification for the quantum question: Shor's algorithm counts as structural math and is in scope; Grover's generic search is not a structural break, and it is named once later, then set aside.

The thirty-year story we are about to trace is a spiral, not a line. Three times the field concentrated its security onto one kind of mathematics, and three times a shock forced it to spread out again.

flowchart LR A["1978 McEliece: the first code-based bet"] --> B["1994 Shor: two bets share one spine"] B --> C["2005 LWE: the lattice core arrives"] C --> D["2016 NIST competition: five families enter"] D --> E["2022 SIDH collapses, classically"] E --> F["2024 FIPS 203, 204, 205 published"] F --> G["2025 HQC selected as the code hedge"]

To answer whether the new bets are correlated, we first have to understand the last time they were -- the one moment when a single idea took the entire classical stack at once.

2. Shor: The Original Correlated Failure

For twenty years the field slept soundly because breaking RSA seemed to say nothing about breaking elliptic-curve cryptography. That comfort was an illusion -- the most important one to understand here, because the entire post-quantum project is an attempt not to fall for it twice.

The numbers told a reassuring story. The best classical attack on RSA was the general number field sieve, with a sub-exponential running time; the best classical attack on elliptic curves was Pollard's rho, a square-root method [@gnfs-pollard]. Two problems, two unrelated algorithms, two independent-looking bets. If someone found a faster way to factor, elliptic curves would be untouched, and vice versa. Diversify across both and you were doubly safe -- or so the reasoning went.

The foundation of all public-key cryptography: security rests on the belief that some specific problem -- factoring a 2048-bit number, recovering a short lattice vector -- is too expensive to solve on average, for anyone, with any known method. The operative word is *belief*. "Nobody has broken it yet" is evidence, not a proof; almost nothing in cryptography is proven hard.

Then, in 1994, Peter Shor showed that both bets were the same bet. His polynomial-time quantum algorithm solved integer factoring and discrete logarithm, because underneath their different surfaces both are instances of a single mathematical object: the abelian hidden-subgroup problem [@shor-1994]. Find the hidden periodic structure and you have solved the factoring instance, the discrete-log instance, and the elliptic-curve instance alike.

A general problem about finding hidden periodic structure in a function defined over an abelian (commutative) group. Integer factoring and discrete logarithm are both special cases of it. Shor's 1994 algorithm solves the abelian HSP in polynomial time on a quantum computer, which is why one result dissolved two problems that looked entirely unrelated. flowchart TD RSA["RSA: integer factoring"] --> HSP{"Abelian hidden-subgroup problem"} ECC["ECC: discrete logarithm"] --> HSP HSP --> SHOR["Shor, 1994: polynomial-time quantum HSP"] SHOR --> Z1["RSA falls"] SHOR --> Z2["ECC falls"]

This is the template for everything this article fears. Two primitives can each be individually strong -- decades of failed attacks, careful parameter choices, universal deployment -- and still fall together, in one stroke, because their strength was never really two separate things.

Note: RSA and elliptic-curve cryptography were never two bets. They were one bet on the abelian hidden-subgroup problem, wearing two costumes. The security question was never "is each algorithm strong?" It was always "do the algorithms secretly share a spine?" Strength is measured per algorithm; failure is measured per assumption.

Two honest caveats keep this precise. First, Shor's algorithm needs a large, fault-tolerant quantum computer that does not yet exist; its threat is future, not present, and it does not threaten any of the lattice, code, or hash schemes we will meet below.Grover's algorithm is the other quantum result people cite. It gives only a generic quadratic, $2^{n/2}$, speedup for unstructured search -- effectively halving a symmetric key's strength, so a 256-bit key still offers about 128 bits against a quantum attacker [@grover-1996]. That is absorbed by larger parameters, not a structural break, and the last we will say of it. Second, the reason Shor matters here is historical, not technical: it is the event that created the field. The looming "Q-Day," when a quantum computer runs Shor at scale, is precisely the correlated failure that made everyone go looking for replacements.

If the lesson of Shor is that independent-looking bets can share a hidden spine, then the obvious first move after 1994 -- just swap RSA and elliptic curves for one quantum-safe algorithm -- walks straight back into the same trap.

3. The Naive Swap Rebuilt the Single Point of Failure

The first instinct after Shor was the worst one: treat it as a component swap. Rip out RSA and elliptic curves, find one quantum-safe replacement, and declare victory. The instinct is understandable -- engineers replace broken parts every day -- but it is exactly the mistake the correlation lens tells you to avoid.

The raw material was already on the shelf. The candidate problems with no exploitable abelian-HSP structure had existed for decades: McEliece's code-based cryptosystem from 1978 [@mceliece-1978], Merkle's hash-based signatures from 1979 [@merkle-1979], the NTRU lattice system from 1998 [@ntru-1998], and Regev's Learning With Errors problem from 2005, which would become the workhorse of the entire modern stack [@regev-lwe-2005]. Any of them could resist Shor. The temptation was to pick the most efficient one and standardize it alone.

A deployed stack whose security, however many algorithms it contains, ultimately rests on a single hard-problem family. Like a field planted with one genetic strain, it can look healthy right up until a single blight -- one mathematical advance -- takes all of it at once.

Here is why a single replacement is not a fix but a relocation of the risk. Shor did not punish RSA for being weak; it punished the stack for concentrating on one kind of mathematics. Swap in a lone lattice scheme and you have rebuilt precisely that: a monoculture with a new problem underneath, one advance away from total failure. You did not escape the Shor pattern. You reissued it.

To be honest about the epistemics: no paper proves the theorem "monocultures always fail." This is a design argument, and its evidence is circumstantial rather than deductive -- the Shor precedent behind us, and, as we will see, the collapses of SIKE and Rainbow still ahead.

The people who saw it earliest said so in plain terms. Daniel Bernstein and Tanja Lange argued for years that committing to a single system courts a "cryptographic monoculture," and built NTRU Prime partly as a standing objection to it [@ntruprime-diversity]. That position, once a minority view, is the intellectual seed of everything NIST eventually did.

Because NIST did not swap. It ran a competition.

When NIST opened its post-quantum project in 2016, 82 submissions arrived and 69 were accepted into the first round, spread across five mathematical families: lattice, code, hash, multivariate, and isogeny [@ir-8240; @nist-pqc-project]. The breadth was the substance, not the packaging. An open competition across unrelated hard problems is, structurally, a search for a *set* of uncorrelated bets -- even before anyone attached that language to it.

Note: The deepest design lesson of the post-Shor era is counterintuitive: a standardization effort should not try to crown the single best algorithm. It should assemble a diversified set whose members would have to fail for independent reasons. A lone "winner" is a monoculture waiting to happen.

NIST bet on breadth -- five families, an open process, trust earned by attrition. But breadth on paper is not diversity in fact. A competition can start with five families and still funnel almost all of its real-world weight onto one of them. To see whether that happened, you have to stop reading the roster and start reading the map -- exactly what the survivors ended up standing on.

4. The Map of What Rests on What

Here is the uncomfortable picture, drawn as a map. Take the standardized and selected post-quantum stack, ignore the marketing names, and color each scheme by the hard problem it actually rests on. Where is the concentration?

The modern public-key primitive for agreeing on a shared secret. Rather than encrypting a chosen message, the sender *encapsulates* a fresh random key against the recipient's public key, producing a ciphertext; the recipient decapsulates it to recover the same key. ML-KEM, HQC, and Classic McEliece are all KEMs.

Six schemes carry the weight. ML-KEM (FIPS 203) is a lattice KEM whose security is tied to Module-LWE at modulus q = 3329 [@fips-203]. ML-DSA (FIPS 204) is a lattice signature resting on Module-LWE and Module-SIS at modulus q = 8380417 [@fips-204]. Falcon (draft FIPS 206) is a lattice signature too, but on the NTRU short-vector problem rather than Module-LWE [@ntru-1998].

SLH-DSA (FIPS 205) is a signature whose security reduces entirely to the strength of a hash function [@fips-205]. Classic McEliece rests on decoding random binary Goppa codes [@mceliece-1978], and HQC -- selected by NIST in March 2025 -- rests on decoding quasi-cyclic codes [@ir-8545].

flowchart TD subgraph Lattice MLKEM["ML-KEM on Module-LWE"] MLDSA["ML-DSA on Module-LWE plus Module-SIS"] FAL["Falcon on the NTRU lattice"] end subgraph Hash SLH["SLH-DSA on hash security only"] end subgraph Code HQC["HQC on quasi-cyclic decoding"] MCE["Classic McEliece on binary-Goppa decoding"] end MLKEM -.->|shared Module LWE assumption| MLDSA The hard problem underneath both ML-KEM and ML-DSA. Informally it is noisy linear algebra over structured (module) lattices: you are shown many linear equations whose right-hand sides have each been nudged by a small random error, and asked to recover the secret. "Module" is the middle setting between fully unstructured LWE (slow but conservative) and fully structured Ring-LWE (fast but more algebraic surface for an attacker to grab).

The map makes one fact impossible to miss: three of the six schemes stand on lattices. That concentration is not an accident. It is the payoff of a twenty-year efficiency arc -- Ajtai's 1996 worst-case-to-average-case reduction [@ajtai-1996], Regev's LWE in 2005 [@regev-lwe-2005], Ring-LWE's dramatic size reductions in 2010 [@ring-lwe-2010], and the Module-LWE middle ground in 2015 [@module-lwe-2015] that Kyber and Dilithium adopted in 2017 to become today's ML-KEM and ML-DSA [@kyber-2017; @dilithium-2017]. Lattices won the efficiency argument, and that is why they became the core.

But notice the precise shape of the correlation, because misstating it is the single most common error about this stack. ML-KEM and ML-DSA are the genuinely correlated pair: both rest on Module-LWE. That does not mean any attack on one instantly breaks the other. They use different parameters -- different moduli (3329 versus 8380417), different module ranks,The rank is roughly how many ring elements stack into the secret vector; a higher rank means a harder instance and a larger key. different noise -- so a parameter-specific attack need not transfer, and ML-DSA carries an additional Module-SIS assumption that ML-KEM does not [@fips-204].

What they share is the assumption family. A generic, structural advance against Module-LWE would reach both at once; a narrow trick tuned to one parameter set might reach neither.Falcon is NTRU, not Module-LWE -- a third and structurally distinct lattice bet, and the least conservative of the three because its NTRU lattices carry extra algebraic structure. It is also the one still unfinished: draft FIPS 206 (FN-DSA) remained unreleased as of this writing [@nist-pqc-project].

You can turn that observation into a two-line audit. Do not count algorithms; count assumptions.

{` // Map each deployed scheme to the hard problem it truly rests on. const assumption = { 'ML-KEM-768': 'lattice', 'ML-DSA-65': 'lattice', 'Falcon-512': 'lattice', 'SLH-DSA-128s': 'hash', 'HQC-128': 'code', 'Classic-McEliece': 'code' };

// A stack is only as diverse as its set of DISTINCT assumptions. function auditStack(schemes) { const families = new Set(schemes.map(function (s) { return assumption[s]; })); console.log('Deployed: ' + schemes.join(', ')); console.log('Distinct assumption families: ' + Array.from(families).join(', ')); if (families.size === 1) { console.log('WARNING: monoculture. One advance against ' + Array.from(families)[0] + ' takes the whole stack.'); } else { console.log('OK: a break must cross ' + families.size + ' unrelated families to take everything.'); } }

auditStack(['ML-KEM-768', 'ML-DSA-65', 'Falcon-512']); // looks diverse, is not auditStack(['ML-KEM-768', 'SLH-DSA-128s', 'HQC-128']); // lattice + hash + code `}

The first stack has three different algorithm names and one assumption. The second has three names and three assumptions. Only the second is a portfolio.

Key idea: The map is the thesis. Every scheme sits in exactly one assumption band -- lattice, hash, or code -- and every break lives in a band too. To take the whole stack down, a single break would have to cross bands, reaching mathematics unrelated to where it started. Diversity is not decoration on top of the security argument. It is the security argument.

The map, laid out precisely, and the five generations of thinking that produced it:

Scheme (standard)	Role	Family	Specific assumption	Best-known attack	Representative size	Correlation group
ML-KEM (FIPS 203)	KEM workhorse	Lattice	Module-LWE, q = 3329	Lattice sieving / BKZ [@core-svp]	~1 KB public key	Lattice core
ML-DSA (FIPS 204)	Signature workhorse	Lattice	Module-LWE + Module-SIS, q = 8380417	Lattice sieving / BKZ [@core-svp]	~3 KB signature	Lattice core (paired)
Falcon (draft FIPS 206)	Compact signature	Lattice	NTRU short vector	Lattice sieving / BKZ [@core-svp]	sub-kilobyte signature	Lattice (distinct)
SLH-DSA (FIPS 205)	Conservative signature	Hash	Hash preimage / collision resistance	Generic hash attacks	several to tens of KB signature	Hash anchor (uncorrelated)
HQC (NIST IR 8545)	KEM hedge	Code	Quasi-cyclic syndrome decoding	Information-set decoding [@bjmm-2012]	few-KB public key	Code hedge
Classic McEliece (ISO-track) [@classic-mceliece-iso]	KEM deep hedge	Code	Binary-Goppa syndrome decoding	Information-set decoding [@bjmm-2012]	0.26-1.36 MB public key [@classic-mceliece-site]	Code hedge

Generation	Era	What we bet on	How we avoided concentrating	Why it was superseded
Number-theoretic monoculture	pre-1994	Factoring and discrete log (RSA, ECC)	We did not -- two problems were believed independent	Shor: both are one abelian-HSP bet [@shor-1994]
Naive one-for-one swap	1994-2016	A single quantum-safe replacement	Not at all -- one new problem underneath	Rebuilds the monoculture Shor punished
Five-family bake-off	2016-2022	An open competition across five families	Breadth of candidates [@ir-8240]	Attrition thinned it toward a lattice-heavy core
Lattice-centric core	2022-2024	Module-LWE efficiency (ML-KEM, ML-DSA)	Partly -- hash-based SLH-DSA retained	Concentration risk: three lattice schemes
Diversified portfolio	2024-2025	Lattice, hash, and code, explicitly	Dated policy: SLH-DSA, then HQC [@ir-8545]	Current -- the correction made explicit

A map like this is only a worry until a family actually vanishes from it. That is not hypothetical. An entire family that reached NIST's Round-4 shortlist -- isogenies -- did exactly that, while sitting under the most intense scrutiny the field can muster.

5. SIDH: How a Family Vanished in an Afternoon

Return to the ten-minute break and look at exactly how it worked, because the mechanism is the warning. A scheme that survived more than a decade did not fall to a new theory, a faster computer, or a lucky guess. It fell to arithmetic that had been sitting in a 1997 journal, waiting.

SIDH's hard problem is to find a secret isogeny -- a structured map -- between two supersingular elliptic curves. That problem, taken bare, still looks hard today. But a protocol has to do more than pose a hard problem; it has to let two honest parties reach the same key. To make that possible, SIDH publishes extra data alongside its public key: the images of certain torsion points under the secret isogeny [@jao-defeo-2011]. That auxiliary information is not part of the underlying hard problem. It is a gift the protocol hands the attacker in order to function.

An isogeny is a structure-preserving map between two elliptic curves. SIDH hides its secret in a specific isogeny and dares attackers to find it. But to let two parties agree on a key, the protocol must also publish the images of certain torsion points under that secret map. Those published images are auxiliary data the bare hard problem never had to reveal -- and they are exactly what the attack fed on.

In late July 2022, Wouter Castryck and Thomas Decru showed how to weaponize that gift. They applied Kani's reducibility criterion -- a result in arithmetic geometry published in 1997 and essentially unused in cryptography for twenty-five years [@kani-1997] -- to the published torsion-point images. The criterion lets you glue the curves into a higher-dimensional abelian surface and test whether it splits, and from that test recover the secret isogeny. On SIKEp434 it ran in about ten minutes on a single classical core [@castryck-decru-2022].

sequenceDiagram participant P as Protocol participant A as Attacker P->>A: Publishes torsion-point images (required to function) A->>A: Apply Kani reducibility criterion from 1997 A->>A: Glue curves into an abelian surface, test reducibility A->>P: Recover the secret isogeny (the private key) Note over A: About ten minutes, one core, classical, not quantum

It was not a fluke of one parameter set. Within weeks, Damien Robert proved the attack runs in classical polynomial time from any starting curve, sealing the result as structural rather than patchable [@robert-2022], and Luciano Maino and Chloe Martindale generalized it while carefully bounding it away from neighboring constructions [@maino-martindale-2022].

Now sit with the three facts that make this the emotional center of the article. It was not Shor and not a quantum computer -- an ordinary laptop did it.The interval is the whole point. SIKE advanced to Round 4 on 5 July 2022 and was broken around 30 July 2022 -- roughly three and a half weeks later [@nist-2022-selection; @castryck-decru-2022]. Years of survival bought time, not safety. It was not gradual erosion -- one paper took the family from "final round" to "dead." And the vulnerability was structural from birth: SIDH published its own attack surface on day one, and the tool that read it had existed, fully public, since 1997.

Note: The attack was classical. It ran on an ordinary core using Kani's criterion, with no quantum computer anywhere in the story. And SIDH is not CSIDH: this result key-recovered SIDH and SIKE, but does not apply to CSIDH, CSI-FiSh, or SQIsign [@maino-martindale-2022]. Blaming a quantum machine, or extending the collapse to every isogeny scheme, are both wrong.

Here is the shift. Most of us treat heavy vetting as evidence of durability: if a scheme survives years of expert attack, surely it is safe. SIKE says otherwise. Vetting measures how long a family has resisted the tools people thought to try. It cannot measure the tool nobody connected yet -- and that tool can already be published, in a field the cryptographers were not reading.

The mathematics that collapses a quantum-safe family can already exist, fully published, decades before anyone connects it to the target.

If a whole family can vanish like this -- classically, in an afternoon, at the peak of its scrutiny -- then the only rational response is to never bet the stack on one. That is precisely, and deliberately, what NIST built next.

6. The Portfolio NIST Actually Built

The standardized stack is not a winner. It is a portfolio, and it was designed rather than stumbled into. Read across the three families and you can see the strategy in the shape.

The lattice pair, ML-KEM and ML-DSA, are the efficient workhorses -- small keys, fast operations, the default choice for general traffic [@fips-203; @fips-204]. Next to them sits the maximally conservative anchor: SLH-DSA, a signature whose security reduces entirely to the strength of a hash function and shares no algebraic structure with lattices at all [@fips-205]. Its lineage runs straight back to the SPHINCS stateless hash-based signature of 2015 [@sphincs-2015]. If every lattice assumption on the map fell tomorrow, SLH-DSA would not notice.

The hard problem behind code-based cryptography. Given a random-looking linear code and a corrupted codeword, recover the small error pattern that was added. That recovery is a decoding problem which has resisted efficient solution since the 1970s. HQC and Classic McEliece both rest on variants of it.

The third family is the encryption hedge. Classic McEliece has stood essentially unbroken as a structure for roughly 47 years, the deepest-studied bet on the board [@classic-mceliece-site].McEliece's conservatism has a price: its public keys run from about 0.26 MB to 1.36 MB depending on parameters [@classic-mceliece-site], roughly two to three orders of magnitude larger than ML-KEM's. That bandwidth is the price of a structure unbroken for nearly half a century. And in March 2025, NIST added HQC, a newer code-based KEM built on quasi-cyclic codes [@hqc-site], precisely to have a standardized encryption path that does not touch lattices.

Note: The clearest proof that diversity is a deliberate strategy and not an accident is the calendar. On 11 March 2025, NIST selected HQC as a second standardized KEM -- explicitly because it rests on codes rather than lattices, so that a future lattice break cannot bring down all post-quantum encryption at once. NIST even documented why it chose HQC over BIKE and why it did not select Classic McEliece [@ir-8545].

That selection is the thesis rendered as a signed, dated decision. A monoculture-minded process would have shipped one KEM -- the fastest -- and moved on. NIST shipped a second one on a different hard problem, and said out loud that non-correlation was the reason.

NIST did not choose HQC because it was the fastest or the smallest. It chose HQC because it is not a lattice.

Here is the whole portfolio as an engineering comparison. The last row -- correlation to the lattice core -- is the one this article cares about most.

Dimension	Lattice core (ML-KEM / ML-DSA)	Lattice (Falcon)	Hash (SLH-DSA)	Code (HQC)	Code (McEliece)
Worst-case structural threat	Generic Module-LWE advance	Advance on NTRU lattices	Break of the underlying hash	ISD advance on quasi-cyclic codes	ISD advance on Goppa codes
Best-known attack cost	Sieving $2^{0.292\beta}$ [@core-svp]	Sieving $2^{0.292\beta}$ [@core-svp]	Generic hash bounds	ISD $2^{\Theta(n)}$ [@bjmm-2012]	ISD $2^{\Theta(n)}$ [@bjmm-2012]
Representative size	~1 KB pk, ~3 KB sig	sub-KB signature	KB-scale signature	few-KB public key	0.26-1.36 MB public key [@classic-mceliece-site]
Performance	Fast	Compact, fast verify	Slower, larger signatures	Moderate	Fast operations, very large keys
Attack-cost verifiability	Contested margin [@classic-mceliece-site]	Contested margin	High (hash-based)	Machine-checkable	Machine-checkable, most stable
Correlation to lattice core	It is the core	High (lattice)	None (hash)	Low (code)	Low (code)

A portfolio on paper only becomes a defense when it is fielded, and this one is. On the wire, the dominant deployment is a hybrid: a classical key exchange and a lattice KEM run together, most commonly the X25519MLKEM768 group, which pairs X25519 with ML-KEM-768, the two primitives it shares with the general-purpose X-Wing combiner [@xwing-2024].

Running a classical key exchange (say X25519) and a post-quantum KEM (say ML-KEM) side by side, then combining their two shared secrets through a key-derivation function. The result is secure as long as *either* half is unbroken, so a surprise break of the post-quantum piece does not, on its own, expose the session.

The adoption is real and recent. By early 2024, roughly 2 percent of TLS 1.3 connections to Cloudflare used post-quantum key exchange, with over 99 percent of that traffic driven by Chrome [@cloudflare-pq-2024]. Apple's iMessage PQ3 and Signal's PQXDH shipped post-quantum protection into production messaging [@apple-pq3; @signal-pqxdh]. And the NSA's CNSA 2.0 suite mandates ML-KEM and ML-DSA, plus the stateful hash-based signatures LMS and XMSS for software- and firmware-signing, for national security systems on a timeline running to 2033 [@cnsa-2.0]. The portfolio is not a whiteboard proposal; it is being poured into the foundations of the internet right now.

A portfolio is only a defense, though, if its bets are genuinely uncorrelated. So the honest question -- the one that separates comfort from security -- is whether these bets are independent. They are not all as independent as the map makes them look.

7. Are the Bets Actually Uncorrelated?

This is where the map earns its keep. Press on each band and watch how far the crack spreads. There are three verdicts to reach and one uncomfortable caveat that undercuts all of them.

The lattice cluster is genuinely correlated -- and it is the largest correlated surface on the map. A sufficiently general advance against structured lattices, or a real quantum algorithm for Module-LWE, would not stay contained. It would reach ML-KEM and ML-DSA through their shared Module-LWE assumption and very likely Falcon through its NTRU lattices as well.

The caveats from Section 4 still hold and still matter -- Falcon is NTRU rather than Module-LWE, the parameters differ, and ML-DSA carries an extra Module-SIS route -- so not every lattice result hits all three. But the honest summary is stark: the single most valuable target on the board is "lattices in general," and three standardized schemes sit behind it.

flowchart TD GEN["Generic Module-LWE break"] --> MLKEM["ML-KEM"] GEN --> MLDSA["ML-DSA"] LR["Large lattice-reduction advance"] --> MLKEM LR --> MLDSA LR --> FAL["Falcon"] ISD["Information-set decoding advance"] --> HQC["HQC"] ISD --> MCE["Classic McEliece"] HASH["Hash function break"] --> SLH["SLH-DSA"] NN["Nearest-neighbor search"] -.-> LR NN -.-> ISD

The code pair is partially correlated. HQC and Classic McEliece are both code-based, but they are different structural bets -- quasi-cyclic codes versus binary Goppa codes. They share an attack ruler: improvements to information-set decoding erode both [@bjmm-2012]. But a structure-specific attack, one that exploits the quasi-cyclic shape or the Goppa structure in particular, need not transfer between them. Same family, two different bets inside it.

The best-known family of attacks against code-based cryptography. ISD guesses a subset of coordinates it hopes are error-free, solves the resulting linear system, and checks whether the implied error is small enough, repeating until it succeeds. Fifty years of refinement have chipped at its exponent without changing its exponential character -- which is exactly why the code margin is considered stable.

The hash anchor is the least correlated bet on the map, but not perfectly isolated. SLH-DSA shares no algebraic structure with lattices or codes at all; its only correlation is to the strength of the SHA-2 and SHA-3 families it is built on. And those carry the largest, most-attacked security margins in all of cryptography. If you wanted the closest thing to an assumption that fails for reasons entirely its own, this is it.The lattice margin, by contrast, is not settled. Concrete-security estimates that NIST itself has published for Kyber-512 have spanned roughly $2^{140}$ to $2^{180}$ gates depending on modeling assumptions [@classic-mceliece-site]; the code margin is comparatively stable and can be checked by attack-cost simulators.

Now the caveat that keeps this section honest. Lattice sieving and code-based ISD, at their algorithmic cores, both reduce to the same primitive: finding very close vectors in a huge set, a nearest-neighbor search. The best sieving algorithms and the best decoding algorithms have both been sharpened by advances in nearest-neighbor techniques [@core-svp]. So it is conceivable that one deep breakthrough in nearest-neighbor search could sharpen attacks in both the lattice band and the code band at once -- a meta-correlation the tidy three-color map hides.

I have to mark that claim precisely, because overstating it would betray the whole argument. No published result demonstrates an attack that transfers between the families, and no reduction is known in either direction. This is an inferred caution, not a documented failure.

Note: "No known reduction between two assumptions" is a statement about today's literature, not about mathematics. It means nobody has published a way to turn a break of one into a break of the other. It does not mean no such way exists. Mistaking "we have not found a link" for "there is no link" is exactly the overconfidence that Shor and SIDH punished.

The strongest case for leaning on code-based encryption comes from the anti-monoculture camp around Daniel Bernstein and Tanja Lange [@ntruprime-diversity]. The argument has two parts: lattice concrete-security estimates are contested and have shifted over time, whereas the cost of information-set decoding is stable and can be pinned down by machine-checked attack simulators. The Kyber-512 figures they marshal are NIST's own [@classic-mceliece-site]. Read them as an interested party making a real point -- not as a neutral referee.

So the encryption diversity is real but not proven, and the lattice concentration is real and only partly hedged. Which raises the deepest question in the article, the one no better algorithm can answer: could we ever prove two assumptions uncorrelated, even in principle?

8. Why You Cannot Prove the Portfolio Uncorrelated

Now the bad news that no better algorithm can fix. There are two impossibilities here, and they ascend: the first is well known and merely humbling; the second is specific to this article's thesis and is, in a strict sense, permanent.

The first: nothing in the stack is proven hard. Module-LWE, syndrome decoding, and hash security all rest on the same foundation -- "nobody has broken it yet." The best-known positive result is Regev's: a quantum reduction from worst-case lattice problems to average-case LWE [@regev-lwe-2005]. That is genuine, beautiful evidence: if you could solve random LWE instances efficiently, you could solve the worst case of certain lattice problems too. But it is not a hardness proof, because those worst-case problems are themselves only believed hard.

A problem is worst-case hard if *some* inputs are hard; it is average-case hard if a *randomly chosen* input is hard. Cryptography needs the second, stronger property, because keys are random. General decoding is NP-complete in the worst case, but that says nothing about the average random instance a code-based scheme actually uses -- which is why "NP-complete" is a weaker comfort here than it first sounds.

It goes deeper than "we have not gotten around to it." The lattice problems live in a place that makes a proof structurally unavailable.

The class of problems whose yes-answers and no-answers both have short, checkable certificates. The worst-case lattice problems (approximate GapSVP and GapSIVP) that LWE reduces from sit here [@aharonov-regev-2005]. That location is itself a clue: problems in NP intersect coNP are believed *not* to be NP-complete, so lattice hardness cannot simply be inherited from NP-completeness -- and a real hardness proof would have to settle questions about P, NP, and coNP that have resisted half a century of effort. Suppose you proved that Module-LWE requires exponential time. You would then have exhibited a problem in NP that is not in P -- which proves P is not equal to NP, the most famous open question in computer science, with a million-dollar prize attached. Every cryptographic hardness assumption is, in this exact sense, a bet on how a Millennium Problem resolves. We build the internet on conjectures because proofs are unavailable, not because anyone is being careless.

The second impossibility is the one this whole article has been circling, and it is worse than the first. Even if, by some miracle, we could prove each assumption individually hard, we still could not prove them uncorrelated. Uncorrelatedness is a statement about all possible future mathematics: that no single idea, in any field, ever reaches two of these problems at once. You can accumulate evidence for it -- watch two assumptions resist different tools, wielded by different communities, for different lengths of time. You can never close it.

SIDH is the proof of the danger: the tool that took it was a 1997 theorem nobody had connected to cryptography. There is no theorem that says "and there are no more surprises like that one."

Key idea: You cannot prove the portfolio uncorrelated. You can observe that two assumptions have resisted different tools for different lengths of time, but you can never rule out a single future idea that reaches both -- that is not a gap in today's knowledge, it is unprovable in principle. Diversity is therefore risk management, not proof. The portfolio is not a solution to the hardness problem; it is the best available discipline in the permanent absence of one.

This is the moment the comfortable reading breaks. Diversity felt like a solution -- hold different assumptions and relax. It is not a solution. It is a disciplined bet made under permanent uncertainty, chosen precisely because certainty is not on the menu and never will be.

Diversity is the closest thing to a security proof this science permits -- and it is not a proof at all.

If we can neither prove the bets hard nor prove them independent, the only rational questions left are practical ones: where would a correlated break actually come from, and how much time is on the clock?

9. Where the Correlated Break Would Come From

If you wanted to take down the whole stack, here is where you would aim. Three of these questions are open mathematics; the fourth is a clock.

A "Shor for lattices." An efficient quantum algorithm for Module-LWE would be the nightmare scenario: a single result reaching ML-KEM, ML-DSA, and by extension the lattice core all at once -- the correlated break the map warns about. And this is not a thought experiment. In April 2024, Yilei Chen posted a paper claiming exactly such an algorithm.In little more than a week Chen withdrew the claim: a flaw in Step 9, found independently by Hongxun Wu and Thomas Vidick, could not be repaired [@chen-2024; @green-chen-2024]. It must be cited only as retracted, never as a live break [@quantum-insider-chen].

The algorithm did not survive contact with other experts -- but for a little over a week, serious people believed the lattice core might be gone. That interval is the point. The feared correlated break is unrealized, not impossible, and the field felt exactly how much rides on one assumption.

Shared structure between lattices and codes. As Section 7 noted, lattice sieving and code decoding both lean on nearest-neighbor search. Whether that shared tooling hides a deeper connection -- a single advance that erodes both bands -- is genuinely open. No reduction is known, no transfer has been demonstrated, and "no known reduction" is not "no possible link."

Whether the signature on-ramp adds real diversity. NIST is still recruiting more signature families, and the roster is a live test of the whole thesis.

NIST is hunting for additional, uncorrelated signature families through an "on-ramp" call [@nist-onramp]. The candidates are telling. SQIsign is an isogeny scheme, the family whose SIDH and SIKE members collapsed in 2022. UOV, MAYO, and SNOVA are multivariate, the family whose flagship Rainbow was key-recovered in a weekend on a laptop [@beullens-rainbow-2022]. FAEST and HAWK bring still other assumptions. The open question is whether adding a *young, lightly vetted* family is durable diversity or just new, unmeasured risk -- because SIDH proved that "vetted for a few years" is not the same as "safe."

The clock. Everything above would be an academic seminar if the timeline were comfortable. It is not, because of a single idea.

The attack that makes migration urgent today even though no quantum computer exists yet. An adversary records encrypted traffic now and stores it, waiting for a future quantum computer to decrypt it retroactively. Any secret that must stay confidential for longer than the time-to-quantum is already exposed, no matter how strong today's key exchange looks.

Michele Mosca turned this into a one-line risk test, $X + Y \geq Z$: if the years your data must stay secret ($X$) plus the years you need to migrate ($Y$) meet or exceed the years until a cryptographically relevant quantum computer ($Z$), your data is already at risk today [@mosca-2015].

Mosca's inequality: if secrecy_life + migration_time >= time_to_quantum, your data is already exposed to harvest-now-decrypt-later.

def already_exposed(secrecy_life_years, migration_years, years_to_quantum): exposure = secrecy_life_years + migration_years print("Secrecy lifetime (X): " + str(secrecy_life_years) + " yr") print("Migration time (Y): " + str(migration_years) + " yr") print("Time to quantum (Z): " + str(years_to_quantum) + " yr") if exposure >= years_to_quantum: print("EXPOSED: X + Y exceeds Z by " + str(exposure - years_to_quantum) + " yr. Migrate now.") else: print("Safe for now by " + str(years_to_quantum - exposure) + " yr. Keep watching Z.")

A record that must stay secret 15 years, a 5-year migration, quantum in 12 years:

already_exposed(15, 5, 12) `}

For many long-lived secrets the inequality already bites, which is why the migration is being written into law rather than left to preference. The alarm is not new -- the NSA signaled it as early as 2015, when it announced plans to move away from its existing Suite B algorithms [@nsa-2015]. It has since hardened into deadlines: CNSA 2.0 sets a 2025-to-2033 timeline for national security systems [@cnsa-2.0], and Executive Order 14412 codifies migration requirements and the harvest-now-decrypt-later threat directly into federal policy [@eo-14412].

None of the open questions is settled, and the clock is already running. So the only responsible move is to build a stack today that survives being wrong about any one of them. That turns out to be a concrete engineering task.

10. Building an Uncorrelated Stack on Monday

Strip away the theory. Here is what to deploy, and the single rule that ties it together: watch the assumption, not the algorithm name.

Deploy hybrids. Run a classical key exchange and a post-quantum KEM together and combine their secrets, so that a break of the post-quantum half is not, by itself, a break of the session. The dominant TLS deployment is the hybrid group X25519MLKEM768; the closely related general-purpose combiner X-Wing [@xwing-2024] is built on the same X25519 and ML-KEM-768 primitives.

flowchart LR X["X25519 shared secret"] --> KDF["Combiner / KDF"] K["ML-KEM-768 shared secret"] --> KDF KDF --> S["Session key (secure if either input holds)"]

This is not a hypothetical benefit.The empirical case for hybrids is already written. Cloudflare's earlier CECPQ2b experiment paired X25519 with the isogeny KEM SIKE, and any traffic recorded then stayed safe when SIKE broke -- the classical half still held [@cloudflare-pq-2024]. A hybrid turned a total break into a non-event. A hybrid is the correlation lens applied to a single connection.

{` // A hybrid combines a classical secret and a post-quantum secret. // The session key is safe as long as EITHER half is still unbroken. function hybridSafe(classicalBroken, pqBroken) { return !(classicalBroken && pqBroken); }

for (const classicalBroken of [false, true]) { for (const pqBroken of [false, true]) { const verdict = hybridSafe(classicalBroken, pqBroken) ? 'SAFE' : 'EXPOSED'; console.log('classical broken=' + classicalBroken + ', PQ broken=' + pqBroken + ' -> ' + verdict); } } // Only the final row, where both are broken, prints EXPOSED. `}

Refuse a lattice monoculture. This is the mistake the whole article exists to prevent.

Note: Replacing RSA with ML-KEM, and ECDSA with ML-DSA and Falcon, feels like a thorough migration. In assumption terms it is a lattice monoculture: one good enough advance against structured lattices reaches all of it. "Post-quantum" is not the same thing as "diversified."

Pair the efficient lattice core with a backstop that shares nothing with it: SLH-DSA for signatures you need to trust for decades, and a code-based KEM -- HQC or Classic McEliece -- kept available for encryption. And because the lattice margin is the contested one, prefer the higher-margin parameter sets (ML-KEM-768 or 1024) over the smallest.

Build for replacement. No choice here is permanent, so the system must be able to change its mind.

The engineering property of being able to swap a cryptographic primitive without re-architecting the system around it. If your protocol treats "the KEM" as a replaceable module rather than a hardwired choice, then an assumption that starts to erode can be dropped for another before it fails -- which is the operational form of holding a portfolio.

Put together, the decision guide is short, and every row is chosen by assumption, not by benchmark:

Need	Deploy	Why
General key exchange	ML-KEM-768, hybridized with X25519	Efficient lattice core plus a classical backstop
Maximum-conservatism encryption	Classic McEliece or HQC	Code assumption, uncorrelated with lattices
General signatures	ML-DSA-65, hybridized	Efficient lattice signature with a classical hedge
Firmware and root-of-trust signing	SLH-DSA	Hash-only, shares nothing with the rest, longest-lived trust
Bandwidth-critical signing	Falcon	Smallest signatures, at the cost of a third lattice bet

Note: When you audit a stack for diversity, ignore the product names and list the assumptions. Three lattice schemes with three different names are one bet. A lattice KEM, a hash signature, and a code KEM are three. The name tells you the vendor; the assumption tells you what actually has to break.

One boundary, named once and handed off: the ways these schemes break in practice -- timing leaks in KEM decapsulation, the delicate floating-point sampling inside Falcon's signer, fault and power attacks -- are implementation attacks, a different and equally real surface owned by the sibling track. This section is about the mathematics you choose to deploy, not the code that runs it.

Every one of these moves is a refusal to concentrate -- the same refusal, at the level of a single deployment, that the whole standardization effort was reaching for. Which brings us back to the thesis, now with all the evidence in.

11. Common Misconceptions, Corrected

The fastest way to misread everything above is to reach for one of these seven conclusions. Each is a precise trap, and each answer defends the portfolio rather than any single scheme.

No. Every standardized scheme -- ML-KEM, ML-DSA, SLH-DSA -- currently stands, and HQC has been selected on top of them [@ir-8545]. The argument of this article is not that the stack is weak. It is that the stack's safety is a *diversified portfolio*, not the proven hardness of any one algorithm, because none of them is proven hard. No. The 2022 break was entirely *classical*: it applied Kani's 1997 reducibility criterion to the torsion-point data that SIDH publishes by design, and recovered the key in about ten minutes on a single ordinary core [@castryck-decru-2022; @kani-1997]. No quantum computer was involved. It was not Shor and it was not quantum. No. SIKE was a Round-4 *alternate candidate* still under evaluation, and it was broken before any selection was made [@ir-8413; @nist-2022-selection]. It was never standardized. The correct lesson is that a late-stage, heavily vetted candidate can fall without warning -- which is worse, not better, than a fringe scheme failing. A *generic, structural* break of Module-LWE would indeed threaten both -- that is the correlated-pair risk at the center of the map. But they use different parameters (moduli 3329 versus 8380417, different ranks and noise), and ML-DSA additionally rests on Module-SIS, so a *parameter-specific* attack on one need not transfer to the other [@fips-203; @fips-204]. The correlation is at the level of the shared assumption family, not identical instances. Its security *is* hash security -- that is the design, not a weakness [@fips-205]. And SHA-2 and SHA-3 carry the largest, most-scrutinized security margins in all of cryptography. Reducing entirely to that well-studied foundation, while sharing no algebraic structure with lattices or codes, is exactly why SLH-DSA is the conservative anchor of the portfolio. Because the trust is not placed in one assumption; it is placed in diversity. Lattice, code, and hash rest on unrelated mathematics developed by different communities, and are unlikely to all fall for the same reason at the same time. A break of one leaves the others standing. That is risk management under permanent uncertainty, which is the most any cryptographic science can offer. No -- it is HQC. Classic McEliece is standardized on the ISO track [@classic-mceliece-iso] and was not selected in this round; NIST's IR 8545 explains why it chose HQC over BIKE and why it did not select McEliece [@ir-8545]. Both are code-based, but the newly selected NIST KEM is HQC.

Notice what every answer has in common: not one of them defends a single algorithm. They defend the portfolio.

12. The Portfolio Is the Product

Put the evidence back together. Shor proved that two bets which looked independent -- factoring and discrete log -- were one bet on the abelian hidden-subgroup problem, and fell together the moment the right machine existed [@shor-1994]. SIDH proved that a family can vanish in an afternoon, classically, with no warning, when a 1997 theorem finally met the auxiliary data the protocol had been publishing all along [@castryck-decru-2022]. And the standardized stack, colored by assumption, clusters onto three families -- lattice, hash, and code -- with a genuinely correlated Module-LWE pair, ML-KEM and ML-DSA, sitting at its efficient center [@fips-203; @fips-204].

None of those assumptions is proven hard. None ever will be, short of settling questions about P, NP, and coNPP is the class of problems solvable quickly; NP the class whose solutions can be verified quickly. Whether the two are equal is the central unsolved question of computer science. that have resisted fifty years of effort. And even if they were proven hard one at a time, no theorem could certify them uncorrelated, because uncorrelatedness is a promise about mathematics not yet invented. That is the humbling floor under the entire post-quantum project.

So the security of the stack was never going to be the strength of its strongest algorithm. It is the deliberate, dated refusal to let its bets be correlated: hash-only SLH-DSA standing apart from everything, the March 2025 selection of code-based HQC precisely because it is not a lattice, and an on-ramp still searching for more uncorrelated bets [@fips-205; @ir-8545]. Diversity here is not a hedge bolted onto the design. It is the design.

That reframes what we have actually been buying all along. Not a proof. A portfolio.

We cannot prove the stack secure. But we can, and did, refuse to bet it all on one piece of mathematics.

This is the sentence you were handed in the first section, now earned. We are not betting on a proof. We are betting that lattice, code, and hash will not all fail for the same reason on the same day -- and we have arranged things so that if we are wrong about one, we are not wrong about all three. For a science that can prove nothing hard, that disciplined refusal to concentrate is not a consolation prize. It is the whole defense, and it is the best one available for the thirty years we are wagering on it.

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

noreply@paragmali.com (Parag Mali) — Tue, 14 Jul 2026 03:13:06 GMT

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

The deadlines in this article are precise about scope, and it matters. Executive Order 14412 requires *federal agencies* to transition their high-value assets and high-impact systems -- explicitly excluding National Security Systems -- to post-quantum key establishment by December 31, 2030 and to post-quantum digital signatures by December 31, 2031 [@eo14412]. A companion Federal Acquisition Regulation rule pushes covered federal contractors toward compliance by December 31, 2030 [@eo14412]. Critical infrastructure operators are *encouraged*, not mandated. That National Security Systems exclusion is a hand-off, not a gap: NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0, September 2022) already owns that estate, mandating the same NIST winners -- ML-KEM and ML-DSA -- on its own use-case-staggered schedule, to be complete by 2035 in line with NSM-10, the memorandum that set the whole government-wide posture [@cnsa2] [@nsm10]. The civilian and national-security tracks are two branches of one 2022 origin. And one more distinction worth burning in: EO 14412 ("Securing the Nation Against Advanced Cryptographic Attacks") is not EO 14413, a separate order about quantum innovation published in the same Federal Register issue [@eo14412]. Do not cite one for the other.

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.

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.

NIST NCCoE's "Migration to Post-Quantum Cryptography" practice guide -- whose Volume B is the cryptographic-discovery volume -- is an initial public *preliminary draft*, and its own title page says so [@sp1800-38-guide] [@sp1800-38b-pdf]. Cite it for its discovery reference architecture, which is genuinely useful, but never as a finalized, normative NIST standard. Treating a draft as a final spec is one of the recurring errors in this space.

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 regulator agrees, in writing. As reported by Nextgov, CISA's guidance states that the agency "has not been able to confirm the full scope of cryptographic algorithm detection capabilities that will be available via automated cryptographic discovery tools," and that "the inventory process requires both manual data collection and the use of automated support" [@nextgov-cisa]. The body pushing hardest for automated discovery is explicit that automation alone will not get you to a complete inventory. Bounded coverage is not a vendor's excuse; it is the official operating assumption.

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, 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 [@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.