The U.S. Office of the National Cyber Director has projected that migrating prioritized federal information systems to post-quantum cryptography between 2025 and 2035 will cost roughly $7.1 billion. None of that money gets spent intelligently without a cryptographic inventory first. You cannot replace what you cannot find, and as NIST SP 1800-38B puts it bluntly, most enterprises do not actually know where their public-key cryptography lives — it is buried in TLS terminators, HSM-protected signing keys, embedded device firmware, container base images, vendor SDKs, and code paths last touched a decade ago.
This is the unglamorous foundation of the entire PQC transition. Before any organization argues about ML-KEM versus hybrid key exchange, before any CISO commits to a migration date, somebody has to answer a deceptively simple question: where is RSA, ECDH, and DSA running in our environment, and what is it protecting? This guide walks through the tools and methodology that produce a defensible answer.
Why an Inventory Is the Gate, Not the Warm-Up
NIST finalized three PQC standards in August 2024 — FIPS 203 (ML-KEM for key encapsulation), FIPS 204 (ML-DSA for digital signatures), and FIPS 205 (SLH-DSA, the hash-based signature backup). In March 2025, NIST selected HQC as a fifth algorithm to serve as a code-based KEM backup to ML-KEM, with a draft standard expected around 2026 and final standardization in 2027. Federal agencies operating under National Security Memorandum 10 (NSM-10) and the Quantum Computing Cybersecurity Preparedness Act are already obligated to maintain rolling cryptographic inventories. The Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) sets a deprecation horizon of 2030 for non-quantum-resistant cryptography in National Security Systems.
The practical driver is harvest now, decrypt later. An adversary capturing encrypted traffic today — VPN tunnels, TLS sessions, signed firmware updates — can store it indefinitely against the eventual arrival of a cryptographically relevant quantum computer (CRQC). NIST and several national authorities now treat 2030 as a plausible near-term CRQC milestone, with broader expert consensus pointing to a 10-to-20-year window. Data with a secrecy lifetime longer than that window is already at risk.
The inventory itself is the deliverable that turns this abstract threat into an engineering project. Without it, “migrate to PQC” is a slogan. With it, you have a prioritized list of systems, owners, and dependencies that maps directly to remediation tickets.
What a Cryptographic Inventory Actually Contains
A working inventory is not a spreadsheet of “we use TLS.” It is a structured catalog of cryptographic assets and the dependencies between them — what the IBM-led CycloneDX 1.6 extension calls a Cryptography Bill of Materials (CBOM).
The asset categories worth tracking are narrower than you might expect but go deeper than a typical asset register. Algorithms must be captured at the variant level, not the family level — AES-128-GCM and AES-256-CBC are different security postures, and SHA1 versus HMAC-SHA1 is the difference between a broken primitive and an acceptable MAC construction. Keys need provenance: where generated, where stored, what HSM, what rotation policy, what they sign or encrypt. Certificates need their full chain, key algorithm and length, validity window, and the systems that present them. Protocols need their negotiated parameters: TLS version, cipher suites in the offer list, IKEv2 transforms, SSH key exchange algorithms.
Crucially, the inventory must distinguish between implements and uses relationships. A library implements an algorithm; an application uses it. OpenSSL implementing ML-KEM is meaningless if your application is still calling RSA-2048 for key exchange. The CBOM model formalizes this distinction, which matters because remediation almost always happens at the application or configuration layer, not the library layer.
The Discovery Methodology: Why One Tool Will Not Do It
NIST SP 1800-38B is explicit on this point: there is no single product that finds all instances of vulnerable cryptography in a real enterprise. The NCCoE lab demonstration deliberately combined contributions from AWS, IBM, Samsung SDS, InfoSec Global, SandboxAQ, Thales, and others to cover gaps that any individual tool leaves. The methodology that produces a defensible inventory rests on layering four discovery techniques, each with known blind spots.
Source code analysis finds cryptographic intent at the moment it was written. Tools like GitHub CodeQL, IBM’s Sonar Cryptography plugin (CBOMkit-hyperion), and the Wind River crypto-detector pattern-match against API calls, type declarations, and import statements. Strengths: catches algorithms before they ship, integrates into CI/CD, attributes findings to specific files and line numbers. Limitations: misses cryptography in compiled third-party dependencies, dynamic configuration, and infrastructure as deployed.
Binary and container analysis picks up where source analysis stops. IBM’s CBOMkit-theia scans container images and directories for cryptographic library signatures. This catches what comes in via base images, vendor binaries, and supply-chain components — the bulk of cryptography in most environments is not code anyone in the organization wrote.
Network traffic analysis identifies what actually negotiates on the wire. Passive sensors classify TLS, SSH, IKE, and other protocol exchanges, recording cipher suites, certificate chains, and protocol versions in production. SandboxAQ’s AQtive Guard Network Analyzer and Keyfactor’s AgileSec (via the InfoSec Global acquisition completed in 2025) operate in this layer. Strengths: ground truth for what is running, agentless. Limitations: only sees what crosses observable network points, blind to data-at-rest cryptography and offline signing.
Host and filesystem inspection covers data at rest and runtime behavior. Agent-based tools enumerate keystores, certificate files, configuration directives, and live cryptographic API calls. SandboxAQ’s Application Analyzer hooks running processes; AQtive Guard’s Filesystem Analyzer parses crypto objects from disk. Limitations: agent deployment friction, OT and embedded systems often cannot host agents.
The NIST conceptual architecture treats these four streams as inputs to a normalization and correlation engine that emits a consolidated CBOM. The point of the architecture is overlap by design — when static analysis finds RSA-2048 in code, the network scan should confirm an RSA certificate on the wire, and the filesystem scan should locate the corresponding private key file. Three independent confirmations of the same asset is high-confidence; one detection in one tool is a starting hypothesis.
The Tooling Landscape
A few characteristics distinguish the leading commercial platforms. SandboxAQ’s AQtive Guard combines all three modalities (network, application, filesystem) under one control center and counts the U.S. Air Force, DISA, and the Department of Health and Human Services among disclosed customers. In October 2025, the company also released OpenCryptography.com, a free public database of cryptographic findings extracted from popular Docker Hub images — useful as both a reference and a way to triage your own container base images.
The IBM and Keyfactor axis consolidated significantly in 2025. Keyfactor acquired InfoSec Global, bringing AgileSec Analytics into a broader certificate and key lifecycle platform; IBM Consulting then announced a partnership in November 2025 making AgileSec part of IBM’s Quantum Safe Transformation Services. IBM’s own stack — Quantum Safe Explorer for source scanning, Quantum Safe Advisor for runtime, and Quantum Safe Remediator for hybrid deployment — wraps around the CBOM specification IBM contributed to CycloneDX.
On the open-source side, IBM’s CBOMkit suite and CycloneDX’s reference tooling provide enough machinery to bootstrap an inventory without a procurement cycle. CodeQL queries for cryptographic patterns are publicly documented. For organizations that need a starting point before committing budget, the open path is viable for code-level discovery, weaker for network and host coverage.
A Phased Methodology That Survives Contact With an Enterprise
Vendor pitches make this look linear. It is not. A cryptographic inventory is built in overlapping phases that loop back on each other as discovery surfaces new systems.
Phase one: scope and governance. Decide what is in your direct control versus what is vendor-managed. For SaaS and third-party services, the deliverable is not a scan output but a vendor risk statement and PQC roadmap commitment. Define what counts as a cryptographic asset for your purposes — the temptation to include every symmetric cipher in every library leads to noise that buries the actual quantum-vulnerable findings (RSA, ECDH, ECDSA, DSA, DH).
Phase two: pilot discovery. Pick one business-critical system or application boundary. Run at least two complementary tools — typically one source/binary scanner and one network or host scanner. Compare their outputs. The pilot’s real purpose is calibrating tools to your environment and seeing how false-positive rates behave on your stack, not producing a complete inventory.
Phase three: scaled discovery. Extend coverage across the four discovery layers. Integrate scanning into CI/CD pipelines so new code is inventoried at commit time. Place network sensors at egress points, between segmented zones, and in front of critical applications. Deploy host agents where supported, document agentless gaps.
Phase four: correlation and CBOM construction. Normalize outputs into the CycloneDX 1.6 schema or an equivalent internal model. Resolve overlaps between tools — the same TLS certificate found by network analysis and filesystem inspection should collapse to one asset, not two. Cross-reference findings against your existing asset inventory (CMDB, IAM, EDR) so each cryptographic asset has an owner and a business context.
Phase five: risk prioritization. Score assets by data sensitivity, secrecy lifetime, system criticality, and exposure. A public-facing TLS endpoint protecting decade-relevant data ranks above an internal service handling ephemeral session tokens. The output is a ranked migration backlog, not a finding list.
Phase six: continuous operation. A point-in-time inventory rots fast. New code ships, certificates rotate, vendors push updates. The mature state is continuous discovery feeding a living CBOM that participates in change management and procurement gates.
Pitfalls That Sink Inventory Programs
The recurring failure mode is treating discovery as a one-shot exercise rather than a capability. Organizations stand up a tool, generate a report, declare victory, and watch the inventory drift into uselessness within a quarter. Continuous integration into CI/CD and standing network sensors are the only durable answer.
A second failure is over-trusting any single tool. SandboxAQ marketing and IBM marketing both promise comprehensive coverage. Neither is wrong about their own scope; both are misleading if read as “you only need us.” The NIST architecture exists precisely because the layers do not substitute for each other.
A third is skipping context enrichment. A list of 40,000 RSA-2048 instances with no owner, business unit, or criticality field is unactionable. Most of the inventory’s value comes from the join with existing asset and identity systems, which is unglamorous integration work that does not show up in any tool demo.
A fourth is forgetting embedded and OT environments. ICS controllers, medical devices, vehicle ECUs, and field equipment frequently cannot host agents and may not present discoverable network traffic to general-purpose sensors. These often have the longest secrecy lifetimes and the slowest patch cycles — exactly the systems where harvest-now-decrypt-later risk is most acute. Plan for vendor-supplied attestations and selective lab teardowns rather than expecting automated discovery to handle them.
Frequently Asked Questions
Do we need a CBOM if we already produce SBOMs? The SBOM tells you a component is present. The CBOM tells you whether the component’s cryptographic functionality is actually used and how. They compose: a CBOM typically references SBOM components and adds the cryptographic semantics on top. Per the CycloneDX 1.6 specification, both can live in the same document.
How long does a real inventory take? For a mid-sized enterprise, expect 6 to 18 months to reach a defensible baseline, with continuous operation thereafter. The pilot phase alone usually runs 2 to 3 months once tooling is selected.
Can we wait for vendors to handle this? Partially. Hyperscalers and major vendors are publishing their own PQC roadmaps, and some cryptography (managed TLS, managed KMS) will migrate transparently. Anything you operate yourself, anything custom, and anything regulated requires your own inventory and your own remediation plan.
Is open-source tooling sufficient? For source-code discovery, often yes — CodeQL and IBM’s open CBOMkit components are credible. For network and host coverage at enterprise scale, commercial platforms still offer materially better correlation, dashboarding, and integration. A hybrid approach is common.
Where This Goes Next
The maturity curve here will look like vulnerability management did fifteen years ago: niche capability, then standard practice, then a procurement and audit requirement. Expect cryptographic inventory to become an explicit control in the next NIST Cybersecurity Framework revision and a default expectation in financial-sector and healthcare audits well before the CRQC threat materializes. The organizations that will fare best in the PQC transition are not the ones with the fastest migration plans — they are the ones who already know what they are migrating from.
If you have not started, the first defensible action is small and concrete: run one open-source crypto scanner against one critical repository this quarter, and capture the output as a CBOM. Everything else builds from that.
