Mental model
In M11 you saw the Europol/FS-ISAC/CFDIR risk-based prioritization methodology; that methodology starts by building a crypto inventory. This lesson shows how to build that inventory, with five different discovery layers; each layer has its own strength and its own blind spot.
Five layers, five different viewpoints
Network: passively or actively analysing live network traffic to observe which TLS versions, cipher suites and key exchange methods are in use. A fast, non-intrusive method, but it only sees the traffic it can see.
Code: static analysis of source code to find which cryptography libraries are imported and which algorithms are called directly. It works at build time, but can miss an algorithm chosen dynamically at run time (for example one read from a configuration file).
Cert (certificate): using Certificate Transparency logs and direct certificate scanning to find which key types and sizes an organization’s TLS certificates use. A direct application of the certificate chain topics you saw in M7.
Dependency: scanning the libraries a piece of software uses (an SBOM, Software Bill of Materials) to find which cryptographic functions are embedded inside them. The current SBOM Minimum Elements document published on 29 July 2026 by CISA/NSA/FBI (with international partners) defines the minimum data fields an SBOM must carry (SBOM Metadata: about the document itself; Component Data: about the software’s components); it is a comprehensive update of NTIA’s 2021 version, roughly doubling the required data set. This layer is the main input to the CBOM (Cryptography Bill of Materials) you will see in the next lesson: you can think of a CBOM as a crypto-specific extension of an SBOM.
Runtime: directly observing which cryptographic operations a process actually performs while running (for example by hooking a library function). It can catch algorithms chosen dynamically at run time that the static methods (code, dependency) miss, but it adds load and complexity to the production system.
A real blind spot: ECH, which the network layer cannot see
A concrete, current example of the network layer’s limit: ECH (Encrypted Client Hello, RFC 9849, with FINAL2026-03-01 status, became a full standard in 2026 after a long time as a draft) is a TLS 1.3 extension that encrypts the contents of a client’s ClientHello message (including the SNI, the target hostname). With ECH enabled, a network observer (a passive traffic analysis tool) sees an encrypted_client_hello extension in the ClientHello but cannot see the real target hostname; only a generic “public name” belonging to the ECH provider is visible. It can be understood with a “two envelopes” analogy: the outer envelope shows a generic address, and the real address is inside the inner (encrypted) envelope. For a network-based crypto discovery program, this is a growing blind spot: as ECH spreads, answering “which service is being talked to, with which algorithm” just by looking at network traffic becomes steadily harder.
A similar blind spot applies to east-west traffic in a microservice architecture (service-to-service traffic, “east-west” rather than “north-south”): this traffic is usually encrypted (for example with mTLS) and never appears at the network boundary (the organization’s external gateway), because it never leaves. These two examples are concrete evidence of why a single layer (network) is not enough on its own; the code, dependency and runtime layers catch the real cryptography behind this traffic, which the network cannot see, from other angles.