Key Discovery

What key discovery means

Key discovery is the disciplined identification and description of cryptographic keys across an environment. In the terminology of NIST SP 800-57 Part 1 Rev. 5, key inventory information concerns each key but does not include the key itself; examples include the owner, key type, algorithm, application, and expiration date. The inventory normally holds a key identifier or pointer to the location of the key rather than secret or private material. This boundary is central: discovery creates knowledge about cryptographic protection without turning the inventory into a collection of secrets.1

The scope can be broader than a single KMS or HSM. A practical discovery exercise can correlate metadata from key-management systems, PKI systems, HSM systems, hosts, filesystems, binaries, running processes, certificate stores, application repositories, CI/CD pipelines, network interfaces, and other technologies. Keystores and key formats may contain public and private asymmetric keys, including PKCS#12, Java keystores, OpenPGP keys, X.509 certificates, OpenSSH keys, PKCS#1, and PKCS#8. The presence of a format or reference is an inventory fact; it is not a reason to copy its private contents.2

What a useful key-discovery record contains

At minimum, a record should identify the key or certificate reference, owner or sponsor, location or service, key type, algorithm, key length where available, application or purpose, and expiration date. The owner field should answer who or what owns or shares the key and how that party can be contacted. The location may be a KMS key identifier, an HSM object reference, a keystore path, a certificate-store reference, a cloud-resource association, or another pointer that permits authorized operators to find the controlling service without exposing material.1

For operational use, extend the record with protection boundary, lifecycle state, dependencies, provenance, access-control context, rotation or renewal information, and confidence. The protection boundary describes where the key is intended to remain controlled—for example, an HSM, KMS, application host, keystore, or another managed boundary. Lifecycle status should distinguish facts such as active, expired, revoked, compromised, deactivated, suspended, or destroyed when those states are supported by the available evidence. The record should preserve whether a value is observed, inferred, unknown, or redacted rather than presenting an inference as certainty.126

Dependencies make an inventory useful for impact analysis. A certificate may depend on a private signing key, a TLS service, a certificate authority, revocation information, or an application endpoint. A data-encryption key may be protected by a key-encrypting or key-wrapping key. A service may use a key through a protocol or library rather than through an obvious file. TLS 1.3, for example, produces cryptographic parameters through the handshake and protects application records with authenticated encryption; discovery therefore benefits from linking protocol observations to applications, certificates, endpoints, and the relevant key-management records rather than treating a file scan as the entire picture.134

Where discovery should look

Start with authoritative management planes: KMS, HSM, PKI, certificate-management, and cloud-resource records. These sources can provide identifiers, owners, algorithms, states, expiration dates, and protection boundaries. Then examine the systems that consume cryptography: application configuration, source and binary artifacts, libraries, running processes, certificate stores, keystores, network interfaces, and protocol endpoints. The preliminary NIST SP 1800-38B draft describes discovery across executable objects such as application binaries, cryptographic libraries, and Java archives, and nonexecutable objects such as keystores and other key formats.2

Include repositories and delivery infrastructure because cryptographic use can be introduced or changed through software. Discovery evidence may come from application repositories, CI/CD pipelines, firmware and software-update paths, and dependency inventories. CISA, NSA, and NIST advise identifying cryptography in network protocols, end-user systems and servers, applications and associated libraries, and cryptographic code or dependencies in CI/CD pipelines. Correlation with asset, identity, credential, access-management, endpoint, and continuous-diagnostics inventories can reveal relationships that a cryptographic scan alone cannot establish.52

Backups and archives deserve careful treatment. They can establish that a key or certificate has a recovery path, retention period, or historical state, but inspecting them must not silently become key extraction. If an inventory is also used for backup or archiving, its handling requirements change; otherwise, NIST’s inventory guidance says secret or private keys should not be included. Record the existence, authorized location, owner, and access requirements of a backup without copying raw material into the discovery dataset.1

Coverage, limitations, and confidence

A discovery result is not automatically complete. Tools may fail to identify embedded cryptography used internally within products, and organizations may need to ask vendors for lists of embedded cryptography. Password-based encryption of private keys in some keystore formats may also affect the fidelity of discovery results. These limitations should appear in the record or assessment rather than being hidden behind a binary “found” or “not found” label.52

Treat unmanaged keys and unknown ownership as findings requiring validation, not as proof that no owner exists. A record can distinguish direct observation from correlation or inference, identify the source and time of observation, and explain what was inaccessible, redacted, embedded, or unresolved. CISA’s SBOM guidance provides a useful analogous discipline: unknown and redacted components should be distinguishable, and data should be corrected promptly when errors are found. Applied to key discovery, provenance and correction history improve trust in the inventory.267

Confidence should reflect both the quality of the observation and the strength of the relationship. A KMS record that directly identifies an active key and its owner may have high confidence for those fields. A suspected application dependency inferred from code or network behavior may require confirmation. A certificate can be observed while its corresponding private-key location remains unknown. Report those as separate facts so that an apparently complete certificate record does not imply confirmed private-key custody.26134

Using discovery without confusing it with remediation

The inventory becomes actionable when it supports ownership, status monitoring, and reporting to the official responsible for remedial action. Review records for missing owners, expired or soon-to-expire certificates and keys, compromised or revoked states, weak or quantum-vulnerable algorithms, unclear protection boundaries, duplicate aliases, and dependencies on unmanaged systems. The discovery record describes the condition; a separate controlled process decides whether to rotate, revoke, migrate, reconfigure, or retire the object.1

For modernization or post-quantum planning, correlate cryptographic objects with the systems and sensitive datasets they protect. The joint CISA, NSA, and NIST guidance recommends including where quantum-vulnerable cryptography protects critical datasets and estimating the length of protection needed. The preliminary NIST SP 1800-38B draft is explicitly preliminary, and its listed discovery platforms and capabilities are examples from its demonstration environment; individual platforms may have extended capabilities. Preserve that status and limitation when using the evidence to design a program.52

Access control is part of safe discovery. Inventory data can expose sensitive relationships even when it excludes raw keys, so access should be limited to personnel and systems that need it, with accountability for changes and exports. The inventory should support appropriate audit and reporting while respecting the protection boundary of the underlying KMS, HSM, keystore, certificate store, cloud resource, or application.

Conclusion

Key discovery is the controlled creation of a trustworthy, non-secret inventory of cryptographic keys and their relationships. It records references, metadata, ownership, purpose, protection boundaries, lifecycle, dependencies, provenance, and confidence across management systems, applications, files, protocols, cloud resources, repositories, and backups. Its value depends on distinguishing observation from inference, preserving limitations, and keeping inventory separate from key recovery or secret exfiltration. Used this way, discovery gives organizations a defensible basis for ownership, renewal, incident response, and cryptographic migration decisions.152