IAM software vs IGA: why governance matters beyond logins

At a glance

What this is: This analysis separates IAM from IGA and shows why login control alone does not resolve access governance, compliance, or toxic entitlement risk.

Why it matters: IAM teams, IGA leads, and security architects need both enforcement and governance because real risk emerges when access remains justified on paper long after it stops making business sense.

By the numbers:

• 84% of organizations still rely primarily on manual processes for user access reviews and provisioning, with fewer than 6% achieving full automation.
• One 2025 report found that non-human identities can outnumber human identities by roughly 144 to 1 in large enterprises.

👉 Read SafePaaS's analysis of IAM software vs IGA and federated governance

Context

IAM software and identity governance solve different parts of the access problem. IAM decides whether an identity can log in and reach a resource right now, while IGA decides whether that access should still exist, remain compliant, and stand up to audit over time. When organisations treat those as interchangeable, they end up with stronger sign-in controls and weaker accountability for who can still move data, approve payments, or change production systems.

That gap matters because modern identity stacks now include human users, service accounts, tokens, and AI-influenced workflows. A programme built only around authentication and session control can enforce bad access decisions very efficiently. The governance question is whether the access model still reflects policy, segregation-of-duties rules, and lifecycle state across the full identity estate.

Key questions

Q: How should organisations decide whether to invest in IAM or IGA first?

A: Start with the control failure that creates the biggest business risk. If users cannot authenticate reliably, IAM is the immediate priority. If access already works but entitlement justification, segregation of duties, and audit evidence are weak, IGA should come first. Most mature programmes need both, but governance usually closes the more dangerous gap when login control is already in place.

Q: Why do access reviews fail when they are run in spreadsheets?

A: Spreadsheets cannot reliably model cross-application conflicts, ownership changes, expiry dates, or remediation status at scale. They also encourage rubber-stamping because reviewers see lists, not business context. When the review process is manual, the organisation often checks activity, not justification. That is why toxic access can survive multiple review cycles without being meaningfully challenged.

Q: What does federated identity governance solve that IAM alone does not?

A: It creates one governance layer across multiple IAM systems, ERP platforms, and SaaS apps so policy and risk decisions are consistent. IAM can enforce access in each system, but federated governance can compare entitlements across systems, detect SoD conflicts, and orchestrate review and remediation from a single control plane.

Q: How should security teams govern non-human identities alongside human users?

A: Apply the same governance principles to machine identities that you already apply to people: clear ownership, lifecycle state, access justification, periodic review, and timely revocation. Service accounts, tokens, and bots can be over-privileged for long periods if they sit outside governance workflows, which makes them a hidden source of audit and breach risk.

Technical breakdown

IAM enforces access at login, but it does not validate business justification

Identity and access management software is built to answer a narrow question: can this identity authenticate and reach this system now? It does that through SSO, MFA, conditional access, directory sync, and basic provisioning controls. That is useful, but it is not a governance decision. If a role is over-entitled, if an exception never expires, or if an admin grant is created outside policy, IAM will usually enforce it just as effectively as a valid entitlement. The control plane is working exactly as designed, which is the point. The failure is upstream in the access decision model, not in session enforcement.

Practical implication: treat IAM as enforcement, not as evidence that access is still justified.

IGA adds lifecycle control, access reviews, and SoD enforcement

Identity Governance and Administration is the policy and evidence layer that governs who should have access, why they should have it, and how long it should remain in place. It covers joiner-mover-leaver workflows, access requests, periodic certifications, role modelling, segregation-of-duties rules, and audit-ready reporting. The important distinction is temporal. IGA is lifecycle-based, so it can challenge access that was once valid but is no longer defensible. That is why IGA is the part that can reveal toxic combinations such as request plus approve plus pay, even when those permissions are spread across multiple applications.

Practical implication: move high-risk entitlements into review and certification workflows that force explicit re-approval.

Federated identity governance creates one control plane across fragmented systems

Most enterprises do not have one clean identity stack. They have multiple directories, several IAM systems, ERP and finance platforms, SaaS applications, and business units that each manage access differently. Federated identity governance sits above those systems and normalises entitlements into one model for policy, risk scoring, and remediation. That matters because a toxic combination may not exist inside a single application. The risky outcome often only appears when permissions are combined across Oracle, SAP, Workday, and SaaS. A federated model lets governance follow the business process instead of being trapped inside app silos.

Practical implication: centralise SoD and access review logic across systems, not inside each application separately.

Threat narrative

Attacker objective: The attacker or insider seeks to use legitimate access paths to perform high-risk actions without triggering governance controls.

1. Entry occurs when a user, administrator, or non-human identity receives access that is technically valid but not yet governance-checked against business policy.
2. Escalation happens when over-entitled roles, exception grants, or unreviewed access accumulate into toxic combinations such as request plus approve plus pay.
3. Impact follows when auditors, finance teams, or security owners discover that access was never properly justified, creating fraud exposure, failed controls, or misstatements.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IAM-only programmes create a governance illusion. They improve authentication, conditional access, and session enforcement, but they do not answer whether an entitlement is still justifiable. That leaves organisations with modern login controls and manual spreadsheets governing high-risk access decisions. The practical conclusion is simple: enforcement without governance only makes bad access faster to use.

