Automated Discovery Tools for Cryptographic Inventory Management

Before an organisation can migrate its cryptography to post-quantum standards, it must know what cryptography it has and where it lives. This sounds straightforward. It is not. Cryptography is embedded across application source code, compiled binaries, TLS stacks, certificate stores, hardware security modules, container images, and infrastructure-as-code repositories. No single scanning tool covers all of these surfaces. The organisations that discover this late lose weeks.

The NIST NCCoE Migration to Post-Quantum Cryptography project (SP 1800-38) identifies cryptographic inventory as the mandatory first step on the PQC migration path. A typical enterprise with 500 internal applications, 50 cloud services, and several hundred microservices running in containers has cryptographic surface area that manual inventory cannot cover within any reasonable project timeline. Automated scanning across multiple layers is the only practical approach.

This article maps the discovery landscape for security architects, DevSecOps leads, and CISOs managing a PQC migration programme. It names the specific tools available for each scanning layer, identifies what each tool covers and what it misses, and explains how the Cryptography Bill of Materials (CBOM), standardised under CycloneDX 1.6, provides a common output format that connects discovery to migration planning. The goal is to help practitioners assemble a multi-tool discovery stack that produces a defensible inventory, not to recommend a single vendor solution that leaves surfaces unscanned.

Why Cryptographic Inventory Is the Hardest First Step

The scope problem in cryptographic discovery is larger than most practitioners expect at the start of a migration programme. Cryptography in enterprise systems is distributed across six distinct surfaces: application source code, including hardcoded algorithm choices, library imports, and cipher suite configuration; compiled binaries, where statically linked crypto libraries may be present without source code access; TLS and DTLS network traffic, covering negotiated cipher suites, certificate algorithms, and key exchange mechanisms; certificate and key stores, including HSMs, PKI directories, and cloud key management service instances; container images and infrastructure-as-code repositories; and hardware firmware.

The migration scope is defined by the algorithms that are vulnerable to quantum attack. Asymmetric cryptography using RSA, ECC, and Diffie-Hellman is the primary target. For symmetric cryptography, AES-256-GCM is the recommended floor: AES-128-GCM carries greater exposure to Grover's algorithm than AES-256-GCM, making algorithm selection matter even within the symmetric layer. NIST NCCoE SP 1800-38 defines the discovery methodology across these surfaces, and the guidance is explicit that Phase 1 inventory must cover all six before migration prioritisation can begin with confidence.

The practical consequence of incomplete inventory is discovered mid-programme: a migration that was thought to cover all external-facing TLS systems turns out to have missed a set of internally developed microservices using a legacy crypto library. Starting discovery with a clear multi-layer model prevents that surprise. For the broader migration programme that discovery feeds into, see How to Start a PQC Migration Programme.

Source Code Scanning

Commercial Tools for Source Code Discovery

IBM Quantum Safe technology, previously positioned within the IBM Guardium Cryptography Discovery product line, scans application source code and binary artefacts for cryptographic usage and outputs an inventory of algorithm types, key sizes, and usage contexts. IBM has built its cryptographic discovery capability as part of the broader IBM Quantum Safe programme, and the tooling integrates with IBM's migration advisory services.

PQShield's UltraPQ Suite includes source code scanning for cryptographic algorithm detection across Java, C/C++, Python, and Go. PQShield is a UK-based PQC vendor whose commercial tooling suite incorporates a cryptographic discovery component as part of its migration advisory offering. This makes it one of the few commercial tools with direct PQC expertise built into the scanning rule set rather than applied as a post-processing layer.

Sandbox AQ acquired Cryptosense, a French cryptographic analysis firm, in 2022, and developed the combined product into an enterprise cryptographic discovery platform. The Sandbox AQ platform provides static code analysis and runtime analysis of Java applications for cryptographic algorithm usage. One attribution note: some early documentation and secondary references incorrectly attribute Cryptosense to Microsoft. Cryptosense was acquired by Sandbox AQ, not Microsoft. Microsoft has its own cryptographic discovery capabilities within the Defender and Purview product lines, but these are a separate product lineage from the Cryptosense tooling.

A further tool worth noting for readers who have encountered it in procurement: the ISARA Catalyst cryptographic agility toolkit, produced by ISARA Corporation, included CBOM generation output as part of its discovery capabilities. Current product availability and branding should be verified directly with ISARA Corporation before specifying the ISARA Catalyst toolkit in a procurement.

