Who is accountable when self-service access requests create excess privilege?

Accountability sits with the governance process owner, the application owner, and the access approver together, because self-service only works when policy checks, approval rules, and audit logs are aligned. If the workflow permits excess privilege, the issue is not user demand alone but weak control design and ownership.

Why This Matters for Security Teams

Self-service access feels efficient, but it becomes a governance problem the moment the workflow can grant more than the requester should receive. In NHI environments, that risk is amplified because access often persists beyond the task, the approver may not understand the technical blast radius, and the policy engine may be too coarse to distinguish intent from entitlement. NHI Mgmt Group notes that Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which is why excess access is usually a design failure, not a user exception.

This is also where traditional request-approve-provision models break down. A human requester may know what they want, but the control owner must decide what is safe to grant, for how long, and under what conditions. Current guidance from the OWASP Non-Human Identity Top 10 emphasizes that over-permissioned identities and weak lifecycle controls are core exposure points, especially when approvals are treated as administrative formality rather than policy enforcement.

In practice, many security teams discover excess privilege only after a workflow has already been used at scale, rather than through intentional design reviews.

How It Works in Practice

Accountability is shared, but not blurred. The governance process owner is accountable for the policy model, the application owner is accountable for defining the minimum access required, and the approver is accountable for validating the specific request against that policy. If the system allows users to self-select broad roles, then the request flow is effectively granting standing privilege unless it is constrained by runtime checks, time limits, and explicit business context.

For access requests that touch NHIs, best practice is to combine request-time evaluation with short-lived entitlement delivery. That means using policy-as-code, approval routing, and just-in-time grants so the request is validated against context, not just a dropdown menu. The 52 NHI Breaches Analysis is useful here because it shows how credential misuse and excess access often move together once a control gap exists. Where available, the approval system should also log who requested, who approved, what policy was applied, and when revocation occurred.

• Use least-privilege templates instead of open-ended role selection.
• Require business justification and object-level scope for each request.
• Make approvals time-bound and automatically revoked when the task ends.
• Review audit logs for policy overrides, not just successful approvals.

For identity governance, the operational question is not whether a user clicked self-service, but whether the workflow enforced a safe boundary at the moment access was granted. The best control designs align with OWASP Non-Human Identity Top 10 and related identity governance practices, which treat over-privilege as a lifecycle failure. These controls tend to break down when request systems are wired directly to broad entitlement groups because group membership bypasses granular policy evaluation.

Common Variations and Edge Cases

Tighter approval workflows often increase operational overhead, so organisations have to balance speed against assurance. That tradeoff becomes visible in environments where developers, automation jobs, and support teams all need rapid access to production systems. In those cases, current guidance suggests using narrower request paths for different identity types instead of a single self-service model that serves everyone equally.

One common edge case is emergency access. Break-glass procedures can be legitimate, but they should be isolated from ordinary self-service and reviewed separately because they intentionally relax normal controls. Another is delegated approval, where managers or product owners can approve access they do not fully understand. That may be acceptable for low-risk systems, but it is weak for secrets, service accounts, and CI/CD access where privilege is difficult to see after the fact.

In mature programs, the accountable parties should also include the audit owner and the platform team if the workflow is technically incapable of enforcing policy. If the request path can only grant coarse bundles, then the resulting excess privilege is a platform design issue as much as a process issue. For that reason, many organisations map this problem to the OWASP Non-Human Identity Top 10 and the governance patterns documented in Ultimate Guide to NHIs.

Related resources from NHI Mgmt Group

• Who is accountable when automated access changes fail an audit or create privilege drift?
• Who should be accountable when ePHI is exposed through excess access?
• Who is accountable when access controls create unsafe clinical workarounds?
• Who is accountable when hospital access controls create unsafe workarounds?