TL;DR: IGA improves visibility into who has access, but it does not govern how work is executed across applications, processes, and transactions, according to SafePaaS. That distinction matters because segregation of duties and enterprise risk are business execution problems, not just access management problems.
At a glance
What this is: This is an analysis of why identity governance and administration stops at access control and does not, by itself, govern enterprise execution or SoD risk.
Why it matters: It matters because IAM and IGA teams are often asked to prove control over business outcomes that only federated governance across identity, process, transaction, and data layers can actually enforce.
Context
Identity governance and administration is often treated as the control point that proves an enterprise is governed, but that assumption breaks down once work crosses systems, processes, and transactions. Governance is about outcomes, not just identities or entitlements, so a programme that stops at access reviews can leave segregation of duties and execution risk untouched.
The article's core claim is that IGA remains necessary but insufficient: it can show who has access and whether approvals exist, yet it cannot determine whether that access combination produces a risky business action across applications. For identity teams, the gap is between access administration and federated governance of how the enterprise actually operates.
Key questions
Q: What breaks when IGA is treated as enterprise governance?
A: Access visibility remains useful, but the organisation starts certifying entitlements instead of controlling outcomes. That leaves process conflicts, transaction risk, and SoD failures outside the control boundary, even when reviews and approvals look complete. The result is formal compliance without reliable business governance.
Q: Why do segregation of duties conflicts still appear after periodic reviews?
A: Because periodic reviews only see the access state that exists at the moment of review. If roles, approvals, or transaction paths change between cycles, conflicts can reappear before anyone notices. The gap closes when SoD rules are enforced in provisioning and lifecycle workflows rather than documented after the fact.
Q: How do you know if IGA is actually governing the business?
A: Look for whether controls evaluate transactions and process outcomes, not only roles and approvals. If audit findings still recur, compensating controls keep growing, and manual reviews never disappear, the governance model is still centred on identity administration rather than enterprise execution.
Q: What is the difference between identity governance and federated governance?
A: Identity governance manages access rights, approvals, and entitlement hygiene. Federated governance extends that model across applications, processes, transactions, data, and infrastructure so the organisation can judge whether work is executed correctly and safely in practice. The second model governs outcomes; the first mostly governs permissions.
Technical breakdown
Why identity-centric IGA cannot govern business execution
IGA platforms are built to manage identities, roles, entitlements, and approval workflows. That scope is useful for proving access discipline, but it does not extend into the business logic of how transactions are initiated, approved, reconciled, or combined across systems. When governance is reduced to entitlement review, control becomes retrospective and fragmented. The enterprise may know who could act, yet still not know whether the resulting action sequence is acceptable in business terms.
Practical implication: Practitioners need to treat IGA as an access control layer, not the full governance model.
How segregation of duties fails across applications and time
Segregation of duties is rarely broken inside a single application. The real risk appears when a person can perform sequential steps across different systems, such as initiating, approving, and reconciling the same business event. Each step may look compliant on its own, while the combined sequence creates a conflict. Traditional IGA can flag role overlap, but it cannot reliably evaluate the business meaning of cross-system execution patterns in real time.
Practical implication: SoD controls must be evaluated at the process level, not only at the entitlement level.
What federated identity access governance adds above IGA
Federated identity access governance, as described in the article, is a control layer that connects identities to business processes, processes to transactions, and transactions to risk outcomes. It is not centralisation for its own sake. It is a way to govern execution where work is distributed across cloud, SaaS, ERP, and legacy environments. That architecture shifts the question from who has access to what that access enables in practice.
Practical implication: Design governance so that process and transaction risk are evaluated alongside identity data.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
IGA is a control plane for access, not a governance plane for outcomes. The article's central failure mode is category confusion: access administration is being mistaken for enterprise governance. That matters because boards and auditors care about whether business is executed correctly, not whether entitlements were reviewed on schedule. Practitioners should stop treating access visibility as proof of control maturity.
Segregation of duties is an execution problem before it is an identity problem. The article correctly frames SoD as risk that emerges across applications, processes, and time, not inside a single system. That means the traditional entitlement-only model can certify conflicting permissions while missing the harmful sequence those permissions enable. The implication is that governance must follow business action chains, not just identity records.
Federated governance is the named concept that closes the control gap. It describes the layer that links identities, applications, processes, data, and infrastructure into one outcome-oriented control model. This is materially different from centralised identity administration because it evaluates what work gets done, not only who can log in. Practitioners should think in terms of governed execution paths, not isolated access events.
The enterprise control debt created by IGA-only thinking is operational as well as audit-related. The article points to recurring manual controls, compensating processes, and persistent findings as symptoms of a model that cannot scale. That is not a tooling inconvenience, it is a structural mismatch between how modern enterprises operate and how legacy governance is measured. Practitioners should re-map control ownership to the actual business flow.
True governance must be federated because modern enterprise risk is federated. Cloud platforms, SaaS providers, ERP modernisation, and M&A activity all distribute execution across boundaries that no single identity system can fully see. The control question is therefore not whether IGA exists, but whether the governance model can reason across systems and transactions. Practitioners should align their governance architecture to the enterprise's operating reality.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
What this signals
Federated governance is the missing control layer: enterprises do not fail because they lack identity records, they fail because no single control view spans the business actions those identities enable. That makes transaction-aware governance a programme design issue, not a reporting enhancement.
IGA maturity should be measured by whether it reduces manual exception handling and recurring audit remediation, not by how many entitlements can be catalogued. When control evidence still has to be assembled after the fact, the programme is describing access, not governing outcomes.
For practitioners
- Separate access governance from execution governance Document which controls prove entitlement hygiene and which controls prove that business actions are executed correctly across systems.
- Map segregation of duties at the process level Trace initiation, approval, reconciliation, and settlement paths across applications so SoD conflicts are evaluated as one workflow.
- Federate governance signals across systems Correlate identity data with transaction context, application state, and business outcomes instead of relying on a single repository.
- Retire recurring compensating controls Identify manual reviews and exception paths that persist because IGA cannot see execution risk, then redesign them into upstream controls.
Key takeaways
- IGA can show who has access, but it cannot by itself prove that business is executed correctly across systems.
- Segregation of duties failures often arise from cross-application action sequences, which identity-centric reviews are not designed to judge.
- Federated governance is the practical response because it ties identity, process, transaction, and risk outcome into one control model.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The article reframes governance around enterprise outcomes, not identity objects. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | IGA still matters for entitlement control, even though it is not the whole governance model. | |
| Recommendation — Align governance controls to business outcomes instead of stopping at access administration. Use entitlement governance to verify who can access what, then extend controls to execution risk. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The article's access-centric limit shows why least privilege remains necessary but insufficient. |
| Recommendation — Apply least-privilege controls to reduce overbroad access before evaluating process-level risk. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article depends on sound account and entitlement management as the baseline control layer. |
| Recommendation — Maintain accurate account and entitlement inventories as the starting point for broader governance. | ||
Key terms
- Federated Governance: A governance operating model where central teams define policy and control standards, but business domain owners make access decisions inside those guardrails. It fits organizations where risk, process knowledge, and operational responsibility are distributed across functions, regions, or platforms.
- Segregation of Duties: Segregation of Duties is a control principle that prevents one person or role from combining incompatible permissions that could create fraud, error, or undetected change. In ERP environments, it must account for roles, transactions, approvals, and compensating controls across business processes.
- Control Debt: Control debt is the accumulation of weak, custom, or poorly owned security decisions that make future governance harder. In identity programmes, it appears when exceptions, one-off workflows, and legacy process assumptions become embedded in the access model and are expensive to unwind later.
- Execution Governance: Execution governance is the policy and ownership model that determines what software may run, who can approve exceptions, and how those decisions are reviewed. It connects endpoint security to operational control, because unmanaged exceptions often become a hidden source of risk.
Deepen your knowledge
Identity lifecycle management, secrets management, and workload identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org