Open Source Options

Semgrep, an open source static analysis tool, supports custom rule authoring that can be applied to cryptographic pattern detection. Security teams can write Semgrep rules to flag known-vulnerable cryptographic patterns: RSA key sizes below 2048, DES or 3DES usage, MD5 or SHA-1 in integrity-critical contexts, and ECC parameters using vulnerable curves. Semgrep rules must be written per language and maintained as libraries evolve. No comprehensive, maintained public rule set for PQC-focused source code scanning exists as of May 2026, so this approach requires investment in rule development.

OWASP Dependency-Check provides a complementary capability: it flags known-vulnerable library versions linked to CVE entries, including cryptographic libraries with published vulnerabilities. Combined with the OWASP Cryptographic Storage Cheat Sheet, which catalogues correct and incorrect cryptographic implementation patterns, Dependency-Check gives development teams a starting point for identifying vulnerable cryptographic dependencies within their build pipelines.

One tool that does not belong in this category but is sometimes included by confusion: PQClean is a project producing clean, portable C reference implementations of NIST PQC candidates for benchmarking and evaluation. It is relevant to development teams assessing algorithm performance. It is not a scanning tool and does not perform cryptographic inventory discovery.

Binary Scanning

Where source code is unavailable, because the software is a commercial product, a vendor appliance, or a legacy application whose source has been lost, binary scanning can identify cryptographic library signatures. The approach involves pattern matching against known cryptographic library strings using tools such as the Unix strings command, signature matching against compiled function patterns from known versions of libcrypto or BoringSSL, and entropy analysis to detect key material embedded in binaries.

Binwalk and radare2 are open source binary analysis tools used in embedded security research and firmware analysis. Neither is purpose-built for cryptographic inventory in the PQC migration context, and applying them requires customisation and security research expertise. They are not plug-and-play scanning tools. Their use is documented in practitioner writeups rather than formal NIST or ETSI guidance, and teams using them for PQC discovery should treat them as a specialist investigation tool rather than a production scanner.

Commercial software composition analysis (SCA) tools, including Synopsys Black Duck, Checkmarx SCA, Sonatype Nexus IQ, and Veracode, identify cryptographic library components in compiled software through software composition analysis. These tools are primarily oriented towards licence compliance and CVE detection, not PQC-specific algorithm enumeration. However, they do surface the cryptographic library inventory that feeds into CBOM generation. Combined with NTIA SBOM Minimum Elements guidance (published by NTIA in July 2021, not CISA), they provide a structured basis for identifying which cryptographic libraries are present and in which versions, which is the first step towards algorithm-level enumeration.

Network and TLS Scanning

TLS handshake fingerprinting identifies the cipher suites and key exchange mechanisms negotiated between endpoints. Three tools cover this surface at different scales. Testssl.sh, an open source command-line tool, enumerates TLS configurations across accessible endpoints and reports cipher suites, key exchange algorithms, certificate details, and known vulnerabilities. Qualys SSL Labs provides a hosted scanning service that produces detailed TLS configuration reports for publicly accessible HTTPS endpoints. Both tools report algorithm and key size information at the level needed for migration prioritisation.

At enterprise scale, Zeek (formerly Bro) and Suricata can be configured to extract TLS metadata from network traffic passively, without decrypting it. This approach identifies all TLS endpoints and their cryptographic configuration by observing negotiated cipher suites, certificate subjects, and signature algorithms as they appear in live traffic. Passive scanning catches endpoints that active scanning misses because they are not reachable from the scanner's network position.

Certificate inventory adds a third scanning layer for the PKI surface. All X.509 certificates deployed across an organisation can be identified through certificate transparency log monitoring, using crt.sh, combined with direct queries to internal certificate authorities. Migration priority for certificates follows from three factors: RSA key size (RSA-1024 and RSA-2048 are both vulnerable to Shor's algorithm, as is RSA-4096 regardless of key length, since Shor's attack scales with key size rather than being stopped by it); ECC curve (all standard curves including P-256 and P-384 are vulnerable); and certificate lifetime relative to the Q-Day window. A certificate expiring in 2026 is lower priority than one with a ten-year validity extending to 2034.

