Discovery Best Practices

1. Define scope by outcome

The first question is not “Which scanner should we run?” It is “Which decisions must discovery support?” A migration or crypto-agility program may need to identify systems, applications, protocols, infrastructure, and usage elements that depend on algorithms being replaced. That makes discovery an input to planning, prioritization, migration playbooks, and risk treatment—not merely a list of filenames or certificates. The scope should therefore state the decisions, populations, and evidence quality needed for each use case. The cited preliminary draft describes discovery use cases across code, compiled binaries, dependencies, end-user systems and servers, applications and libraries, and network protocols, including traceability to systems through active scanning and historical traffic captures.1

A useful scope normally includes cryptographic keys and keystores; X.509 certificates; cryptographic libraries and algorithms; protocols; code and repositories; compiled binaries and dependencies; hosts, servers, applications, and end-user systems; network interfaces and observed traffic; PKI, key-management, and HSM systems; and supplier or cloud-hosted products. This is a risk-based scope, not a claim that every organization must collect every field in every environment. The appropriate boundary depends on the decisions being made, the organization’s risk strategy, and the systems that are actually in use. NIST describes key-management concerns that include key usage, public-key validation, key-inventory management, accountability, audit, and algorithm and key-size selection.2

2. Combine multiple evidence methods

No single observation method answers every discovery question. Repository and CI/CD analysis can identify cryptography in source code, dependencies, and build artifacts. Binary and filesystem analysis can find implementations that source review does not expose. Host and endpoint collection can examine applications, libraries, certificate stores, running processes, and other local evidence. Network methods can identify protocols and systems associated with active communications, while historical traffic captures can provide additional traceability. PKI, certificate, key-management, and HSM records provide authoritative operational context that may not appear in application code. The preliminary NIST practice guide describes collection across hosts, filesystem and binary data, running processes, certificate stores, network interfaces, CI/CD pipelines, application repositories, key-management systems, PKI systems, and HSM systems.1

Use methods according to the question being answered. Repository evidence is useful for what developers declared or built; runtime and network evidence help determine what is operating or communicating; certificate and key-management evidence helps establish managed identities and key relationships; supplier evidence helps address products that the organization cannot inspect directly. For development pipelines, security practices can be integrated into software development, builds, packaging, distribution, and deployment, with automatically generated security and compliance artifacts. A representative code base may also be scanned before pull or merge requests so findings can be reviewed before code enters the main branch.1

Use more than one method where the consequences of omission are material. Compare results rather than assuming that disagreement means one source is wrong. A library found in a repository but absent from a running process may be unused, conditionally loaded, replaced at build time, or missed by runtime observation. Conversely, an active protocol or certificate may be generated or managed outside the repository. The inventory should preserve each observation and its source so that reconciliation remains possible.1

3. Establish identifiers, provenance, and confidence

Every record should have an authoritative or reproducible identifier appropriate to the object: a component name and version for software, a certificate and public-key identifier where applicable, a repository and revision, an image digest or equivalent immutable artifact reference, a host or service identity, or a supplier product and version. Identifiers should not be treated as interchangeable labels. CISA’s 2025 SBOM minimum-elements passage distinguishes component name from software identifiers and notes that component name formats should allow alternate names without introducing confusion. RFC 5280 describes subject key identifiers as a means of identifying certificates containing a particular public key and authority key identifiers as supporting certification-path construction.45

Provenance answers how a record was obtained, from which system, at what time, with which collector or analysis method, and from which artifact or observation. Preserve the source record rather than only the normalized result. The SSDF evidence passage explicitly identifies provenance, artifact, and evidence as defined concepts in the 2022 version. For certificates and keys, retain the relationship between the observed object and its issuing, owning, or managing authority when that relationship is supported by evidence. For software, retain repository, build, package, image, or supplier context as available.6

Confidence should describe the strength and limitations of the evidence, not disguise uncertainty as a binary answer. A signed artifact with a stable identifier and corroborating runtime observation may support higher confidence than a heuristic string match. A supplier assertion may be useful but should remain distinguishable from direct observation. Record why confidence was assigned, what evidence would raise or lower it, and whether the observation establishes presence, active use, configuration quality, or only a possibility.613

