Who should own the cleanup of excessive permissions?

Ownership should sit with the business and identity governance function together, because access decisions require both operational context and control enforcement. IT can execute revocation, but managers, application owners, and security teams must define what is still justified. Without clear ownership, excess access simply survives the next review cycle.

Why This Matters for Security Teams

Excessive permissions are not a cosmetic hygiene issue. They are one of the fastest ways that routine access sprawl turns into real blast radius when a service account, API key, or operator role is compromised. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks notes that 97% of NHIs carry excessive privileges, which helps explain why cleanup ownership matters as much as the cleanup itself. Security teams often find that no one feels accountable once the review starts, especially when access was inherited across cloud, CI/CD, and application ownership lines.

That ambiguity creates a governance gap: IT can remove access, but only the business and application owners can say whether the access is still justified. The OWASP Non-Human Identity Top 10 treats over-privilege as a core risk because compromised NHI access is usually abused through what was already allowed, not by bypassing controls entirely. In practice, many security teams encounter excessive permissions only after an audit, incident, or failed access review has already exposed the gap.

How It Works in Practice

The practical ownership model is shared, but not diffuse. Business owners and application owners should decide what access is still needed, identity governance should enforce the policy and track exceptions, and IT or platform teams should execute revocation through the relevant directory, cloud, or secrets system. This separation matters because access decisions require operational context, while remediation needs control discipline.

A workable cleanup process usually includes three steps:

• Identify the identity, resource, and permission set that is out of scope for current work.
• Validate the business justification with the manager or system owner, not only with the technical admin.
• Remove the privilege, then confirm that dependent jobs, integrations, and break-glass paths still function.

For NHIs, this gets harder because permissions may be embedded in CI/CD pipelines, workload tokens, or static secrets. Current guidance suggests pairing access review with lifecycle management, because a permission that is technically removable but operationally undocumented will keep reappearing. NHIMG’s guide shows how widely NHI risk is distributed, while the OWASP NHI guidance reinforces that entitlement review must include non-human accounts, not just employee roles. In environments using zero trust or policy-based access, the control point should be the policy engine, but the ownership question still belongs to the business and governance function. These controls tend to break down when access is spread across many application teams and no single owner can attest to what is still required.

Common Variations and Edge Cases

Tighter ownership often increases review effort, requiring organisations to balance faster remediation against more complete justification. That tradeoff becomes visible in large SaaS estates, shared service accounts, and platform teams where one permission set may support multiple workloads.

There is no universal standard for this yet, but best practice is evolving toward named accountability at both the business and technical level. For example, a manager may own human access decisions, while an application owner owns NHI entitlements and a governance team enforces deadlines, evidence, and escalation. In highly regulated environments, that split should be documented in access review workflow, because “someone in IT” is not a durable control owner.

Edge cases also matter. Emergency access, third-party integrations, and dormant break-glass accounts need explicit exception handling so cleanup does not break critical operations. NHIMG’s broader NHI guidance and the OWASP NHI Top 10 both point to the same operational lesson: if revocation can only happen when everyone agrees informally, excessive permissions will survive by default, not by design.

Related resources from NHI Mgmt Group

• Who should own OAuth app and service account cleanup?
• Who should own redundant app cleanup and offboarding?
• Why do excessive permissions keep showing up in IAM programmes?
• When do NHI access reviews create more value than a one-time cleanup?