Who is accountable when developer access outlives the project or role?

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.

Why This Matters for Security Teams

Developer access rarely stays neatly inside one system boundary. The same person may hold repository permissions, cloud console access, CI/CD rights, secrets vault access, and incident-response exceptions long after their project ends. That makes accountability a governance problem, not just a help desk task. When ownership is unclear, stale access becomes a shared blind spot and no one moves first.

Current guidance from the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs both point to lifecycle control as the real control point: if access is not owned, reviewed, and revoked on a schedule, it effectively becomes standing privilege. That matters because developer identities often inherit broad trust across production tooling, code paths, and deployment systems. In the current state of practice, accountability must be explicit across the system owner, identity governance, and engineering leadership, rather than assumed through job title alone.

NHIMG research shows why this keeps becoming a production issue: 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, and only 20% of organisations have formal processes for offboarding and revoking API keys. In practice, many security teams discover stale developer access only after a role change, contractor exit, or incident review has already exposed the gap.

How It Works in Practice

Accountability works best when it is assigned to the people who can actually remove access, not just approve it. The system owner should define which tools, repositories, and environments are in scope. The identity governance team should operate the review cadence, evidence collection, and revocation workflow. The engineering manager should confirm that project membership, onboarding, and offboarding reflect the current team structure. That split matters because developer access is usually distributed across multiple control planes.

In practical terms, teams should tie access to role, project, and time-bound need, then verify it continuously rather than only at hire or exit. A useful operating model includes:

• recertification of repository, cloud, and secret access on a fixed schedule
• automatic removal of access when project membership ends
• JIT elevation for production tasks instead of permanent admin rights
• separate approval paths for application ownership and infrastructure ownership
• evidence of revocation for tokens, keys, and group memberships

This is consistent with the lifecycle and visibility emphasis in NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and with identity governance principles in the OWASP Non-Human Identity Top 10. Where organisations make progress is usually not in a single tool, but in making ownership visible in tickets, offboarding checklists, and access review reports. These controls tend to break down when access is granted through ad hoc exceptions, because the exception path outlives the project that justified it.

Common Variations and Edge Cases

Tighter access governance often increases coordination overhead, so organisations have to balance speed against assurance. That tradeoff is most visible in fast-moving engineering teams, acquired companies, and contractor-heavy environments where project boundaries shift frequently. Current guidance suggests that the answer is not to delay access, but to make duration and accountability explicit from the start.

Edge cases usually appear when ownership is split across functions. A developer may leave the product team but still need emergency access to a legacy service, or a platform team may inherit dormant permissions after a reorganisation. In those cases, best practice is evolving toward context-aware approval and documented exception expiry, rather than indefinite access continuation. NHIMG’s findings that 71% of NHIs are not rotated within recommended time frames and 97% carry excessive privileges show why stale access often persists even when teams believe controls are in place.

For that reason, security leaders should treat unanswered ownership questions as a control failure. If no one can attest to who approves, reviews, and revokes a developer’s access after role change, the access should be treated as unresolved risk, not administrative noise.

Related resources from NHI Mgmt Group

• Who is accountable when access outlives the role that created it?
• Who is accountable for third-party access that outlives its intended use?
• Who is accountable when delegated access outlives the original business need?
• What is the difference between role-based access and API key governance for NHI security?