An endpoint-held secret is any credential stored or used on a user or developer device instead of being centrally managed. These secrets often bypass repository scanning and vault controls, which means inventory and revocation must extend to the workstation itself to prevent invisible reuse.
Expanded Definition
An endpoint-held secret is a credential that lives on a user or developer device, rather than in a central secrets manager or another controlled service. The boundary matters: once a secret is stored locally, its security depends on the endpoint’s hardening, user behaviour, and local persistence controls, not just on the vault that originally issued it.
This term usually covers API keys, tokens, certificates, and other reusable credentials that are copied into shells, editors, sync folders, build tools, or local config. It excludes centrally managed secrets that are fetched just in time and never persist on the device. In practice, endpoint-held secrets often evade repository scanning because the risk is on the workstation itself, not only in source code. That is why visibility, offboarding, and revocation need to extend beyond the vault into the endpoint estate. For a broader control perspective, the OWASP Non-Human Identity Top 10 is useful when the same secret also functions as a machine credential.
A common misunderstanding is to treat “not in git” as “under control”. Endpoint-held secrets can still be cached in browser profiles, local dotfiles, developer tools, clipboard history, or sync clients, which makes them hard to inventory and easy to reuse silently.
Examples and Use Cases
Endpoint-held secrets show up wherever development or operations work depends on local access paths. They are often introduced for speed, then left behind long after the original task is finished.
- A developer saves a cloud access token in a shell profile so automation keeps working across restarts.
- An analyst pastes an API key into a local notebook or IDE extension to test a data integration.
- A certificate or private key is copied to a laptop for signing, troubleshooting, or short-lived admin work.
- A contractor stores a long-lived credential in a password file on a managed workstation and later reuses it in a different context.
- A build helper or local script keeps a secret in a config file because central retrieval would slow down a release step.
These patterns can be convenient, but they create a tradeoff between operational speed and control. The more endpoints can hold reusable credentials, the harder it becomes to prove where the secret exists and whether it has been copied elsewhere.
NHIMG’s Guide to the Secret Sprawl Challenge and Ultimate Guide to NHIs, Static vs Dynamic Secrets both help frame why local persistence is so hard to govern.
Security Implications
The main security problem is visibility loss. Once a secret reaches an endpoint, it can escape central lifecycle controls, persist after the workflow ends, and remain valid long after the owner has moved on. That creates blind spots in inventory, rotation, and revocation, especially in developer-heavy environments where local tooling is constantly changing.
Mismanaged endpoint-held secrets enlarge blast radius because compromise of one workstation can expose multiple services, environments, or accounts. They also weaken offboarding: if a user leaves or a device is lost, every secret present on that endpoint may need review. NHIMG data shows how serious that gap can be, including the observation that 91.6% of secrets remain valid five days after notification, which points to a slow-remediation problem rather than a discovery problem.
Failure mechanism: the secret is copied locally, reused across tools, and never fully recorded in the systems that own central inventory or rotation. Security teams then miss the endpoint copy, so revocation happens too late or not at all.
Impact: attackers or former insiders can reuse the secret for persistence, lateral access, or unauthorized API activity even after the original use case has ended.
Security, Operational and Governance Implications
Endpoint-held secrets matter because they turn endpoint hygiene into credential governance. A laptop or workstation is no longer just a device risk, it becomes a storage location for credentials whose ownership, rotation, and retirement must be tracked like any other sensitive asset. That changes how teams think about offboarding, developer tooling, and endpoint monitoring.
Operationally, the key issue is not only theft. It is also unmanaged reuse, where the same secret keeps working in places nobody remembers to check. That is why revocation procedures need to account for local copies, cached secrets, and hidden persistence paths, not just the source system that originally issued the credential. For teams managing many local tools and scripts, the practical challenge is proving that a secret has truly disappeared from the endpoint after a change, incident, or employee departure.
52 NHI Breaches Analysis and the Reviewdog GitHub Action supply chain attack are useful references for understanding how exposed secrets become real compromise paths.
Endpoint-held secrets are therefore a governance problem as much as a technical one: if ownership is unclear, revocation will always lag reuse.
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 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secrets and Credential Management | Endpoint-held secrets are locally stored credentials with unclear lifecycle control. |
| NHI-03 — Visibility and Discovery | Local secret copies evade central scanning and require endpoint-level discovery. | |
| Recommendation — Inventory endpoint-held secrets and enforce rotation and revocation from the credential source. Extend discovery to endpoints, configs, shells, and developer tooling. | ||
| CIS Controls v8 | 6 — Access Control Management | Endpoint-held secrets create unmanaged access paths that must be removed on offboarding. |
| 8 — Audit Log Management | Endpoint-held secrets are often detected through host and tool telemetry. | |
| Recommendation — Remove stale local credential paths promptly during user and device offboarding. Log endpoint secret access and review unusual credential use patterns. | ||
| MITRE ATT&CK | T1552.001 — Unsecured Credentials: Credentials In Files | Many endpoint-held secrets persist in local files and configs. |
| T1078 — Valid Accounts | A valid endpoint-held secret can become reusable account access after compromise. | |
| Recommendation — Hunt for credentials in local files and monitor for suspicious secret harvesting. Treat exposed endpoint secrets as valid-account exposure and revoke them fast. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 14, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
