Who should own access decisions when IAM spans multiple teams?

Why This Matters for Security Teams

When IAM spans application owners, platform teams, security, and IT, the risk is not just slow approvals. The real failure is ambiguous accountability: no one knows who should approve access, who can challenge it, and who is responsible when access becomes stale. That pattern is visible across NHI programs too. NHI Management Group notes that only 20% of organisations have formal processes for offboarding and revoking API keys in the Ultimate Guide to NHIs, which shows how quickly ownership gaps become security gaps.

Security teams often default to centralising every decision in IAM, but that creates bottlenecks and weakens business context. Business owners understand whether access is still needed for a contract, system, or process relationship; IAM can enforce policy and preserve evidence, but it cannot invent that context. Current guidance from OWASP Non-Human Identity Top 10 and NHI governance research both point to the same problem: unclear ownership leads to excessive privilege, delayed revocation, and approvals that outlive the business need. In practice, many security teams discover the ownership gap only after access has already been over-granted or left in place after a role change.

How It Works in Practice

The cleanest operating model separates decision ownership from control execution. The business owner of the application, dataset, workload, or vendor relationship owns the access decision because they can answer the only question that matters: should this identity still have access for this business purpose? IAM, security, and IT then enforce the workflow, collect evidence, and apply policy consistently.

That model works best when the request flow is explicit:

• Business owner approves or denies based on business need, data sensitivity, and duration.
• IAM validates the request against RBAC, SoD, lifecycle, and JIT requirements.
• Security defines policy, reviews exceptions, and monitors for abuse or drift.
• IT or platform teams provision, revoke, and log changes in the source systems.

For NHI and agentic workloads, the same split still applies, but the object being owned is often a workload identity or secret set rather than a person. That is why NHI programs increasingly rely on workflow-backed approvals, ephemeral access, and strong evidence trails, as outlined in the Ultimate Guide to NHIs — Key Challenges and Risks. The practical goal is to make approval accountable without forcing every team to interpret policy differently. Standards like OWASP Non-Human Identity Top 10 support that approach by emphasising least privilege, rotation, and lifecycle control.

Good practice also requires a reviewable trail: who approved, what business justification was given, when access expires, and who can revoke it if circumstances change. These controls tend to break down when multiple teams share a service account ownership model because nobody feels responsible for the last mile of revocation.

Common Variations and Edge Cases

Tighter approval ownership often increases process overhead, so organisations have to balance stronger accountability against the need for fast change delivery. That tradeoff is especially visible in shared platforms, matrix organisations, and vendor-managed services where a single business owner may not have full operational visibility.

There is no universal standard for this yet, but current guidance suggests a few workable variations. For high-risk access, require the business owner to approve and a security reviewer to validate exceptions. For low-risk, repeatable access, pre-approve patterns through policy and let IAM enforce them automatically. For cross-functional systems, assign one named accountable owner and make the other teams consultative rather than co-equal approvers. That avoids the common failure mode where everyone can comment but nobody can decide.

The same logic applies to service accounts and agentic AI identities, where access decisions must often be tied to the workload purpose rather than the team chart. NHI Management Group research shows that excessive privileges and weak offboarding remain widespread, so ownership must be tied to lifecycle events, not just initial provisioning. The strongest control point is usually the business system owner, but IAM and security should still retain veto authority for policy violations and emergency revocation.

Related resources from NHI Mgmt Group

• Who should own access decisions when service management and IAM are connected?
• Who should own access decisions when ITSM and IAM responsibilities overlap?
• How do IAM teams decide whether an AI security assistant needs its own access controls?
• Who should own access review decisions in an IAM programme?