How Cryptographic Discovery Works, And What Each Method Misses

Discovery is the work of finding where cryptography is actually used, as opposed to where documentation says it is used. It is the raw material for the inventory described in the previous article, and it is harder than it sounds. Cryptography sits inside network protocols, application code, libraries, operating systems, hardware modules and third-party services, and no single technique can see all of those places.

This article describes the main discovery methods, what each one can and cannot see, and why their results need cleaning up before anyone makes decisions with them.

Why Automation Is Expected

OMB’s memorandum M-26-15 says manual approaches to finding and managing cryptography are often insufficient at the scale of a large organisation.¹ For US federal agencies it points to three kinds of tool: software composition analysis (SCA), which reads software bills of materials (SBOMs) to see which libraries are bundled; static and dynamic application security testing (SAST and DAST), which look for cryptographic calls in code; and network scanners, which report the protocols and cipher suites a service offers. Their output is meant to land in one central cryptographic bill of materials.¹

NIST’s National Cybersecurity Center of Excellence (NCCoE) took a similar line in its discovery project, combining active and passive techniques and drawing on tools many organisations already run, such as code repositories, governance and risk platforms, security information and event management (SIEM) systems and configuration management databases (CMDBs), the records many IT teams keep of their servers and applications.²

The Main Methods

Active network scanning connects to services and records what they offer: protocol versions, cipher suites, key exchange groups and certificates. It is precise about what a reachable service supports, though what a service offers is not always what clients actually use.

Passive network monitoring reads traffic that is already flowing. It shows what clients and servers actually negotiate in daily use. The NCCoE met practical limits in its demonstration set-up: mirroring traffic in the cloud depended on what the provider supported, and traffic from remote, organisation-managed laptops could not be sent to its discovery platform in real time, so it was captured to files and forwarded later.² Passive data can also be less exact. Some application protocol identifiers are deliberately reused, for example DNS over HTTPS uses the same identifier as ordinary HTTPS, so an active scan gives a more accurate answer.²

Code and binary analysis looks inside software for calls to cryptographic functions, hard-coded algorithms and keys. Software composition analysis checks which libraries are bundled and at what versions.

Host and configuration inspection reads certificate stores, key files, configuration files and installed packages on servers and endpoints.

Asset and supplier records cover what cannot be scanned: software-as-a-service (SaaS) platforms, managed services and sealed appliances. The CISA, NSA and NIST factsheet tells organisations to ask vendors about their post-quantum roadmaps, and OMB asks agencies to agree post-quantum responsibilities with cloud providers under the shared responsibility model.³¹

What Each Method Can See

The table below is our own summary, reasoned from how each method works and from the NCCoE and OMB descriptions. It is not a published benchmark, and even a “good” rating only holds for the systems a method can actually reach. As of October 2026 we are not aware of an independent, primary-source study measuring the accuracy of discovery tools, so treat any vendor claim of complete discovery as the vendor’s own claim.

The pattern is the useful part. Network methods see what is negotiated but not what is stored or hard-coded. Code analysis sees what is written but not what is configured at runtime. Supplier questionnaires reach places you cannot scan, but they rely on the supplier’s word.

Turning Raw Findings Into Usable Data

Each tool reports in its own format. The NCCoE gives a small example: one tool records a host as host.example.com:443 while another drops the port. Without normalising the results, the same system appears twice or not at all.² The NCCoE chose a common interchange format so that discovery output could feed risk analysis, and OMB names the CBOM as the place where the data should land.²¹

Labelling also needs care. The NCCoE warns that reporting every quantum-vulnerable algorithm as a conventional software weakness could produce many false positives, because the weakness only becomes real under certain conditions.² A finding should carry context, such as the data protected and the shelf life, before it is treated as a defect.