TL;DR: GitGuardian says developer workstations are filling with plaintext credentials that EDR, vaults, and repository scanning do not inventory, so organisations often need days or weeks of forensics to reconstruct what an attacker could harvest. The gap is control coverage, not detection speed: security teams need per-machine credential inventory to make workstation exposure governable.
At a glance
What this is: This brief argues that developer laptops now hold a credential layer that existing controls do not inventory, leaving exposure to be reconstructed after compromise.
Why it matters: For IAM, PAM, and NHI teams, this matters because workstation-held secrets can bypass traditional inventory, rotation, and audit processes even when other controls are in place.
👉 Read GitGuardian's brief on developer workstation credential inventory and hidden exposure
Context
Developer workstations are now part of the credential estate, not just endpoints to be defended. In this case, the governance gap is simple: organisations can see repositories, vaults, and alerts, but not the full set of credentials stored locally on developer laptops.
That creates a control gap for NHI governance and secrets management. If a machine can contain plaintext keys, tokens, or other secrets outside source control, then the organisation has no reliable inventory to prove exposure, revocation scope, or audit coverage after compromise.
Key questions
Q: What breaks when developer workstation secrets are not inventoried?
A: Without a workstation-level inventory, security teams cannot quickly prove which credentials were present on a compromised laptop, which ones were still active, or how far the exposure spread. That leaves responders reconstructing the problem from artefacts after the fact, instead of containing it from an authoritative device record.
Q: Why do plaintext credentials on developer laptops increase incident scope?
A: Because local secrets often sit outside central vaults and repository scans, an attacker who compromises the device can harvest credentials that remain usable across downstream systems. The organisation then has to determine which secrets existed and where they were accepted. That uncertainty expands the response problem beyond the endpoint itself.
Q: How do security teams know whether workstation controls are actually working?
A: They should look for fewer credential-sharing workarounds, consistent session lock and resume behaviour, complete access logs, and policy enforcement that changes based on device trust and location. If users are bypassing controls to stay productive, the programme is not working as designed.
Q: Should organisations treat developer workstation secrets as part of secrets management?
A: Yes. If a secret exists on a developer machine, it is part of the credential estate and must be governed alongside vaulted secrets, repository secrets, and rotation processes. The distinction matters because unmanaged local copies can outlive the controls that protect centrally stored credentials.
How it works in practice
Why workstation-held secrets evade existing control layers
Endpoint detection and response is built to detect suspicious behaviour, not to enumerate every secret present on a device. Vaults govern centrally managed credentials, and repository scanning covers committed code, but neither sees the credentials that developers cache locally in files, build artefacts, or assistant-generated outputs. The result is a visibility gap between policy and reality: the secret exists, but no control owns its inventory on the workstation. That is why post-incident forensics often become the first time the organisation learns what was there.
Practical implication: inventory the credential layer on developer machines directly instead of assuming EDR, vaults, or code scanning already cover it.
How infostealers turn local credential sprawl into incident scope
Infostealer malware is effective here because it does not need to defeat the whole environment, only the local artefacts a developer machine accumulates. If plaintext credentials or cached session material sit outside centrally governed stores, malware can collect them before any downstream control sees the exposure. That changes the incident from a single-compromise event into an uncertainty problem: teams must determine which secrets existed, which were still valid, and which systems they could reach. In practice, the attack surface is the workstation plus everything authenticated from it.
Practical implication: treat local developer credentials as a distinct exposure domain when defining incident response and revocation scope.
What a per-machine credential inventory changes for governance
A per-machine credential inventory turns workstation exposure into something auditable. Instead of asking only whether an alert fired, security teams can ask what credentials were present, which machines held them, and whether coverage is complete across the fleet. That matters for governance because auditors need evidence, not inference, and executives need measurable exposure, not a forensic estimate. The model also exposes control ownership: the inventory cannot live only in endpoint tooling, because the issue spans identity, device management, and secrets governance at once.
Practical implication: define workstation credential coverage metrics alongside rotation and offboarding metrics so exposure can be reported upward.
NHI Mgmt Group analysis
Developer workstation secrets create an inventory blind spot, not just an endpoint risk. The control failure here is structural: organisations have tools for detection, storage, and source-code scanning, but no authoritative record of the secrets that live only on developer machines. That means the security programme can neither prove exposure nor prove cleanup after compromise. The practitioner conclusion is that credential inventory must extend to endpoints where developers actually work.
Secret discovery without workstation coverage is not governance. A vault can protect managed secrets, and repository scanning can find committed secrets, but neither resolves the unmanaged copy problem on a laptop. The hidden risk is that the same secret may exist in local caches, build outputs, or assistant artefacts while remaining invisible to central controls. The practitioner conclusion is that secrets governance must account for where credentials are created, copied, and retained.
Per-machine credential inventory is the missing control plane for workstation-held secrets. The naming matters because it shifts the problem from “can we detect bad behaviour?” to “can we account for the secret estate on each device?” That is what makes upward reporting possible: exposure, ownership, and control coverage become measurable instead of forensic guesses. The practitioner conclusion is that endpoint, identity, and secrets teams need a shared inventory model.
Hidden credential exposure on developer laptops collapses the assumption that the secure boundary is the repository. Many NHI and secrets programmes assume that if code is protected, the credentials are governed. That assumption fails when credentials exist only on local workstations because the secret’s lifecycle now includes endpoints outside the normal inventory chain. The practitioner conclusion is that lifecycle governance must follow the credential beyond the vault and repository.
Workstation credential risk is now a board-level reporting issue because forensic reconstruction is too slow. When the organisation can only answer exposure questions after days or weeks of analysis, it cannot reliably demonstrate containment, ownership, or audit readiness. That makes the absence of device-level inventory a governance defect, not merely a tooling gap. The practitioner conclusion is that control coverage must be reportable in fleet terms, not anecdotal terms.
From our research library:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
- Read next: Secrets Management Buyer's Guide
What this signals
Developer workstation exposure is becoming the missing layer in NHI governance. Organisations that only govern repositories and vaults are leaving a blind spot where developers actually create and use credentials. The practical shift is toward device-level discovery, because secrets that never reach source control still belong in the governed estate.
Per-machine credential inventory is the control that makes workstation exposure auditable. It gives security teams a way to count coverage, trace ownership, and support revocation decisions when a laptop is compromised. Without that layer, auditors get a story instead of evidence.
For practitioners
- Build a developer workstation credential inventory Map credentials, tokens, and cached secrets on developer laptops as a separate inventory layer from repositories and vaults.
- Correlate endpoint telemetry with identity scope Tie device-level findings to the identities and systems those credentials can reach so revocation decisions are based on actual exposure.
- Separate local secret artefacts from managed secrets Classify files, build artefacts, assistant outputs, and cached tokens as local secret artefacts that require their own handling rules.
- Report fleet-wide coverage to leadership Track what percentage of the developer fleet is covered by workstation credential discovery, and use that metric in audit and risk reporting.
Key takeaways
- Developer workstation secrets create a governance gap because existing controls do not inventory the credentials stored locally on laptops.
- The problem is not hypothetical: once a device is compromised, teams often need days or weeks to reconstruct what was exposed and where it was usable.
- Per-machine credential inventory is the control change that turns workstation-held secrets into a measurable part of the identity and secrets programme.
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 NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Local workstation secrets are exposed outside managed repositories and vaults. |
| NHI-07 — Long-Lived Secrets | The article focuses on secrets that persist on laptops long enough to survive ordinary controls. | |
| Recommendation — Inventory and remove secrets that appear on developer endpoints before they become harvestable. Shorten the lifespan of endpoint-held secrets and verify where they persist outside vaults. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Workstation-held credentials need lifecycle control, not just detection after exposure. |
| Recommendation — Apply IA-5 to govern issuance, storage, rotation, and revocation of endpoint-authenticating credentials. | ||
| MITRE ATT&CK | TA0006 — Credential Access | The threat pattern centers on harvesting credentials from compromised developer devices. |
| Recommendation — Map developer-workstation harvesting to TA0006 and prioritise detections for credential collection activity. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The control gap is inability to account for what credentials authorize on the workstation. |
| Recommendation — Use PR.AA-05 to ensure workstation-held credentials are inventoried and authorised within access governance. | ||
Key terms
- Developer Workstation Credential Inventory: An authoritative record of the credentials that exist on developer laptops and workstations, including plaintext secrets, cached tokens, and local artefacts. It extends governance beyond repositories and vaults so teams can prove what was present, what was exposed, and what must be revoked after compromise.
- Local Secret Artefact: Any secret material that lives on an endpoint outside a central vault or source-control system, such as cached tokens, configuration files, build outputs, or assistant-generated files. These artefacts matter because they can be harvested even when the organisation believes the secret is centrally managed.
- Credential Coverage: Credential coverage is the share of user-facing applications and accounts that are managed through a sanctioned control such as a password manager or federated login. High coverage means fewer hidden credentials, stronger auditability, and cleaner revocation during offboarding or access review cycles.
- Developer Workstation Secret Sprawl: The uncontrolled spread of credentials across a developer laptop, including files, caches, shell state, and tooling artifacts. It matters because these copies often outlive the intended use of the secret and create multiple recovery points for attackers after a single endpoint compromise.
What's in the full announcement
GitGuardian's full brief covers the operational detail this post intentionally leaves for the source:
- Early access findings from developer laptop scans showing what types of credentials are appearing outside source control
- The four reporting metrics used to describe fleet exposure and auditor-testable control coverage
- The 95-day window and why it matters when teams reconstruct exposure after an incident
- How the endpoint credentials audit fits into existing device-management workflows
Deepen your knowledge
NHI governance, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on September 14, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org