4. Separate presence, active use, and configuration quality

Discovery should produce separate fields for at least three questions. Presence asks whether an algorithm, library, key, certificate, protocol, or related object exists in an artifact, system, repository, or record. Active use asks whether the object is loaded, executed, negotiated, issued, trusted, or otherwise participating in an operational path. Configuration quality asks whether the implementation and surrounding settings meet the organization’s requirements. These states can differ: a dependency can be present but unused; a protocol can be enabled but not observed; and a certificate can exist while validation or trust configuration is unsafe.13

The distinction matters because configuration evidence is not inferred safely from presence alone. NIST’s container guidance calls for validation of image configuration settings against vendor recommendations and third-party best practices, centralized and continuously updated compliance reporting, and optional enforcement that prevents noncompliant images from running. NIST’s secure-development guidance similarly recommends documenting each configuration setting’s purpose, options, default value, security relevance, operational impact, and relationships with other settings, and recording how the setting can be implemented and assessed.36

For protocols and certificates, active use also requires careful interpretation. TLS 1.3 guidance warns that a connection may lack verifiable server authentication if certificate-chain validation or equivalent external authentication is absent, and that such a connection is unsafe for general use without another validating mechanism. Thus, “TLS observed” is not equivalent to “TLS is securely configured.”7

5. Collect with least privilege and validate representative results

Collection should use the minimum access needed for the defined outcome. Prefer metadata, hashes, configuration state, process and protocol observations, and approved interfaces when those are sufficient. Restrict access to source, private keys, keystores, secrets, traffic captures, and administrative systems. Redact or tokenize secret values before storing or transmitting discovery results, and keep sensitive raw evidence separate from the broader inventory. NIST key-management guidance emphasizes protecting secret values from disclosure and maintaining chain of custody in procedures involving those values.2

Least privilege does not mean collecting too little to answer the question. Define what evidence is required before collection begins, document permissions and exclusions, and make failures visible. A record that says “not collected” is more useful than an apparently clean result produced by an unauthorized or incomplete query. Collection plans should also address managed and unmanaged applications and systems, because administrative visibility can differ across them. NIST’s mobile-application guidance distinguishes managed applications from unmanaged personal-use applications and notes that managed applications can be controlled through their deployment lifecycle.8

Validate the method on a representative sample before treating results as organizationally meaningful. Include different operating systems, application types, deployment patterns, programming languages, certificate authorities, key stores, cloud and on-premises environments, and supplier products where those populations are in scope. Review true positives, false positives, missed cases, duplicate records, and ambiguous states with the responsible technical owners. Where the sample is not representative, say so and avoid extrapolating its result to the entire population.138

6. Measure coverage and freshness; deduplicate and manage exceptions

Coverage should have an explicit denominator and dimension. Examples include the proportion of in-scope repositories analyzed, production services mapped to an owner, certificates linked to a system, endpoints reporting within the collection window, or suppliers providing evidence for products in use. Freshness should identify when the evidence was observed and when it was last confirmed. Do not collapse these measures into one score: high repository coverage does not prove runtime coverage, and recent collection does not prove complete scope. NIST’s container guidance supports centralized reporting and monitoring that is continuously updated, while the CSF 2.0 describes maintaining and replacing software and generating log records for continuous monitoring in accordance with risk strategy.39

