Developer identity governance needs ZSP, lifecycle control, and discovery

At a glance

What this is: This is a developer identity governance analysis arguing that developers need frictionless access, but only with continuous discovery, protected credentials, zero standing privilege, and lifecycle controls.

Why it matters: It matters because developer access often bridges human identity, NHI, and machine-to-machine workflows, so IAM teams need controls that reduce risk without breaking delivery.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Delinea's analysis of developer identity governance and zero standing privilege

Context

Developer identity governance sits at the intersection of human IAM and non-human identity security. Developers often hold elevated permissions, work across production and non-production systems, and create or consume service accounts, tokens, keys, and certificates as part of day-to-day delivery.

The core problem is that many identity programmes still treat developer access as either a productivity issue or a privileged-user problem. In practice, it is both. That creates a governance gap when access is shared, standing privilege persists, or machine identities are created faster than security teams can classify and govern them.

Key questions

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. Use discovery to find all related accounts and secrets, then apply task-scoped elevation, context-aware checks, and lifecycle reviews so access stays linked to work rather than lingering as standing privilege.

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. That expands the attack surface because a single compromise can expose both human and non-human identity controls, especially where shared credentials or persistent elevation still exist.

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. In practice, this turns developer convenience into long-lived exposure, especially when repositories, cloud environments, and internal tools all store credentials in different places.

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.

Technical breakdown

Why developer identities create a broader identity attack surface

Developer identities are human identities with unusually broad technical reach. They often touch source code, cloud consoles, CI/CD systems, production data, and third-party repositories, while also creating or managing machine identities for applications and automation. That combination makes them harder to govern than standard workforce accounts because the same person can exercise human authentication, privileged access, and NHI-adjacent stewardship in one workflow. The real technical challenge is not just privilege level, but identity sprawl across systems, environments, and repositories.

Practical implication: classify developer access by system, privilege, and credential type before you try to standardise controls.

Zero standing privilege and context-aware access for developers

Zero standing privilege removes persistent elevation and replaces it with task-scoped access. For developers, this matters because their work changes frequently and static role models quickly become stale. Context-aware authorisation adds another layer by checking signals such as system sensitivity, behaviour, and risk before granting elevation. This is stronger than fixed RBAC in dynamic environments because it reduces the window in which privileged access exists. The architecture works best when elevation is temporary, logged, and tied to a clear task rather than a broad project role.

Practical implication: route developer elevation through JIT controls and require context before any privileged action is allowed.

Discovery, vaulting, and lifecycle governance across developer credentials

Continuous discovery is the control that keeps developer identity inventory current as new accounts, secrets, and permissions appear. Vaulting and rotation reduce the damage from static or shared credentials, especially where developers handle SSH keys, tokens, and certificates. Lifecycle governance closes the loop by managing joiner, mover, and leaver events, plus access reviews, so privileged access does not outlive the project or the person. Without those controls, identity drift becomes routine and orphaned access becomes the default failure mode.

Practical implication: connect discovery, vaulting, and JML processes so developer credentials are inventoried, rotated, and removed on a governed cycle.

Threat narrative

Attacker objective: The attacker wants to turn developer trust and elevated access into control of code, infrastructure, or sensitive production data.

1. Entry occurs through exposed developer credentials, shared privileged accounts, or forgotten repository secrets that give attackers a trusted foothold into code and cloud systems.
2. Escalation follows when standing privilege, weak approval gates, or broad project roles let the attacker reach production systems, secrets stores, or deployment pipelines.
3. Impact is achieved through lateral movement into sensitive data, malicious code changes, or downstream compromise of machine identities and application workloads.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Zero standing privilege is the right control pattern, but only when it is paired with identity discovery. Standing privilege is what makes developer compromise so damaging, because persistent elevation broadens blast radius and hides in plain sight. Yet ZSP does not work if the organisation cannot see all the accounts, keys, and entitlements developers are using. The governance lesson is that temporary elevation without complete discovery only shortens the list of things security cannot see.

