# Cryptographic Inventory Tools 2026 Survey **Source**: https://quantumsequrity.com/blog/crypto-inventory-tools **Category**: Operations --- [← Back to Blog](../../blog.html) Operations # Cryptographic Inventory Tools 2026 Survey 13 min read You cannot migrate what you cannot find. This is the unglamorous truth of post-quantum cryptography migration. Before any organization can move to ML-KEM or ML-DSA, it has to know where its current cryptography lives. That means scanning source code, binaries, network traffic, configurations, certificates, and runtime behavior to build an inventory of every cryptographic primitive in use. NIST and CISA have made this clear in their PQC migration guidance. NIST SP 1800-38 dedicates substantial space to "discovery and inventory." CISA's Post-Quantum Cryptography Initiative materials list cryptographic discovery as one of the first activities for any organization. The good news is the tooling for cryptographic inventory has matured significantly. The not-so-good news is that no single tool covers everything. This article surveys the cryptographic inventory tooling landscape as it stands in 2026. We will look at what the tools do well, what they miss, and how to combine them into a useful inventory pipeline. ## What a Cryptographic Inventory Should Capture Before discussing tools, it is worth defining the artifact. A useful cryptographic inventory captures: 1. **Cryptographic primitives in use**: AES, RSA, SHA-256, ML-KEM-768, etc. 2. **Algorithm parameters**: key sizes, modes (CBC, GCM, CTR), curves (P-256, X25519, etc.), iteration counts 3. **Where each primitive is used**: source path, line number for source code, library import for binaries, certificate fingerprint for X.509 4. **Configuration**: where the algorithm is selected (hardcoded, runtime config, negotiated) 5. **Lifecycle data**: cryptoperiod, rotation date, owner 6. **Compliance mapping**: which controls (FIPS 140-3, CNSA 2.0, NIST SP 800-131A) the primitive is subject to The output format is increasingly the **Cryptographic Bill of Materials (CBOM)**, an extension of CycloneDX that captures the above in a machine-readable way. The current spec is CycloneDX 1.6, released July 2024 by the OWASP CycloneDX project, with the cryptography section published as ECMA TR/115. We have a separate article on [CBOM](cbom-crypto-bill-of-materials.md). ## Source Code Scanners Source code scanners examine your codebase for cryptographic API calls. They find things like `Crypto.Cipher.AES.new(...)` in Python, `javax.crypto.Cipher.getInstance("AES/CBC/PKCS5Padding")` in Java, and `crypto/aes` imports in Go. **Open-source options**: - **Semgrep** with cryptographic rule packs. Semgrep is a fast pattern-matching engine for source code. Trail of Bits maintains a `semgrep-rules` repository with rules for weak hash detection, deprecated TLS versions, and similar findings. Custom CBOM-emitting rules can be authored. - **CryptoLyzer** for some specific languages. Smaller scope but precise. - **Bandit** for Python-specific cryptographic anti-pattern detection. - **gosec** for Go. **Commercial options**: - **CryptoBOM Forge** by IBM Research. Open-source but commercially supported. Generates CBOM output. - **Sandbox AQ Security Suite**. Includes Cryptosense, a long-standing crypto inventory product. - **PQShield UltraPQ-Suite**. Focuses on inventory plus migration tooling. - **Tychon CryptoIQ**. Asset-discovery oriented, often combined with network sensors. The strength of source code scanning is precision: you find the exact line where the call happens. The weakness is that it misses cryptography in dependencies. If your code calls `requests.get(url)` and `requests` uses TLS internally, the source scan does not see the TLS negotiation parameters. ## Binary and Dependency Scanners To cover dependencies and shipped binaries, you need a different class of tool. **Open-source options**: - **Trivy** by Aqua Security. Generates SBOMs that can be enriched with CBOM data. Wide language and OS coverage. - **Syft** by Anchore. SBOM generator for containers and filesystems. Complementary to Trivy. - **Detect-It-Easy** for binary analysis. Identifies cryptographic constants and signatures embedded in compiled code. - **YARA rules** with a cryptographic detection ruleset. Useful for finding hardcoded keys, S-boxes, and cryptographic constants in binaries. **Commercial options**: - **Black Duck** by Synopsys. Long-standing software composition analysis tool with cryptographic detection rules. - **JFrog Xray**. SBOM-driven, integrates with Artifactory. - **Mend (formerly WhiteSource)**. Includes some cryptographic discovery. - **SBOM Studio** by Anchore. The strength of binary scanners is coverage of dependencies. The weakness is that they often report library identity (e.g., "uses OpenSSL 3.0.12") without specifying which cryptographic primitives are actually invoked. A library can support 50 algorithms and use 2. ## Network Discovery Tools Network discovery tools observe traffic to identify cryptographic primitives in use. They find things like "this service negotiated TLS 1.2 with `TLS_RSA_WITH_AES_128_CBC_SHA`." **Open-source options**: - **testssl.sh**. The gold standard for TLS configuration audit. Reports cipher suites, certificate details, vulnerable extensions. - **sslyze**. Python library and CLI for TLS scanning. - **Nmap NSE scripts** like `ssl-enum-ciphers`. - **Wireshark** with TLS dissection. Manual but thorough. - **tshark** for scripted analysis of captured traffic. **Commercial options**: - **Quantum Xchange Crypto Discovery**. Network appliance focused on cryptographic inventory at scale. - **InfoSec Global AgileSec Analytics**. Network and endpoint sensors. - **Tychon CryptoIQ** (network deployment). The strength of network discovery is observability of negotiated parameters. It tells you what is actually in use, not what is configured. The weakness is that it only sees external-facing traffic. Internal microservice traffic and offline cryptographic operations are invisible. ## Certificate Discovery X.509 certificates are a special category. Most organizations have hundreds or thousands of them, and discovering them all is a problem in itself. **Open-source options**: - **Certbot inventory tools**. Limited to ACME-managed certs. - **HashiCorp Vault PKI inventory**. If certs are issued by Vault. - **OpenSSL CT log queries**. Search Certificate Transparency logs for issued certificates matching your domains. - **crt.sh**. Web interface to CT logs, scriptable via API. **Commercial options**: - **Venafi Trust Protection Platform**. Long-standing certificate lifecycle product, includes inventory. - **Keyfactor Command**. Similar. - **DigiCert CertCentral**. Vendor-tied but capable for DigiCert customers. - **Sectigo Certificate Manager**. Vendor-tied, similar. Certificate discovery is essential because TLS migration to PQC is gated by certificate availability. We discuss this in [cert lifecycle PQC](cert-lifecycle-pqc.md). ## Runtime and Endpoint Sensors The most comprehensive inventory comes from observing actual runtime cryptographic operations. This requires endpoint instrumentation. **Open-source options**: - **eBPF-based tracers**. Tools like `bpftrace` can hook into glibc or OpenSSL function calls and emit telemetry. Requires kernel support and elevated privileges. - **strace / ltrace**. Heavy but works on any Linux system. - **OpenSSL trace logging**. With `OPENSSL_TRACE` env var, OpenSSL emits operation logs. **Commercial options**: - **Tychon CryptoIQ Endpoint**. eBPF-based endpoint sensor. - **InfoSec Global AgileSec Endpoint**. Similar. - **PQShield UltraPQ-Suite Endpoint**. Runtime sensors give the most accurate inventory because they observe what code actually runs. The weakness is operational cost: you have to deploy and operate the sensor on every relevant host. ## Configuration Scanners Many cryptographic decisions live in configuration data: nginx ssl_protocols, sshd_config Ciphers, ipsec.conf algorithms, app.yaml secret backends. These are easy to scan if you know where to look. - **Ansible inventory queries**. If your config is in Ansible, querying for cryptographic settings is straightforward. - **Salt Pillar / grain queries**. Similar for SaltStack environments. - **kubeconfig and Helm chart scanners**. Specific to Kubernetes deployments. - **Custom regex pipelines**. Often the simplest approach. A grep for `ssl_protocols` across all config data in version control gives a starting point. ## Building a Combined Inventory Pipeline No single tool covers everything. A pragmatic combined pipeline looks like this: 1. **Source code scan** with Semgrep + custom CBOM rules. Catches direct API usage. 2. **Dependency scan** with Trivy or Syft. Catches transitive cryptographic libraries. 3. **Binary scan** with Trivy + YARA rules for compiled artifacts. 4. **Network scan** with testssl.sh on every external endpoint. Catches negotiated TLS parameters. 5. **Certificate inventory** via CT log queries (crt.sh) plus internal PKI export. 6. **Configuration scan** of Ansible, Salt, Helm, or whatever your config-as-code tool is. 7. **CBOM merge**. Combine outputs into a single CycloneDX 1.6 CBOM. 8. **Risk classification**. Score each primitive against PQC migration priority (NIST SP 800-131A guidance, CNSA 2.0 timeline). 9. **Storage and tracking**. Put the CBOM in version control. Re-run quarterly. The total cost of this pipeline depends on scale. For a small org with a single Git repo and a handful of services, it can be implemented in a few engineer-weeks. For an enterprise with thousands of repositories and tens of thousands of services, it is a multi-quarter project. ## CISA's Post-Quantum Cryptography Initiative CISA, NIST, and NSA jointly maintain the Post-Quantum Cryptography Initiative, which publishes guidance and resources for U.S. critical infrastructure. The PQCI website includes a "Quantum-Readiness" roadmap that explicitly calls for cryptographic discovery as the first technical step. CISA's 2025 publication "Quantum-Readiness: Migration to Post-Quantum Cryptography" recommends that organizations: - Establish a project management plan for PQC migration - Engage with vendors about their PQC roadmaps - Conduct an inventory of cryptographic systems and assets - Identify cryptographic systems that protect data with high confidentiality lifetimes - Prioritize migration by risk The inventory step is foundational to all subsequent steps. You cannot prioritize what you have not enumerated. ## Common Inventory Findings Organizations running their first cryptographic inventory typically discover: - **More TLS 1.0 / 1.1 endpoints than expected.** Despite years of deprecation, legacy TLS lingers in admin interfaces, IoT devices, and partner integrations. - **Hardcoded RSA-2048 keys in source code.** Often left from old test fixtures, sometimes committed to version control. - **MD5 and SHA-1 in non-security contexts that turn out to be security contexts.** A "fingerprint hash" used for deduplication might also be used for tamper detection somewhere downstream. - **Inconsistent cryptographic policy across services.** One team uses AES-256-GCM, another uses AES-128-CBC, a third uses AES-256-CTR with no MAC. - **Certificate sprawl.** Hundreds of certs issued by various CAs, many expired, some forgotten on third-party services. These findings are not surprises. They are the normal output of a first inventory. The point is to surface them so they can be addressed. ## CBOM Output Structure: What a Real Entry Looks Like A working CBOM entry under CycloneDX 1.6 looks like this. Every primitive your inventory captures gets a record like the one below, and downstream tools query the JSON for migration planning, risk scoring, or compliance attestation: ```json { "bom-ref": "service-foo-tls-stack", "type": "cryptographic-asset", "name": "TLS_AES_256_GCM_SHA384", "cryptoProperties": { "assetType": "protocol", "protocolProperties": { "type": "tls", "version": "1.3", "cipherSuites": [ { "name": "TLS_AES_256_GCM_SHA384", "algorithms": ["AES-256-GCM", "SHA-384"] } ] }, "oid": "1.2.840.10045.4.3.4" } } ``` Real-world CBOMs accumulate hundreds or thousands of these entries. The `oid` field maps to the X.509 algorithm OIDs registered by ANSI and IANA, which connects cryptographic discovery to certificate inventory cleanly. The `assetType` field can be `algorithm`, `protocol`, `certificate`, `key`, or `relatedCryptoMaterial`, covering all five categories the standard recognizes. Tools that emit valid CycloneDX 1.6 CBOM (Trivy 0.50+, CryptoBOM Forge, Cryptosense, Tychon CryptoIQ) compose cleanly with each other through the `bom-ref` and `dependencies` graph fields. ## Pilot-Phase Inventory: What the First 30 Days Should Look Like For organizations that have never run a cryptographic inventory, the temptation is to procure a commercial tool and wait three months for results. A faster path produces meaningful findings in the first 30 days using only open-source tools and existing source-code repositories. Week 1: Source-code scan. Run Semgrep with the Trail of Bits crypto ruleset against every repository in your primary source-code organization. Ship results to a spreadsheet. Most organizations find 20-50 crypto callsites per medium-sized service, and a handful of weak-hash or MD5 callsites that are quick wins to fix. Week 2: Dependency scan. Run Syft and Trivy against your container registry, every image. Filter the SBOM output for cryptographic library entries (openssl, libsodium, libcrypto, mbedtls, BoringSSL, libgcrypt, BouncyCastle, etc.). Note which versions are running in production. Week 3: External TLS scan. Run testssl.sh against every public-facing hostname in DNS records, plus internal hostnames in your service catalog. Flag any negotiated cipher that uses RSA key exchange, anything below TLS 1.2, anything with a SHA-1 certificate, anything with an RSA-2048 leaf if your retention policy expects post-2030 use. Week 4: Certificate review. Pull all certificates from internal CAs and from CT logs filtered by domain. Bucket by expiration date and by signature algorithm. Files with RSA-2048 leaves and 2030+ expirations are migration candidates. This four-week sprint produces a credible first-pass inventory that covers the high-impact areas. The longer commercial-tool engagement adds depth, but the open-source pipeline is enough to start prioritizing. The lesson from CISA's pilot programs is that organizations that wait for perfect tools never start; the ones that start with imperfect tools eventually have perfect ones. ## Frequently Asked Questions **Is CBOM mature enough to use in production?** Yes. CycloneDX 1.6 includes the CBOM extension. Several open-source and commercial tools emit it. The format is stable and tooling support is growing. **Do I need to inventory cryptography in vendor software?** Yes. NIST and CISA both recommend engaging vendors about their cryptographic posture. A mature procurement process includes asking for a CBOM as part of vendor due diligence. **How long does a first crypto inventory take?** For a small organization (under 10 engineers), 2-4 weeks. For a midsize org (100-500 engineers), 2-4 months. For an enterprise, 6-18 months. The variance is mostly driven by how many systems you have, not by the inherent difficulty. **Should I include hardware cryptography (HSMs, TPMs)?** Yes. The hardware module model number, firmware version, and configured algorithms all belong in the inventory. NIST FIPS 140-3 certification status is a useful field. **How often should I refresh the inventory?** Quarterly at a minimum. Monthly for the parts that change most (CI/CD outputs, deployed services, certificates). The discovery pipeline should be automated so refresh is cheap. **What is the right way to store the inventory?** Treat the CBOM like source code. Commit it to version control. Run it through CI on every change to detect drift. Sign each release of the CBOM with a hardware-rooted signature so downstream consumers can verify provenance. NIST SP 800-218A (Secure Software Development Framework for Generative AI) and NTIA SBOM minimum elements both inform best practice for SBOM custody, and the same patterns apply to CBOM. **How do I handle commercial vendors who refuse to share their CBOM?** Push back on procurement. CISA guidance from 2025 explicitly recommends making CBOM availability a procurement criterion for federal acquisitions, and this is filtering into private-sector contracts. If a vendor will not share at minimum the algorithm list and parameter sizes for cryptography in their product, they cannot credibly support customer PQC migration planning. Contractually require an annual CBOM update through the support agreement. ## Sources 1. NIST SP 1800-38 (Migration to Post-Quantum Cryptography) — https://www.nccoe.nist.gov/crypto-agility-considerations-migrating-post-quantum-cryptographic-algorithms 2. CISA Post-Quantum Cryptography Initiative — https://www.cisa.gov/quantum 3. NIST IR 8547 (Transition to Post-Quantum Cryptography Standards) — https://csrc.nist.gov/pubs/ir/8547/ipd 4. CycloneDX CBOM Specification — https://cyclonedx.org/capabilities/cbom/ 5. NIST SP 800-131A Revision 2 (Transitioning the Use of Cryptographic Algorithms and Key Lengths) — https://csrc.nist.gov/publications/detail/sp/800-131a/rev-2/final 6. CISA Quantum-Readiness Factsheet — https://www.cisa.gov/sites/default/files/2023-08/Quantum-Readiness_Migration_to_Post-Quantum_Cryptography_508c.pdf 7. NTIA Software Bill of Materials Minimum Elements — https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf 8. ECMA TR/115 (Cryptography Bill of Materials) — https://ecma-international.org/publications-and-standards/technical-reports/ ## Related Articles - [How to Inventory Cryptographic Assets](how-to-inventory-cryptographic-assets.md) - [CBOM: The Cryptographic Bill of Materials Standard](cbom-crypto-bill-of-materials.md) - [Crypto-Agility Explained](crypto-agility-explained.md) - [PQC Migration Budget Planning](pqc-migration-budget-planning.md) - [Hybrid Migration Strategy: Step by Step](hybrid-migration-strategy-step-by-step.md) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects data against both current and quantum-era threats. [Try QNSQY](../../pricing.html)