Why do developers create higher identity risk than typical workforce users?

Why This Matters for Security Teams

Developers create higher identity risk than typical workforce users because their day-to-day work intersects with the systems that attackers prize most: source code, production pipelines, cloud consoles, CI/CD, package registries, and secrets stores. That combination turns a single compromised developer account into a potential path to both human access and non-human identity abuse, especially when long-lived tokens, shared credentials, or excess elevation still exist. The issue is not developer intent, but exposure density and blast radius.

This is why NHI governance and developer security cannot be separated. NHIMG research shows that organisations maintain an average of 6 distinct secrets manager instances, which fragments control and weakens central oversight, while the State of Secrets in AppSec report also highlights that only 44% of developers follow security best practices for secrets management. That gap matters because developers routinely create, copy, rotate, and embed the very credentials that later become machine identities. Current guidance in NIST Cybersecurity Framework 2.0 still applies, but the risk profile is broader than ordinary workforce access. In practice, many security teams encounter developer-driven identity sprawl only after a leaked token, compromised pipeline, or cloud escalation has already widened the breach.

How It Works in Practice

Developer identity risk emerges from the way modern engineering work is done. A developer may authenticate interactively to a laptop, then use the same identity to reach cloud control planes, source repositories, build systems, and secrets managers. They may also provision service accounts for applications, generate API keys for testing, or approve automation that later runs with persistence. The security problem is the chaining of these privileges across human and non-human contexts.

Better practice starts by separating the developer as a human principal from the workloads they create and operate. That means strong MFA for interactive access, but also distinct workload identities for services and pipelines, ideally backed by short-lived credentials rather than shared static secrets. Where possible, secrets should be issued just in time, scoped to the task, and revoked automatically when the workflow ends. The best practice is evolving toward policy evaluated at request time, not just pre-assigned roles, because a developer may need elevated access in one context and none in another.

Useful implementation patterns include:

• Use least privilege for the human account and separate it from deployment or runtime identities.
• Issue ephemeral secrets or tokens for builds, deployments, and temporary troubleshooting.
• Keep developer access distinct from production write paths unless there is a documented approval path.
• Track every service account, token, and certificate created by engineering workflows as an owned NHI.

For deeper context on how these identities fail in real environments, see NHIMG’s Ultimate Guide to NHIs and the Top 10 NHI Issues. These controls tend to break down when developer convenience is prioritised over credential isolation because shared access paths and persistent tokens are difficult to distinguish during incident response.

Common Variations and Edge Cases

Tighter identity controls often increase delivery overhead, so organisations have to balance developer velocity against blast-radius reduction. That tradeoff is real, especially in fast-moving engineering teams where temporary access is needed for debugging, releases, or vendor integrations.

One common edge case is the “power developer” model, where senior engineers retain elevated access across multiple environments. That can be defensible for small teams, but current guidance suggests it should be time-bound, logged, and exception-based rather than permanent. Another edge case is platform engineering, where shared templates and automation generate many machine identities. The risk is not just the number of identities, but whether each one has a clear owner, purpose, and expiry.

Developer-created secrets also behave differently from workforce credentials because they are often copied into build logs, test scripts, personal notes, and local config files. NHIMG’s 52 NHI Breaches Analysis shows how frequently identity failures cascade once a secret is exposed. In parallel, the State of Secrets in AppSec report notes that remediation can take weeks, which is far too slow when tokens are already in circulation. The practical answer is not to block developers, but to make elevation ephemeral, ownership explicit, and secrets disposable.

Related resources from NHI Mgmt Group

• Why does supply-chain trust create so much identity risk?
• Why do public signing links create identity risk?
• Why do SAP credentials exposed in backend responses create broader identity risk?
• Why do SAP code injection flaws create such large identity risk?