The process of scanning developer and user machines for tokens, keys, certificates, and other credentials that standard repository or vault controls may miss. It is a control for exposure identification, and it becomes more valuable when linked to ownership and revocation workflows.
Expanded Definition
Endpoint secret discovery is the practice of finding credentials on laptops, desktops, and developer workstations when those secrets have escaped vaults, scanners, or repository controls. It sits alongside secret detection, but its scope is narrower and more operational: the endpoint becomes the last line of visibility for keys, tokens, certificates, and cached session material that may never appear in source control.
In NHI security, the concept is closely tied to exposure identification, ownership resolution, and revocation action. A scan by itself does not reduce risk unless the discovered secret can be linked to an accountable owner and moved into an offboarding or rotation workflow. Definitions vary across vendors on whether browser-stored credentials, local SDK caches, and temporary cloud auth artifacts are in scope, so policy should be explicit. The OWASP Non-Human Identity Top 10 frames this as part of broader secret management failure, not a standalone hygiene task. The most common misapplication is treating a one-time endpoint scan as a complete control, which occurs when organisations fail to repeat scans after developer tooling, credential issuance, or device refresh cycles change.
Examples and Use Cases
Implementing endpoint secret discovery rigorously often introduces noise and device-management overhead, requiring organisations to weigh faster exposure detection against user disruption and alert triage cost.
- A developer stores a cloud access token in a text editor backup on a laptop; the scan flags the file before the token is reused elsewhere. This pattern is often discussed in the Guide to the Secret Sprawl Challenge.
- A CI engineer copies a private certificate to a workstation for local testing; the endpoint scanner finds the file even though the repository is clean. That matters because the secret can still be harvested from a non-repository location, as highlighted in the CI/CD pipeline exploitation case study.
- A browser profile retains cached cloud credentials after a role change; the discovery tool identifies the credential before access persists beyond its intended use. This aligns with OWASP Non-Human Identity Top 10 guidance on secret exposure.
- A contractor’s endpoint contains an API key in shell history, prompting revocation and reissue through the NHI Lifecycle Management Guide approach to ownership and cleanup.
In practice, the highest-value use case is not just finding the secret, but confirming whether it is still valid, who owns it, and whether a replacement must be issued immediately.
Why It Matters in NHI Security
Endpoint secret discovery matters because endpoint storage is where secret sprawl becomes visible after preventive controls fail. NHIMG reports that 96% of organisations store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools, and 79% have experienced secrets leaks, with 77% of those incidents causing tangible damage. Those numbers show why endpoint coverage is not optional when non-human identities are used across developer tooling, automation scripts, and local test environments.
For governance teams, discovery is the trigger point for revocation, rotation, and incident scoping. Without it, exposed tokens can linger on unmanaged devices long after the original job or workflow ends. The Top 10 NHI Issues and the Ultimate Guide to NHIs — Key Challenges and Risks both frame poor visibility as a root cause of broad NHI exposure. Organisations typically encounter the full impact only after a compromised workstation is used for lateral movement or cloud abuse, at which point endpoint secret discovery becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret exposure and discovery failures across non-human identities. |
| NIST CSF 2.0 | DE.CM-8 | Relates to monitoring for anomalies and security events across endpoints. |
| NIST SP 800-63 | IAL/AAL null | Applies indirectly through credential assurance and lifecycle handling. |
| NIST Zero Trust (SP 800-207) | ID, PR.AC | Zero Trust depends on reducing trust in unmanaged or exposed credentials. |
| NIST AI RMF | Applies where AI agents store tokens or local credentials on endpoints. |
Scan endpoints for exposed secrets and route findings into rotation and revocation workflows.
Related resources from NHI Mgmt Group
- What is the difference between secret scanning and non-human identity discovery?
- Should organisations prioritise secret rotation or secret discovery first?
- Should organisations prioritize secret discovery before secret rotation?
- How should organisations govern SaaS discovery across finance, identity, and endpoint data?
