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 IGA stops short of true enterprise governance and why federated governance is needed to connect identity to business outcomes.
Why it matters: It matters because identity teams can meet access-review goals while leaving segregation of duties, transaction risk, and control debt unresolved across the wider enterprise.
👉 Read SafePaaS's analysis of why IGA is not enough for enterprise governance
Context
Identity Governance and Administration is often treated as the centre of enterprise control, but access governance is not the same as governing how the business behaves. The gap appears when identities are approved correctly and the resulting actions still produce risk, audit findings, or conflicting business outcomes.
For IAM, IGA, and GRC teams, the issue is that governance must extend beyond entitlements into applications, transactions, processes, and infrastructure. SafePaaS frames federated identity access governance as the layer that connects those control points, but the underlying problem is broader than any single platform.
Key questions
Q: How should security teams govern access when business risk happens across multiple systems?
A: Security teams should govern the business outcome, not just the entitlement. If a risky action can be initiated in one system, approved in another, and completed in a third, then access reviews in any single platform will miss the combined exposure. The control model needs workflow correlation, transaction context, and clear ownership for the full process.
Q: Why does segregation of duties keep failing in mature IGA programmes?
A: SoD keeps failing because it is usually a business execution problem, not a single-system permission problem. Valid entitlements can combine across applications and time to create an unsafe outcome that no one role review reveals. Mature IGA improves visibility, but it does not automatically detect how actions interact across the process chain.
Q: What do organisations get wrong about treating IGA as enterprise governance?
A: They confuse access governance with outcome governance. IGA can show who has access and whether approvals were completed, but it cannot prove that the business behaved safely after the access was used. The mistake is assuming the identity layer is the same as the operating model.
Q: How can organisations tell whether federated governance is actually working?
A: Look for fewer recurring manual controls, fewer repeated SoD findings, and better correlation between identity records and transaction outcomes. If the programme still depends on compensating checks to catch what the identity tool cannot see, governance is still fragmented. Real progress shows up when risky behaviour is stopped or blocked before completion.
Technical breakdown
Why IGA controls access, not execution
Traditional IGA platforms answer who has access, how it was requested, and whether it matches policy. That is useful for entitlement hygiene, but it is not the same as governing execution. Execution risk emerges when legitimate entitlements combine across systems, time, and business steps to produce an outcome that no single approval review would catch. In other words, IGA is identity-centric and access-centric, while governance is outcome-centric. The control boundary ends at the account and role layer, not at the business process or transaction layer.
Practical implication: treat IGA as one control input and add process- and transaction-level governance where business risk is created.
How segregation of duties breaks across systems
Segregation of duties is rarely violated inside one application. It usually appears when one person can initiate, approve, and reconcile actions across different systems or different stages of the same workflow. Each entitlement looks legitimate in isolation, so an IGA review can pass while the combined behaviour still creates fraud, compliance, or operational exposure. That is why SoD is a business execution issue, not merely an access matrix problem. Without cross-system correlation, organisations only see fragments of the risk.
Practical implication: map SoD rules to end-to-end business workflows, not to a single application’s role model.
Federated governance adds the missing control layer
Federated identity access governance is the idea that governance intelligence must sit above isolated identity tools and connect identity, business process, transaction, and risk outcome. It does not replace IGA. It uses IGA data as one signal and adds context from applications, data, and operational flow so the organisation can judge whether access actually enables unsafe business behaviour. That makes governance more dynamic, because the control question shifts from approval status to business effect.
Practical implication: build a governance layer that correlates identity data with business events before risks become audit findings.
NHI Mgmt Group analysis
IGA is a control plane for access, not a governance model for outcomes. The article is correct to separate identity administration from enterprise governance, because approved access can still produce ungoverned business behaviour once it is exercised across systems and processes. That is the structural limit of entitlement-centric control. Practitioners should stop measuring governance success by access approval alone.
Segregation of duties is a workflow integrity problem disguised as an access problem. A person can hold individually valid entitlements and still violate SoD when those privileges are used across initiation, approval, and reconciliation steps. This is why SoD findings keep recurring even in mature IGA programmes. The practitioner takeaway is to model SoD at the process layer, not only inside the identity repository.
Federated Identity Access Governance is a useful concept because it recognises that control evidence lives outside the IGA tool. Identity data must be joined to application events, transaction records, and risk outcomes if the business wants to know whether governance is real. That does not weaken IGA, but it does demote IGA from endpoint to input. The practitioner implication is to federate control intelligence across systems rather than centralise hope in one platform.
Identity programmes fail when they equate compliance artefacts with operational control. Audit-ready access records can coexist with fragmented enforcement, manual compensating controls, and hidden control debt. The article captures a common enterprise blind spot: formal governance appears complete while execution risk remains unmanaged. The practitioner conclusion is that governance must be judged by business outcome, not by policy conformance alone.
From our research:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which explains why governance fails when entitlement data is treated as complete.
- For a broader control perspective, see Ultimate Guide to NHIs , Regulatory and Audit Perspectives for how audit obligations extend beyond access records.
What this signals
Governance debt will keep shifting out of the identity tool and into the process layer. Teams that rely on IGA alone will continue to see recurring SoD findings, because the real risk sits where entitlements are exercised across systems. The programme signal is clear: invest in transaction-aware controls and correlate identity data with business events before the audit cycle does it for you.
Identity reviews will become less credible if they are not paired with workflow evidence. A clean access certification can still coexist with unsafe execution, so boards and auditors will increasingly ask for proof that controls worked at the point of business action. That pushes IAM, GRC, and process owners toward shared control evidence rather than separate reporting.
Federated control intelligence is the next maturity step for enterprise identity programmes. The organisations that move first will stop using IGA as the centre of gravity and start using it as one source of evidence among several. The change is not cosmetic, because governance that cannot see the transaction cannot prove the outcome.
For practitioners
- Map governance to business outcomes Define the specific business outcomes that must remain safe, such as approvals, reconciliations, journal entries, or vendor changes, and trace them back to the identities and systems that can affect them. Use those outcomes as the unit of governance rather than treating access reviews as the finish line.
- Model segregation of duties across workflows Build SoD rules around end-to-end process steps across applications, not around a single role catalogue. Correlate who initiates, who approves, and who completes the transaction so you can see combined risk even when each entitlement is individually valid.
- Federate control evidence beyond IGA Join identity data with application logs, transaction history, and risk indicators so governance decisions reflect actual execution. This is the only way to distinguish clean entitlement hygiene from genuinely controlled business behaviour.
- Retire compensating controls that mask design gaps Track recurring manual reviews, after-the-fact exception handling, and local spreadsheet checks as symptoms of governance debt. Replace them with control points that test behaviour before the transaction closes or the business action is finalised.
Key takeaways
- IGA manages access, but it does not by itself govern the business outcomes that access enables.
- Segregation of duties failures usually arise across workflows and systems, which is why entitlement reviews alone miss the real risk.
- Federated governance matters because it joins identity data to transaction evidence, allowing organisations to measure control where execution actually happens.
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 CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-4 | Access permissions management is central to the article's IGA critique. |
| NIST CSF 2.0 | GV.OV-01 | Governance oversight is needed where access control does not prove execution control. |
| NIST Zero Trust (SP 800-207) | Zero Trust reinforces continuous verification across systems, not one identity store. |
Establish outcome-level governance metrics that prove controls work in business processes.
Key terms
- Federated Identity Access Governance: A governance model that joins identity data to application, process, transaction, and risk evidence so the organisation can judge whether access actually produces safe business outcomes. It treats IGA as one source of control information, not the complete picture, and is designed for federated enterprises with distributed execution.
- Segregation Of Duties: A control principle that prevents one person from performing incompatible steps in a business process, such as initiating, approving, and reconciling the same transaction. In practice, it must be evaluated across workflows and systems, because isolated entitlements can look safe while combined actions create material risk.
- Compensating Control: A manual or secondary control used when the primary control is incomplete, unavailable, or unable to enforce the intended outcome. These controls often preserve compliance on paper, but they also signal design debt when they recur in the same process and become the main way risk is managed.
- Outcome Governance: A way of governing that measures whether the business action itself stayed within acceptable risk, compliance, and operational boundaries. It goes beyond access approval and checks whether the actual decision, transaction, or workflow produced the intended result without creating hidden exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
This post draws on content published by SafePaaS: Federated identity access governance and the limits of IGA. Read the original.
Published by the NHIMG editorial team on 2026-01-27.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org