Deduplication should merge observations only when identity and equivalence are supported. Keep alternate names, versions, artifact references, and source observations rather than discarding them. A certificate, public key, key pair, service endpoint, software package, and running process may be related without being the same inventory object. Use authoritative identifiers where available, and preserve a relationship graph when one object is issued by, embedded in, loaded by, or observed on another. [claim-0645

Exceptions are part of governance, not an informal bypass. Each exception should state the affected object or population, reason, risk owner, compensating measure, approval, evidence, start date, review date, and exit condition. Update records of design decisions, risk responses, and approved exceptions as circumstances change. SSDF examples specifically include updating such records as needed while addressing vulnerabilities and temporary remediations.6

7. Connect ownership, change, suppliers, and remediation

An inventory becomes actionable only when each material record has an accountable owner or an explicit ownership gap. Ownership may be divided among a service owner, application maintainer, platform team, certificate or PKI administrator, key custodian, supplier manager, and risk owner. Route findings with enough context to act: affected object, authoritative identifier, evidence and timestamp, presence/use/configuration state, confidence, impact, recommended decision, and known dependencies. DevSecOps practices use repository controls, automated builds, security testing, and controlled merge or pull requests with multiple approvers to reduce risk while allowing delivery.10

Integrate discovery with change. New repositories, builds, package releases, infrastructure changes, certificate issuance, key-management changes, deployments, and supplier updates should create or refresh evidence. For active development, scanning before pull or merge requests can flag potential cryptographic issues before approval; for existing environments, scheduled or event-driven collection can update the baseline. The evidence does not establish one universal frequency: release cadence and operational risk differ, and continuous monitoring or event-triggered collection may be appropriate for some populations while periodic review is sufficient for others. [claim-051

Supplier and cloud evidence should be treated as a defined evidence stream. CISA, NSA, and NIST state that engagement with vendors on their post-quantum-cryptography roadmaps is critical and recommend capturing when and how commercial products plan to deliver updates or upgrades, including expected migration cost. For cloud-hosted products, organizations should engage cloud service providers about their roadmaps and later focus on enabling post-quantum cryptography through configuration or application changes when standards are available.11

Remediation handoff should close the loop. A finding is not complete when it is exported; it is complete when the owner confirms the change, the evidence is refreshed, and the resulting state is recorded. Where a permanent fix is unavailable, document temporary remediation, workarounds, risk responses, and approval. Security advisories should explain what the vulnerability is, how to find instances, how to address it, and what configuration changes or temporary workarounds may be needed. [claim-146

8. Use a practical maturity sequence

A staged sequence helps an organization improve without waiting for an ideal platform. The stages below are a practical operating model derived from the evidence requirements above; they are not a claim that every organization must implement them on a fixed timetable.13

1. Define outcomes, in-scope populations, risk priorities, evidence fields, and explicit exclusions.
2. Establish a minimum inventory model with authoritative identifiers, provenance, timestamps, ownership, confidence, and separate presence, active-use, and configuration states.
3. Collect from the highest-value evidence sources, then add complementary repository, binary, host, runtime, network, PKI, key-management, HSM, and supplier evidence as justified by the outcomes.
4. Validate methods against representative samples; measure false positives, missed cases, duplicate rates, coverage, freshness, and unresolved ownership.
5. Integrate evidence generation with CI/CD, build and release processes, certificate and key-management workflows, deployment changes, and supplier engagement.
6. Operationalize remediation, exception review, change-triggered refresh, periodic governance review, and improvement based on observed blind spots.

At every stage, retain uncertainty and limitations. A mature program is not one that claims to see everything; it is one that can explain what it sees, how it knows, what it cannot see, who is accountable, how recently the evidence was collected, and what action follows.136

9. Review the discovery system itself

Periodic review should examine whether scope still matches business and technology changes, whether evidence sources remain authoritative, whether collectors still work, whether identifiers are stable, whether confidence assignments are justified, and whether coverage and freshness metrics expose meaningful gaps. Review unresolved exceptions, supplier roadmap changes, new deployment patterns, new certificate or key-management arrangements, and changes to cryptographic policy. The review interval should be risk- and change-informed rather than presented as a universal scan frequency.3911

Use review findings to improve collection and decision paths. If a remediation repeatedly lacks an owner, fix the ownership model. If runtime evidence regularly contradicts repository evidence, improve build and deployment linkage. If suppliers provide only broad assertions, define more precise evidence requests. If configuration quality cannot be assessed, document the required settings and authoritative assessment mechanisms before expanding collection. [claim-093610

Conclusion

Effective cryptographic discovery is a governed, evidence-based capability. Define outcomes and scope; combine complementary methods; use authoritative identifiers and preserve provenance; protect collection; distinguish presence from active use and configuration quality; validate representative results; measure coverage and freshness; deduplicate without losing relationships; manage exceptions; and connect findings to owners, suppliers, change processes, and remediation. Improve in stages and report uncertainty honestly. This produces an inventory that supports migration and crypto-agility decisions without claiming perfect completeness or relying on a universal scanning schedule.13456910