Quick answer: No single scanning layer finds all the cryptography in a real enterprise environment. A complete discovery program needs seven distinct approaches working together: network traffic scanning (what’s actually negotiated on the wire), source-code scanning (what’s hardcoded before it ever runs), binary analysis (what’s compiled into applications you don’t have source access to), cloud inventory scanning (keys and certificates managed by cloud provider APIs), certificate discovery (crawling certificate transparency logs and internal stores), endpoint agents (what’s configured on individual machines, drivers, disk encryption, local stores), and manual evidence collection for the systems none of the automated layers can reach. Each layer has real, specific blind spots the others cover; treating any single layer as sufficient is the most common reason a “complete” inventory turns out not to be.
NIST’s NCCoE migration guidance and CISA’s quantum-readiness resources both treat cryptographic discovery as the mandatory first phase of PQC migration, but neither prescribes a single tool. That’s appropriate, because no single tool covers the full surface. This guide breaks down what each discovery layer actually finds, what it misses, and how the layers fit together into a complete program.
Key Takeaways
- Seven distinct discovery approaches, network, source code, binary, cloud, certificate, endpoint, and manual, each cover ground the others miss.
- Network scanning finds what’s actually negotiated in live traffic but misses cryptography that never crosses the network, like local disk encryption or offline signing.
- Source-code scanning catches hardcoded algorithm calls before deployment but cannot see cryptography configured at runtime or embedded in compiled dependencies without source access.
- Certificate transparency log crawling finds every publicly trusted certificate for a domain, including ones issued outside your own certificate management process entirely.
- No automated layer reaches air-gapped systems, legacy hardware without agent support, or undocumented shadow IT; manual evidence collection remains a required, not optional, part of a complete program.
The Seven Discovery Layers
1. Network Traffic Scanning
Passively or actively captures the actual algorithms negotiated in live TLS, SSH, and IPsec traffic, giving a ground-truth picture of what’s really running, as opposed to what a configuration file claims is running. This is the layer most likely to surface configuration drift: a server documented as TLS 1.3-only that still, in practice, negotiates a classical-only cipher suite for some client population. Its blind spot is exactly the flip side of that strength: it only sees what actually crosses the network during the observation window, missing cryptography for infrequently used paths, offline processes, and anything not exercised while scanning is active.
2. Source-Code Scanning
Statically analyzes application source code for hardcoded algorithm calls, import statements, and cryptographic library usage, catching problems before they ever reach production. This is the only layer that can flag a hardcoded RSA call buried in application logic before deployment, which is valuable specifically because that kind of finding is expensive to fix later and cheap to fix at the code-review stage. Its blind spot: it cannot see cryptography configured at runtime through environment variables or external configuration, and it needs source access, which rules out third-party and vendor-supplied binaries entirely.
3. Binary Analysis
Fills exactly the gap source-code scanning leaves: examining compiled binaries, firmware images, and container images directly for embedded cryptographic libraries and algorithm signatures, without needing source access. This is essential for third-party software, commercial off-the-shelf applications, and firmware where you have no visibility into the build process. Its trade-off is depth versus source scanning: binary analysis can identify which cryptographic libraries are present and often their version, but has a harder time determining the exact runtime configuration those libraries are actually using.
4. Cloud Inventory Scanning
Queries cloud provider APIs directly, AWS KMS, Azure Key Vault, Google Cloud KMS, and equivalent services, to inventory keys, certificates, and their configured algorithms as reported by the provider itself. This is the most reliable source of truth for cloud-managed cryptography, since it reads the provider’s own record rather than inferring configuration from observed behavior, covered in more depth in our cloud shared responsibility guide. Its blind spot is scope: it only covers what’s provisioned through the cloud provider’s own key management services, missing application-layer cryptography running inside compute instances that the provider has no visibility into.
5. Certificate Discovery
Crawls Certificate Transparency logs and internal certificate stores to build a complete picture of every publicly trusted certificate issued for your domains, including certificates issued outside your own tracked certificate management process entirely, a shadow-IT problem that is more common than most organizations expect. Internal certificate store scanning covers private PKI certificates that never touch a public CT log. The combined blind spot: certificates that are neither publicly trusted nor tracked in a scanned internal store, typically self-signed certificates generated ad hoc by individual applications or developers.
6. Endpoint Agents
Software agents installed on individual machines that inventory locally configured cryptography invisible to every other layer: disk encryption configuration, driver and firmware signing chains, Secure Boot trust anchors, and locally stored certificates and keys, the full scope covered in our endpoint blind spot guide. This is the only layer that reaches this specific surface. Its blind spot is deployment coverage: an endpoint agent only sees machines it’s actually installed on, which means unmanaged devices, contractor laptops, and any endpoint outside your device management program remain invisible to it by definition.
7. Manual Evidence Collection
The layer every automated approach eventually needs as a backstop: air-gapped systems no scanner can reach, legacy hardware too old to support any current agent, and undocumented shadow IT that no inventory process was ever aware of to begin with. This is the most labor-intensive layer and the easiest to skip, which is exactly why it needs to be a scheduled, tracked activity, interviews with system owners, physical audits of isolated environments, rather than an informal catch-all assumed to happen organically.
Coverage Matrix: What Finds What
| Layer | Strongest at | Misses |
|---|---|---|
| Network scanning | Live, ground-truth negotiated algorithms | Infrequent paths, offline processes |
| Source-code scanning | Pre-deployment hardcoded findings | Runtime config, third-party binaries |
| Binary analysis | Third-party software, firmware, containers | Exact runtime configuration |
| Cloud inventory | Provider-managed keys and certificates | In-instance application cryptography |
| Certificate discovery | Public and internally tracked certificates | Untracked self-signed certificates |
| Endpoint agents | Disk encryption, drivers, Secure Boot, local stores | Unmanaged or unenrolled devices |
| Manual evidence | Air-gapped and legacy systems | Scales poorly, easy to skip |
What We’d Actually Recommend
Deploy multiple layers deliberately from the start rather than treating one tool’s output as a complete inventory; the overlap between layers is what catches findings any single approach would miss on its own. Prioritize the layers matching your actual environment’s composition, heavier on cloud inventory and endpoint agents for a cloud-native, managed-device environment, heavier on binary analysis and manual evidence for an environment with significant legacy or air-gapped infrastructure. Schedule manual evidence collection as a tracked activity with defined scope, not an informal assumption, since it is the layer most likely to get skipped under program time pressure despite covering ground no automated layer reaches.
How Encryption Consulting Can Help
CBOM Secure combines multiple discovery layers, network, cloud, certificate, and endpoint scanning, into a single deduplicated inventory output, so overlapping coverage across layers gets reconciled into one record per asset rather than requiring manual correlation across separate tool outputs.
Our PQC Advisory Services design the complete discovery program for your specific environment, including the manual evidence collection plan for air-gapped and legacy systems that no automated tool, ours or anyone else’s, can reach on its own.
Coverage Is a Program, Not a Purchase
No single scanning tool, however capable, covers the full cryptographic surface of a real enterprise environment, and treating discovery as a single-product purchase decision rather than a multi-layer program is where inventory gaps quietly accumulate. Network, source code, binary, cloud, certificate, endpoint, and manual evidence collection each cover real, distinct ground, and the blind spots one layer leaves are almost always covered by another. Building the program around that overlap, deliberately, is what actually gets to a complete inventory rather than a confident but partial one.
Frequently Asked Questions
Is one discovery tool ever sufficient for a complete cryptographic inventory?
Rarely, for any environment beyond a small, homogeneous one. Most enterprise environments span cloud, on-premises, legacy, and endpoint infrastructure, each of which is best covered by a different discovery approach, so a complete inventory typically requires multiple layers working together.
Why does network scanning alone miss so much cryptography?
It only sees what actually crosses the network during the scanning window. Cryptography that never touches the network, disk encryption, offline signing, infrequently used paths not exercised during the scan, remains invisible to this layer by design.
What does certificate transparency log crawling find that internal scanning misses?
Publicly trusted certificates issued for your domains outside your own tracked certificate management process, a common shadow-IT gap where a team or individual obtains a certificate without going through central PKI processes.
Why is manual evidence collection still necessary given how mature automated discovery tools have become?
Air-gapped systems, legacy hardware without agent support, and undocumented shadow IT remain outside the reach of any automated scanning layer. These environments require direct interviews and physical audits, which no tool can substitute for.
Which discovery layer should an organization prioritize first?
Depends on environment composition. Cloud-native organizations should prioritize cloud inventory and network scanning; organizations with significant legacy or on-premises infrastructure should prioritize binary analysis, endpoint agents, and manual evidence collection.
