Who is accountable when cloud access is over-granted and not removed?

Why This Matters for Security Teams

Over-granted cloud access is rarely a single mistake. It is usually a lifecycle failure where provisioning, exception handling, and deprovisioning are split across IAM, platform, and business ownership. When removal is not owned, access lingers long after the business need ends, and that is when entitlement sprawl turns into an incident path. NHI Management Group’s research on The 2026 Infrastructure Identity Survey found that 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which is a useful warning sign for broader cloud entitlement discipline.

The practical risk is not just excess privilege. It is the loss of clear accountability when teams assume someone else will remove access later. That gap is exactly where stale roles, dormant service accounts, and unreviewed exceptions accumulate. The OWASP Non-Human Identity Top 10 treats identity lifecycle control as a core control plane issue, not an admin task. In practice, many security teams discover the removal gap only after an audit, a breach review, or a terminated project still retaining production access.

How It Works in Practice

Accountability should be assigned at two levels: operational ownership and business ownership. IAM teams typically own the control process, tooling, and periodic reviews, while application owners and line managers own the legitimacy of the access itself. The key is that both approval and removal must be explicit. If a person, workload, or cloud role is provisioned for a project, the same record should define when it expires, who can extend it, and who must revoke it.

For cloud environments, mature practice usually includes joiner-mover-leaver workflows, time-bounded exceptions, and periodic recertification of privileged roles. Where workloads are involved, use workload identity rather than long-lived shared secrets so access can be scoped to the actual service and revoked cleanly. The broader pattern is consistent with The 2024 Non-Human Identity Security Report, which shows that non-human IAM maturity still trails human IAM in most organisations, and that dynamic ephemeral credentials are seen as valuable because they reduce the cleanup burden after a task ends.

• Define one named owner for provisioning and one named owner for deprovisioning, even if the same team performs both tasks.
• Make access expiration part of the request, not an afterthought attached to the review cycle.
• Track exceptions separately so temporary over-granting does not become permanent by default.
• Require removal confirmation for terminated staff, closed projects, and decommissioned cloud resources.
• Use policy checks and access reviews to detect roles that have no current business justification.

This guidance tends to break down in federated multi-cloud environments where entitlements are copied across accounts and no single team can see the full access path, because removal depends on multiple control planes and inconsistent ownership models.

Common Variations and Edge Cases

Tighter access removal often increases operational overhead, so organisations must balance rapid delivery against the cost of more frequent entitlement maintenance. That tradeoff is real, especially where teams rely on temporary escalations to keep production moving. Current guidance suggests that the answer is not to relax governance, but to make it lighter weight through time-bound approvals, automation, and clear exception expiry.

There is no universal standard for naming the accountable party in every cloud model. In some cases, the application owner is accountable for the entitlement decision, while IAM is accountable for enforcing the workflow and evidence trail. In others, platform teams own shared cloud roles because they control the infrastructure boundary. What matters is that accountability is written down, testable, and reviewable.

For cloud access that is over-granted and not removed, the hardest cases are cross-functional environments with shared admin roles, outsourced operations, or agentic systems that request new permissions at runtime. Those scenarios require stronger lifecycle controls and more frequent review because the access path can change faster than the quarterly recertification cycle. The emerging best practice is to pair policy-based access decisions with short-lived credentials and explicit revocation triggers, rather than relying on static standing access. For additional context on how cloud entitlement failures become security incidents, see 52 NHI Breaches Analysis and the OWASP Non-Human Identity Top 10.

Related resources from NHI Mgmt Group

• Who is accountable when a cloud workload retains privileged access after it should have been removed?
• Who is accountable when third-party or guest device access is over-extended?
• Who is accountable for access control evidence under SOC and SOX?
• Who is accountable when access controls fail in SOX-scoped systems?