Who should own access orchestration across IAM, IGA, and application security?

Why This Matters for Security Teams

Access orchestration across IAM, IGA, and application security is not just a process question. It determines whether identities are governed as isolated systems or as one control surface. When ownership is split too loosely, policy decisions drift, reviews become inconsistent, and exceptions accumulate outside normal change control. That is especially risky for non-human identities, where secrets, tokens, and service accounts often sit between platform teams and application teams with no single accountable owner.

The current research signal is clear: the State of Non-Human Identity Security found that only 1.5 out of 10 organisations are highly confident in securing NHIs, while OWASP Non-Human Identity Top 10 continues to emphasize credential sprawl, over-privilege, and weak lifecycle governance as recurring failure modes. In practice, control ownership needs to sit where policy can be defined, enforcement can be measured, and evidence can be produced without waiting on multiple queues.

In practice, many security teams encounter control gaps only after an audit finding, a leaked secret, or a failed application change, rather than through intentional access design.

How It Works in Practice

The most workable model is a cross-functional control group with a named accountable function and clear handoffs. IAM typically owns identity primitives, authentication patterns, and enterprise policy enforcement. IGA owns access request workflow, entitlement review, and recertification evidence. Application security owns how privileges are embedded in apps, APIs, workloads, and automation. Audit and risk stakeholders validate that the control is not only designed, but operating consistently.

That model matters because access orchestration is really about sequencing decisions, not just approving accounts. A request may start in IGA, pass through IAM policy, and end in application-side provisioning or secret issuance. If any one of those steps is owned in isolation, the organisation gets partial governance and weak traceability. For NHIs, that often means secrets are issued without a clear business justification, or service accounts survive long after the workload has changed. NHIMG research on the Ultimate Guide to NHIs highlights how lifecycle gaps and poor visibility create the conditions for over-privileged machine access.

• Define one policy owner for access standards, even if multiple teams enforce different steps.
• Use IGA to capture approvals and review cadence, not to “own” every downstream technical control.
• Use IAM for identity proofing, federation, role mapping, and centralized policy enforcement.
• Use application security to validate that app-level permissions, secrets, and service accounts match the approved design.
• Track evidence in a shared control register so exceptions, compensating controls, and revocations are visible.

For implementation, current guidance suggests mapping each orchestration step to a specific control objective and record owner, then aligning that model with the OWASP Non-Human Identity Top 10 and the NHI lifecycle risks described in 52 NHI Breaches Analysis. These controls tend to break down in organisations with fragmented tooling and separate reporting lines because no team owns the full path from request to revocation.

Common Variations and Edge Cases

Tighter orchestration often increases coordination overhead, requiring organisations to balance speed against assurance. That tradeoff becomes more visible in DevOps-heavy environments, mergers, and platform teams that manage both human and machine identities. There is no universal standard for ownership design yet, but best practice is evolving toward shared governance with one accountable control owner, not committee ownership.

In smaller organisations, IAM may act as the control lead because the team already owns federation and enterprise policy, while app sec supplies entitlement standards and exception review. In larger environments, a security governance or identity governance office may own orchestration, with IAM, IGA, and app sec as enforcement partners. The key is that ownership must include the ability to prove enforcement. If a team cannot produce logs, approvals, and revocation evidence, it does not truly own the control.

This is especially important where secrets management and application access overlap. NHIMG’s State of Secrets in AppSec reports an average of 6 distinct secrets manager instances, which is a strong indicator that decentralised ownership can quickly become fragmented. The edge case is not whether decentralisation is allowed. The edge case is whether the organisation has one place to reconcile policy, exception handling, and evidence when systems span multiple domains.

Related resources from NHI Mgmt Group

• Who should own automated IGA outcomes across HR, IT, and security?
• Who should own IGA outcomes when compliance, IAM, and application teams all touch access?
• How should security teams govern AI transformation across identity and access programmes?
• Who is accountable when identity security controls fail across IAM, PAM, and NHI programmes?