Access review as a manual ritual is a control failure, not a process preference. If 84% of organisations still rely primarily on manual review and provisioning, the evidence is that most access governance is still operating as an after-the-fact paperwork exercise. Spreadsheet-based review cannot reliably surface toxic segregation-of-duties combinations across fragmented systems. The practitioner conclusion is that review evidence must be systemised or it will remain incomplete.

Federated identity governance is the missing control plane for business-risk decisions. The strongest governance models do not replace IAM; they sit above it and decide whether access across ERP, SaaS, and directories is defensible in context. That matters because business risk rarely lives in a single system. The practitioner conclusion is to govern end-to-end access across the process, not per application.

Non-human identities make the IAM versus IGA distinction sharper, not weaker. Service accounts, tokens, bots, and AI-influenced workflows can be authenticated perfectly and still remain over-privileged or unreviewed for months. That is why access governance has to extend beyond human employee lifecycle thinking. The practitioner conclusion is to apply the same governance discipline to machine and service identities that already exists for people.

Identity governance must be measured by revocation, exception expiry, and SoD closure, not login success. A mature programme proves that access is reviewed, justified, and removed when the business condition changes. If the only telemetry is sign-in success, the organisation is measuring availability while ignoring entitlement risk. The practitioner conclusion is to shift programme metrics toward governance completion and control closure.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which is why entitlement review and revocation must be treated as a control gap, not a reporting exercise.
• Use the NHI Lifecycle Management Guide to map ownership, rotation, and offboarding controls to the identities that actually carry operational risk.

What this signals

Access governance will keep shifting from periodic review to continuous entitlement control. The practical direction of travel is away from spreadsheet certification and toward always-on review, evidence capture, and exception expiry. For teams modernising IAM and IGA together, the question is no longer whether governance exists, but whether it can keep pace with business change. Link the operating model to the NIST Cybersecurity Framework 2.0 so access control and accountability are measured together.

Identity estates that include service accounts, tokens, and automation will force broader governance scope. The same review logic that once covered employees now has to extend to machine identities, or the control model will leave the fastest-growing access paths outside oversight. One useful reference point is the OWASP Non-Human Identity Top 10, which helps teams frame visibility, rotation, and privilege as governance problems rather than isolated hygiene tasks.

Exception debt is becoming the real identity risk. Each temporary grant, inherited role, or reviewer override that is never closed creates a future audit problem and a future abuse path. For practitioners, the signal to watch is whether access decisions can be re-certified, traced, and retired without manual rescue work.

For practitioners

• Separate enforcement from entitlement governance Keep IAM focused on authentication, conditional access, and session control, then layer IGA on top for access justification, review, and revocation across business systems.
• Automate high-risk access reviews first Prioritise privileged roles, finance entitlements, production access, and SoD-sensitive combinations before broad low-risk campaigns, so reviewers spend time where the loss exposure is highest.
• Model SoD across application boundaries Build rules for end-to-end business processes such as request, approve, and pay, then apply them across ERP, SaaS, and directory sources instead of only within one platform.
• Govern non-human identities under the same policy logic Bring service accounts, tokens, and bots into the same lifecycle and certification process so machine access is not exempt from justification, ownership, and revocation discipline.
• Track governance completion metrics Measure how many entitlements were reviewed, remediated, and re-certified on time, then report the backlog of exceptions that remain open after the review cycle closes.

Key takeaways

• IAM controls who can log in, but IGA determines whether that access still deserves to exist.
• Manual access reviews hide toxic segregation-of-duties conflicts and keep governance evidence fragile.
• Federated governance and lifecycle discipline are the controls that turn identity from an access problem into a managed risk function.

Key terms

• Identity Governance And Administration: The policy and control layer that decides which access should exist, for how long, and under what justification. It produces evidence for auditors, risk teams, and business owners, and it can revoke access when role, purpose, or policy no longer support it.
• Segregation Of Duties: A control principle that prevents one identity from completing incompatible steps in a business process. In practice, it stops combinations such as request, approve, and pay from sitting in one set of hands, whether those permissions are spread across one system or many.
• Federated Identity Governance: A governance model that overlays multiple identity systems and applications with one consistent policy, risk, and review layer. It is used when access is fragmented across ERP, SaaS, directories, and business units, but the organisation still needs unified evidence and control.
• Non-Human Identity: A digital identity used by software, workloads, automation, or agents rather than a person. These identities include service accounts, API keys, tokens, certificates, and bots, and they require lifecycle, ownership, and revocation controls because they often carry standing privilege.

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 building or maturing an identity security programme, it is worth exploring.

This post draws on content published by SafePaaS: IAM software vs IGA and federated governance. Read the original.