CBOM Emission and CycloneDX 1.6

The Cryptography Bill of Materials is the standardised output format that turns scan results into actionable migration planning data. CycloneDX 1.6, released in April 2024, introduced a formal CBOM extension to the existing software and hardware bill of materials schema. A CBOM records cryptographic assets including algorithms, certificates, and keys; their usage contexts covering the protocol, component, and application where each asset is used; their properties including algorithm type, key length, curve, and mode; and their dependencies on other components.

The CBOM format provides a machine-readable output that can be ingested by migration planning tools, risk scoring systems, and compliance reporting pipelines. It is the interface between cryptographic discovery and migration prioritisation. NIST NCCoE SP 1800-38 identifies CBOM as the target inventory artefact from Phase 1 discovery. For the architecture that consumes this inventory for ongoing migration management, see our article on Crypto Agility: The Architecture Principle.

The relationship between CBOM and SBOM is worth clarifying for teams already running SBOM programmes. An SBOM, as defined by the NTIA Minimum Elements published in July 2021, records all software components in a build including open source libraries and third-party dependencies. A CBOM extends that record with cryptographic specifics: it does not replace the SBOM but adds a cryptographic layer to it. Teams with mature SBOM pipelines can extend their existing tooling to emit CBOM output using the CycloneDX 1.6 schema, rather than building a separate pipeline. For the relationship between SBOM and post-quantum readiness in more detail, see SBOM and Post-Quantum Readiness. For guidance on building the register that houses discovery outputs, see the cryptographic asset register build guide.

Tool support for CycloneDX 1.6 CBOM output as of May 2026 is uneven across the market. IBM Quantum Safe and Sandbox AQ have announced CBOM output capabilities. Open source tooling for automated CBOM generation from aggregated scan output requires assembly using helper libraries including cyclonedx-python-lib and the cyclonedx-bom plugins for Gradle and Maven build systems. The current state of CBOM tooling support should be verified against current product documentation before specifying it in procurement requirements.

Building a Multi-Layer Discovery Stack

No single tool covers all six surfaces. The practical architecture recommendation is to assemble a stack mapped to surface area and to start with the highest-risk surfaces rather than attempting full coverage simultaneously in Phase 1.

For external-facing systems, the highest-priority starting point is TLS and certificate scanning. Testssl.sh or Qualys SSL Labs for active endpoint scanning, combined with Zeek passive traffic analysis for internal TLS, covers the network surface quickly and surfaces the certificate inventory and cipher suite configuration that matter most for external HNDL exposure. For internally developed applications, source code scanning with IBM Quantum Safe or PQShield, or Semgrep with custom rules for development teams with the capacity to build them, covers the application surface. For systems where source is unavailable, commercial SCA tools provide the binary and library surface.

The mapping by surface is as follows. Application source code is covered by SAST tools with crypto rules: IBM Quantum Safe, PQShield UltraPQ Suite, or Semgrep with custom rules. Compiled binaries and firmware are covered by SCA tools: Synopsys Black Duck or Sonatype Nexus IQ. Network and TLS traffic is covered by passive analysis and active scanning: Zeek, testssl.sh, and Qualys SSL Labs. Certificate inventory is covered by PKI queries combined with CT log monitoring using crt.sh. Cloud KMS and HSM inventories are covered by provider-native APIs: AWS KMS key metadata API, Azure Key Vault, and GCP Cloud KMS each provide programmatic access to key inventory and algorithm metadata. Container images are covered by container SCA tools including Grype, Syft from Anchore, and Trivy. All outputs converge into CBOM emission via CycloneDX 1.6 tooling.

The output of the discovery layer feeds directly into the NIST IR 8547 IPD migration prioritisation framework published in November 2024. Assets classified as Category 1, meaning those using algorithms that should be discontinued as soon as practicable, take priority over Category 2 assets where migration should be planned, which in turn take priority over Category 3 assets where continued monitoring is sufficient. A CBOM provides the machine-readable asset list that makes this prioritisation systematic rather than manual.

About the Author

Steven Vaile is a quantum security and post-quantum cryptography consultant and the founder of Quantum Security Defence. He advises enterprises and government bodies on PQC migration strategy, cryptographic governance, and quantum risk assessment. He has spoken at international security conferences on the intersection of quantum computing and critical infrastructure protection.