Developer workflows expose the same secret and lifecycle weaknesses that drive NHI incidents. Developers frequently create, reuse, or inherit tokens, keys, and certificates, which means the line between human identity governance and NHI governance is thin in practice. If lifecycle processes do not remove obsolete access, the organisation accumulates orphaned credentials and stale permissions. That is the same failure pattern seen in many machine-identity incidents, so practitioners should align developer governance with NHI lifecycle discipline.

Dynamic authorisation is replacing static role logic for high-change engineering teams. Developers move between projects, environments, and approval contexts too quickly for fixed RBAC to remain reliable on its own. Access decisions need to reflect current task, system sensitivity, and risk posture, not last quarter's role assignment. The implication for identity teams is clear: if developer access is still being managed as a static entitlement problem, the programme is already behind the work pattern.

Identity lifecycle control is the hidden control plane for developer risk. Joiner, mover, leaver handling, access reviews, and deprovisioning are often viewed as administrative tasks, but for developers they determine whether privileged access remains linked to an active task or becomes dormant exposure. That makes lifecycle governance a security mechanism, not an HR process. Practitioners should elevate developer lifecycle controls to the same operational level as secrets management and privileged access monitoring.

From our research:

• 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.
• That pattern sits alongside the 52 NHI breaches Report, which helps teams trace how exposed credentials and unmanaged identities turn into breach pathways.

What this signals

Credential hygiene will keep failing as a governance problem until developer lifecycle controls are treated as a production control plane. If teams still rely on periodic reviews alone, they will keep finding expired access after the damage window has already opened. The practical shift is to connect access reviews, deprovisioning, and secret rotation into one operating model so developers do not carry old privilege into new work.

The next maturity step is not more security friction. It is better identity orchestration: continuous discovery, task-scoped elevation, and tighter linkage between repository access, cloud privilege, and machine-identity ownership. That combination is what lets IAM teams preserve developer speed without accepting invisible privilege growth.

Secret sprawl is a leading indicator of governance drift. The moment a programme accumulates multiple vaults, ad hoc keys, or informal repository credentials, it is signalling that control ownership has fragmented. For teams building future-state identity governance, that is the point to tighten lifecycle control and align it with the standards in the OWASP Non-Human Identity Top 10.

For practitioners

• 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. Use continuous discovery across source control, cloud, and production systems, and tie each credential to a named developer or service owner.
• 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. Pair JIT access with logging so security teams can confirm the privilege was used for the stated purpose.
• 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. Treat stale credentials as an active exposure path, not an administrative cleanup item.
• Embed developer accounts in lifecycle governance Include developers in joiner, mover, and leaver processes, access reviews, and recertification cycles so privileged access is removed when roles change. Align those reviews with production access, third-party collaboration, and machine identity creation privileges.

Key takeaways

• Developer identity risk comes from breadth of access, not just privilege level.
• Persistent elevation and scattered secrets create the breach conditions that identity teams are trying to eliminate.
• Discovery, JIT access, vaulting, and lifecycle governance need to operate as one control model for developers.

Key terms

• Developer Identity: A developer identity is the human account used by software engineers to access code, infrastructure, cloud systems, and production-adjacent tools. In practice, it often carries broader privileges than a normal workforce account and may also create or manage machine identities, which increases governance complexity.
• Zero Standing Privilege: Zero standing privilege means no persistent elevated access exists by default. The user or operator receives higher privilege only when a task requires it, for a limited duration, with approval and logging. For developers, it reduces the time privileged access is exposed and limits the blast radius of compromise.
• Identity Discovery: Identity discovery is the continuous process of finding, classifying, and tracking accounts, secrets, permissions, and related assets across environments. It matters for developer governance because new credentials appear quickly in repositories, cloud services, and automation workflows, and unseen identities become unmanaged risk.
• Lifecycle Governance: Lifecycle governance is the discipline of managing identities from creation through change and removal. For developers, it covers joiner, mover, and leaver events, access reviews, and deprovisioning, ensuring access matches current work and does not persist after a project, role change, or departure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Delinea: Securing developer identities: A frictionless experience. Read the original.