Notifications
Clear all
Topic starter
25/06/2026 1:17 am
TL;DR: Developer identities are high-value targets because they blend elevated privileges, production access, remote work, third-party collaboration, and frequent interaction with machine identities, according to Delinea. The governance issue is not productivity versus security, but whether identity programmes can remove standing access, discover shadow accounts, and keep developer access tied to unique identities instead of shared credentials.
NHIMG editorial — based on content published by Delinea: Securing developer identities: A frictionless experience
Questions worth separating out
Q: How should security teams govern developer identities without slowing delivery?
A: Start by separating developer identity into its own governance path, because developers combine human access, privileged access, and machine identity stewardship.
Q: Why do developers create higher identity risk than typical workforce users?
A: Developers often have access to production systems, cloud platforms, source code, and third-party repositories, and they may also create service accounts and secrets.
Q: What breaks when developer secrets are not centrally discovered and rotated?
A: Unmanaged secrets create orphaned access, hidden dependencies, and stale permissions that attackers can reuse long after the original task ends.
Practitioner guidance
- Map developer access by credential type and environment Build an inventory that separates human accounts, service accounts, API keys, tokens, certificates, and repository credentials so you can see where developers cross into machine identity ownership.
- Replace standing elevation with task-scoped approval Grant elevated access only for the duration of a specific debugging, deployment, or maintenance task, and require the request to name the target system and reason.
- Rotate and retire shared developer secrets quickly Eliminate shared privileged accounts where possible, then rotate SSH keys, tokens, and certificates whenever a developer changes teams, leaves a project, or stops using a repository.
What's in the full article
Delinea's full blog covers the operational detail this post intentionally leaves for the source:
- How Delinea maps developer access across human identities, machine identities, and privileged workflows in one platform view
- The specific controls used to support context-aware MFA, JIT elevation, and zero standing privilege for developers
- Examples of how the platform handles credential vaulting for SSH keys, tokens, and certificates used in development workflows
- How the blog frames continuous discovery and lifecycle governance for developers working across production and third-party systems
👉 Read Delinea's analysis of developer identity governance and zero standing privilege →
Developer identities and standing privilege: are your controls enough?
Explore further
25/06/2026 10:36 am
Developer identity is a governance boundary, not just a user population. Developers are routinely treated as a single privileged workforce segment, but that hides the fact that they operate across production systems, create machine identities, and handle credentials with different trust characteristics. The result is a programme design problem: one identity class is being forced through controls built for ordinary employees. Practitioners should treat developer identity as a distinct governance domain with human, privileged, and machine-identity overlap.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, which means the control gap often begins with day-to-day developer behaviour rather than tooling alone.
A question worth separating out:
Q: Who is accountable when developer access outlives the project or role?
A: Accountability should sit with the system owner, the identity governance team, and the engineering manager together, because developer access often spans application, infrastructure, and repository controls. Lifecycle reviews, offboarding, and recertification must remove stale access before it becomes a hidden production risk.
👉 Read our full editorial: Developer identity governance needs ZSP, lifecycle control, and discovery
