Cryptographic Discovery and PQC Readiness Tools Buyer’s Guide: How to Evaluate and Prove Them

Every post-quantum migration plan starts with a cryptographic inventory, and most organisations cannot build one by hand because cryptography is buried in protocols, libraries, binaries, keys and devices that nobody has catalogued. A market of cryptographic discovery and PQC readiness tools has grown to fill that gap, driven by official deadlines such as the UK NCSC's 2028 milestone for full discovery and a migration plan, and US federal requirements for annual inventories of quantum-vulnerable systems. This vendor-neutral buyer's guide explains what these tools do, which discovery methods matter, how to test claims in a proof of concept and how to fit the output into your PKI, key management and machine identity programmes. It is for cryptography owners, security architects and procurement teams. How to structure the inventory itself is covered in the Cryptographic Inventory and CBOM Guide.

Key takeaways

• No single discovery method finds everything. Network scanning sees protocols in use, host and code scanning see libraries and keys at rest, and connectors see what PKI, HSM and KMS platforms already know. Buy coverage across methods, or plan to combine tools.
• The output must be portable. Insist on export in CycloneDX CBOM (part of the ECMA-424 standard), so your inventory is not locked into one product.
• Prioritisation is the real value. A list of a million RSA usages is useless; tools must tie findings to assets, owners, data lifetimes and deadlines.
• Most keys belong to machines. Certificates, SSH keys, code signing and token signing keys are non-human identities, so integration with certificate lifecycle and secrets tooling decides whether findings get fixed.
• Prove it on your estate. Seed a test environment with known cryptography and measure what each tool finds, misses and misclassifies before you sign.

What the category does

Cryptographic discovery tools locate where an organisation uses cryptography, describe each use in enough detail to judge its quantum risk, and track remediation. CISA describes automated cryptography discovery and inventory tools as tools that automate the collection of the cryptographic characteristics needed for an inventory. NIST's National Cybersecurity Center of Excellence runs a Migration to PQC project with a cryptographic discovery workstream, and its draft SP 1800-38B includes a functional test plan for exercising discovery tools.

The discovery technique comparison above draws on our own assessment of how each method works; vendors combine them differently, which is why the proof of concept below matters.

When you need it

• A deadline needs evidence: the NCSC expects organisations to complete a full discovery exercise and an initial plan by 2028, US federal agencies must deliver annual inventories of quantum-vulnerable systems under NSM-10, and national security system suppliers face CNSA 2.0 acquisition rules from 1 January 2027. See the Post-Quantum Cryptography Deadlines Tracker.
• The estate is too large for spreadsheets: hundreds of applications, multiple clouds, an internal PKI and HSMs.
• You need continuous, not one-off, inventory: cryptography changes with every release, and the inventory has to stay current through a migration that runs to 2035.
• Auditors or customers ask for a CBOM: regulated sectors and large customers increasingly request evidence of crypto inventory and agility.

When you may not: a small organisation running mainly SaaS and managed cloud services may get most of what it needs from cloud provider reports, its certificate lifecycle tool, an external TLS scan and supplier questionnaires. Start there and buy a dedicated tool only when gaps appear.

Must-have capabilities

• Multi-method discovery: at least network or protocol scanning plus host or code scanning, plus connectors to your CAs, cloud KMS and HSMs.
• Rich classification: algorithm, primitive (for example signature, key agreement or KEM), parameter set or key size, curve, protocol and version, library and version, and certificate details. CycloneDX 1.6 models these as asset types algorithm, certificate, protocol and related crypto material, with a nistQuantumSecurityLevel field where 0 means no NIST post-quantum security category is met.
• Quantum risk rating: flags quantum-vulnerable public key algorithms and weak symmetric parameters, mapped to NIST and, where relevant, CNSA 2.0 requirements (ML-KEM-1024, ML-DSA-87, AES-256).
• Asset and owner context: links each finding to an application, host, business service and owner from your CMDB or asset inventory.
• Prioritisation inputs: data sensitivity and confidentiality lifetime, exposure (internet-facing or internal) and dependency on suppliers.
• CBOM export and API: CycloneDX CBOM output (version 1.6 or later) and an API for your GRC, CMDB and ticketing tools.
• Change tracking: continuous or scheduled rescans with diffs, so you can show progress and catch regressions.
• Secure handling of what it finds: a tool that reads keystores must never copy private key material into its own database.

Evaluation criteria

Questions to ask vendors

1. Which discovery methods does the product use, and which parts of our estate will each method not see?
2. How do you detect cryptography inside TLS 1.3 sessions, containers built after a scan and third-party binaries?
3. Do you export CycloneDX CBOM, which version, and does the export include parameter sets, library versions and relationships to components?
4. How do you classify hybrid key exchange and PQC algorithms such as ML-KEM and ML-DSA, and how often are classification rules updated?
5. What privileges do scanners, agents and connectors need, and can any component read or copy private keys?
6. How is the risk score calculated, and can we change the weighting for data lifetime and exposure?
7. Which CAs, CLM platforms, cloud KMS services and HSM models do you integrate with today?
8. How do you show progress over time against dates such as the NCSC 2028 and 2031 milestones?
9. Where is our inventory data stored, who can access it and how is it protected, given it is effectively a map of our cryptographic weak points?
10. What evidence do you have from independent testing, such as participation in the NCCoE Migration to PQC project or published accuracy tests?

