up:: Migration Architecture MOC
Can AI Build Your Cryptographic Inventory?
A wave of tools now promise to point an AI at your environment and hand you a finished cryptographic inventory. The demo is genuinely impressive. The output is unsafe to build a migration on, and the reason for that sits in the research rather than in any vendor’s marketing.
The inventory is the foundation of the entire quantum transition. Every decision downstream, what’s exposed, what to fix first, what a vendor controls, traces back to a cryptographic bill of materials. So the question of whether a machine can produce that inventory on its own is worth taking seriously, and the answer is that it can do one half of the job brilliantly and the other half not at all.
What an AI is actually good at here
Reading a description and judging “this looks cryptographic” is exactly the kind of task a language model does well. A 2026 study had an ensemble of local models classify roughly 63,000 Linux packages as cryptographically relevant or not, taking a majority vote over each package’s name, description, and dependencies. The best configuration reached an F1 score around 0.86.1
That is a useful result, and it earns the AI a real place in the workflow. It means you can take a haystack of tens of thousands of components and narrow it to the few hundred worth a closer look, in an afternoon, on hardware you already own. Finding cryptography you didn’t know you had is the expensive part of a migration, and a model that shrinks the search space is doing something valuable. Triage is worth a lot.
Where the impressive demo quietly breaks
The trouble starts when that first pass gets sold as the finished inventory, because three properties of the technique each disqualify it as a system of record.
It reads the label rather than the code. The classifier works from a package’s description and dependency names, so a component with a thin or misleading description gets miscounted in either direction.1 Even in that study’s best run, on a clean single-distribution dataset, roughly 1 in 7 calls was wrong. A real enterprise estate is far messier than one Linux distribution.
The same input gives a different answer on a different day. Run the pipeline against next month’s model version and the classifications drift, even with the randomness turned down as far as it will go.1 An inventory that changes when a vendor updates a model can’t be reconciled against last quarter’s.
The output shows its work as a sentence rather than a source. It gives a verdict plus a justification string, and a justification is a rationale. An auditor needs the configuration line or the binary offset a finding came from, and a classifier working off descriptions has none to hand over.
Even the more sophisticated research goes out of its way to compensate for this. A 2026 knowledge-graph approach that scores post-quantum readiness uses a language model to estimate each asset’s risk values, then routes every one of those estimates through a human reviewer before trusting it.2 The researchers built the human-in-the-loop in precisely because they knew the machine’s numbers needed a witness.
Why a CBOM is the wrong place to cut this corner
Most work tolerates a good-enough first draft. A cryptographic inventory does not, because everything stands on it. Foundation-grade work has to be reproducible and traceable, so that a regulator, an auditor, or your own team 6 months from now can follow any single entry back to the exact place it came from. A number that shifts when the model updates, produced by a tool that read a description instead of the cryptography itself, is guesswork with a confident interface. Build a migration plan on it and you inherit every one of its errors, silently, at the layer where they are most expensive to find.
This is the same reason the discipline treats discovery as the hard 80% of a migration and the algorithm swap as the easy 20%. The value was never in producing a list quickly. It’s in producing a list you can defend.
The way to use it
Use the AI for the search and a deterministic tool for the evidence. Let the model make the first pass and narrow the estate to its crypto-relevant candidates, then point a deterministic extractor at that shortlist, one that reads the actual configuration and emits a traceable record for every finding. The model saves you weeks of looking in the wrong places. The deterministic pass produces the thing you sign your name to.
Handing the whole inventory to the model skips the only part that makes an inventory worth having. Treat it as the scout that tells you where to look, and keep the surveyor’s work for the tool that can prove what it found.
The one-click AI CBOM is seductive because the real work is slow and unglamorous, and a clean dashboard feels like progress. The model genuinely shrinks the finding. It leaves the proving exactly where it was, and the proving is the whole point.
If your team is weighing an AI-driven inventory against an audit-grade one, that tradeoff is worth a conversation before you commit to it.
Last verified 2026-07-27 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.
Footnotes
-
Eduard Hirsch, Kristina Raab, Tobias J. Bauer, and Daniel Loebenberger, “Detecting Cryptographically Relevant Software Packages with Collaborative LLMs,” arXiv:2603.07204 (2026). Reports an F1 of approximately 0.86 for a majority-vote ensemble of local models over Fedora package metadata, notes classification from descriptions and dependencies, and documents parse-failure and reproducibility limits. ↩ ↩2 ↩3
-
Rasmus Erlemann, Charles Colyer Morris, and Sanjyot Sathe, “Full-Stack Knowledge Graph and LLM Framework for Post-Quantum Cyber Readiness,” arXiv:2601.03504 (2026). Uses a language model to estimate asset resistance and business-weight attributes, validated through a human-in-the-loop review workflow. ↩