Who is accountable when unnecessary access remains in place?

Why This Matters for Security Teams

Unnecessary access is rarely a single-control failure. It usually means the approval, provisioning, and revocation chain drifted apart, so access that was justified once remained active long after the business need changed. That creates audit exposure, incident blast radius, and ambiguity about who must act when a review finds stale permissions. The governance problem is especially visible in non-human identities, where access can persist across services, pipelines, and automations without a human noticing.

The accountability question matters because “owned by everyone” often becomes owned by no one. Guidance in the OWASP Non-Human Identity Top 10 points to lifecycle and privilege weaknesses as a recurring source of exposure, and NHIMG research on the Ultimate Guide to NHIs shows how identity sprawl and weak ownership make that exposure harder to contain. In practice, many security teams encounter unnecessary access only after an audit finding, incident review, or access recertification has already exposed the gap.

How It Works in Practice

Accountability should follow the control failure, not just the person who approved the original request. In most mature environments, managers or application owners are accountable for the business justification, IAM or IGA teams are accountable for the mechanics of provisioning and revocation, and control owners are accountable for proving that removal actually happened. For NHI and agentic systems, the same logic applies, but the evidence must extend to tokens, service accounts, API keys, and delegated tool access.

Operationally, that means teams need a closed loop: request, approval, issuance, expiry, review, and revocation evidence. The review is incomplete unless it confirms that access was removed from the live system, not merely marked for removal in a ticket. Current guidance from OWASP and NHIMG’s breach analysis in 52 NHI Breaches Analysis both reinforce the same lesson: stale access becomes exploitable when ownership is unclear and revocation is not verified.

• Managers and app owners define why access is needed and when it should end.
• IAM and IGA teams implement automated expiry, approval routing, and revocation workflows.
• Control owners validate evidence that access was removed from every target system.
• Security and audit teams test whether exceptions, break-glass access, and inherited permissions are tracked separately.

For NHIs, the practical test is whether a secret, token, or role can still be used after the review says it should not exist. These controls tend to break down in highly distributed environments where access is inherited across cloud accounts, service meshes, CI/CD pipelines, and manually managed exceptions because revocation evidence becomes fragmented.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, requiring organisations to balance fast delivery against stronger proof of removal. That tradeoff is real in environments with frequent team changes, ephemeral workloads, or many machine identities, where stale access can appear faster than manual review cycles can clear it.

There is no universal standard for assigning accountability in every edge case, but current guidance suggests separating decision authority from control verification. For example, an application owner may approve access for a vendor integration, while the IAM team automates expiry and the control owner confirms deletion from the target system. If a review finds access still present, the owner of the business need is not necessarily the same party responsible for the broken workflow.

This becomes especially important when secrets, tokens, and delegated access are shared across systems. NHIMG’s The State of Secrets in AppSec highlights how fragmented secrets management undermines central control, which is why stale access should be treated as a lifecycle failure, not just a missed ticket. In regulated environments, accountability ultimately remains with the organisation, even when technical ownership is split across teams and tools.

Related resources from NHI Mgmt Group

• Who remains accountable when a managed cloud security provider misses an incident?
• Who is accountable when multi-cloud access reviews miss excessive permissions?
• How should security teams run access reviews for non-human identities?
• How should security teams govern non-human identities that have persistent access?