Red flags

• "Complete visibility" claims from a single discovery method.
• No CBOM or other open export format, or an export that drops parameter detail.
• Dashboards that count "quantum-vulnerable assets" without showing raw evidence per finding.
• Agents or connectors that require write access to keystores, CAs or HSMs, or that extract key material.
• Risk scores you cannot inspect or adjust.
• Deadlines quoted wrongly, for example treating draft NIST dates as final rules.

Deployment and integration

Where identity fits: most findings will be keys and certificates held by non-human identities: TLS endpoints, workload mTLS certificates, SSH keys, code signing keys and identity provider token signing keys. Route those findings to the teams and tools that already own machine identities, so remediation happens through certificate reissue and key rotation rather than one-off tickets. See the Post-Quantum Migration for NHIs Guide and the CLM Buyer's Guide.

1. Connect authoritative sources first: CAs, CLM, cloud KMS and HSMs give a reliable baseline quickly with read-only access.
2. Add external and internal network scanning: start with internet-facing services, then internal segments with change approval for scan windows.
3. Add host and code scanning in pilot rings: a small set of servers and repositories first, checking performance and false positives, then expand.
4. Integrate with CMDB and ownership data: findings without owners do not get fixed.
5. Feed ticketing and the migration plan: create work items by application and owner, not by individual finding.
6. Roll back safely: agents and connectors should be removable without residue; keep the last exported CBOM so the inventory survives a change of tool.

Protect the tool itself as a sensitive system: its database describes every weak cryptographic dependency you have. Give its service accounts least privilege, monitor their use and review access to findings. See the Cryptographic Key Management Guide.

Pitfalls

• Buying before scoping: without a list of environments and data lifetimes, you cannot judge coverage or prioritisation.
• Inventory as a project, not a process: a one-off scan is out of date within a release cycle.
• Ignoring suppliers: discovery tools cannot see inside SaaS and managed services; pair them with supplier questionnaires and contract clauses.
• Treating PQC readiness as the only goal: the same inventory finds expired certificates, weak legacy algorithms and unmanaged keys, which often deliver faster risk reduction. See the Weak Cipher and Legacy Protocol Retirement Playbook.
• No agility plan: finding RSA is easy; replacing it needs crypto-agile architecture. NIST's crypto agility white paper (CSWP 39, published December 2025 and updated in June 2026) covers the strategies. See the Crypto-Agility Guide.

Proof of concept

1. Build a seeded test environment with known cryptography: TLS endpoints using RSA-2048, ECDSA P-256 and a hybrid ML-KEM group; SSH hosts with RSA and Ed25519 keys; a repository with crypto API calls and a vendored library; a container image with a keystore; a cloud KMS key and an HSM partition.
2. Run each candidate tool with the same scope and privileges, and record findings per seeded item: found, missed or misclassified.
3. Export a CBOM from each tool and validate it against the CycloneDX schema; check that parameter sets and library versions survive export.
4. Connect to one production CA and one cloud KMS in read-only mode and compare the tool's view with the platform's own records.
5. Change one seeded item (for example rotate a certificate to a stronger key) and confirm the rescan shows the change.
6. Review the tool's privileges, data storage and audit logs with your security architecture team.
7. Score results against the evaluation criteria table and record the evidence for procurement.

Buyer checklist

• Environment list and data lifetime classification completed before vendor demos.
• Discovery methods mapped to every environment, with gaps assigned to another tool or process.
• CycloneDX CBOM export validated in the proof of concept.
• Seeded known-answer test run with recorded found, missed and misclassified rates.
• Read-only privileges confirmed; no extraction of private keys.
• Integration with CA, CLM, KMS, HSM, CMDB and ticketing demonstrated on your instances.
• Risk scoring model reviewed and adjustable.
• Reporting against NCSC, NIST and, where relevant, CNSA 2.0 dates confirmed against official sources.

Framework mapping

Use the mapping to write requirements into the procurement: ask the vendor to show, on your data, the report you would hand an auditor for each row.

Standards and references

• CISA: Strategy for Migrating to Automated Post-Quantum Cryptography Discovery and Inventory Tools
• NIST: SP 1800-38 Migration to Post-Quantum Cryptography (preliminary draft)
• NIST NCCoE: Migration to Post-Quantum Cryptography project
• CycloneDX: Cryptography Bill of Materials (CBOM)
• CycloneDX: Specification (ECMA-424)
• NCSC: Timelines for migration to post-quantum cryptography
• NIST: IR 8547 Transition to Post-Quantum Cryptography Standards (Initial Public Draft)
• NIST: CSWP 39 Considerations for Achieving Cryptographic Agility

How NHI Mgmt Group can help

We provide independent requirements and evaluation support for cryptography, PKI, machine identity and NHI programmes. Browse vendors in our products directory or contact us.

Related NHI Mgmt Group resources: Cryptographic Inventory and CBOM Guide · Post-Quantum Cryptography Migration Guide · NIST IR 8547 PQC Transition Timeline Guide · Post-Quantum Cryptography Deadlines Tracker