IAM software vs IGA: why governance matters beyond logins

At a glance

What this is: This is a governance analysis showing that IAM software controls entry, while IGA controls whether access should still exist and remain defensible.

Why it matters: It matters because IAM-only programmes can leave toxic access, segregation-of-duties conflicts, and audit exposure hidden behind successful logins.

Context

IAM and IGA are often treated as one category, but they solve different problems. IAM decides whether an identity can authenticate and reach a resource now, while IGA governs whether that access is still justified, compliant, and defensible over time.

The governance gap appears when organisations fund login controls but leave access reviews, approvals, and revocation decisions in spreadsheets. In that model, access can look legitimate at sign-in and still be unsafe, over-entitled, or non-compliant at the business level.

This article is about identity governance for human users and non-human identities alike, because the failure is not authentication itself. The failure is the absence of a durable control layer that can answer who should still have what access, and why.

Key questions

Q: What breaks when organisations stop at IAM and skip IGA?

A: They can still authenticate users while leaving entitlement validity unchecked. That creates hidden over-provisioning, toxic Segregation of Duties conflicts, and weak audit evidence. In practice, the programme can look mature at login but fail when someone asks who should still have privileged business access and why.

Q: Why do manual access request processes create governance risk?

A: Manual processes increase the chance of inconsistent approvals, slow fulfilment, and weak audit trails. When access decisions are handled through tickets or emails, the organisation often cannot prove that the same criteria were applied every time. That makes manual handling a control weakness, not just an operational burden.

Q: How should security teams govern access across SaaS sprawl?

A: Security teams should govern SaaS sprawl with one inventory, one policy model, and one review process that covers both human and non-human access. The practical goal is to connect application approval, entitlement review, and revocation to business ownership. Without that linkage, access governance becomes a manual cleanup exercise instead of a control system.

Q: How do teams decide whether access is actually justified over time?

A: By tying certification, role design, and revocation to business purpose, not just successful authentication. If the organisation cannot explain why the access exists, who approved it, and when it will expire, the entitlement should be treated as a governance defect rather than an active right.

Technical breakdown

IAM software governs access at the point of login

IAM software authenticates users, authorises access, and enforces policy during sign-in and session handling. In practice, that means SSO, MFA, conditional access, directory sync, and basic provision and deprovision workflows. The control is transactional, not lifecycle-based, so it can only enforce the decision it is given. If role design, exception handling, or entitlement assignment is weak, IAM will still execute it cleanly. That is why strong front-door controls can coexist with weak internal governance.

Practical implication: treat IAM as the enforcement layer and separately validate whether the access decisions feeding it are still correct.

IGA governs eligibility, approvals, and audit evidence

IGA is the policy and process layer that decides who should get access, when, why, and for how long. It covers joiner-mover-leaver flows, access requests, periodic certifications, SoD checks, role modelling, and audit-ready reporting. Unlike IAM, IGA must prove that access remains defensible across time and across applications. That makes it the layer that closes the loop on privilege creep, toxic combinations, and revoked access that never got removed. Without IGA, organisations can know who logged in without knowing whether they should still be entitled.

Practical implication: build access review, SoD, and lifecycle controls around entitlement validity, not just sign-in success.

Federated identity governance normalises fragmented control planes

Large enterprises rarely run one identity stack. They combine directories, cloud IdPs, ERP systems, SaaS, PAM, and application-local controls, each with its own review logic and reporting format. Federated identity governance sits above those silos, normalises identities and entitlements into one model, and orchestrates certification and remediation across systems. The technical point is not centralisation for its own sake. It is control consistency across different platforms so that business-level conflicts can be detected even when the underlying permissions are scattered.

Practical implication: map business-risk entitlements across systems first, then govern them through one cross-application policy model.

Threat narrative

Attacker objective: The objective is to exploit legitimate-looking access that was never revalidated, so privileged actions remain available long enough to create fraud, compliance failure, or operational harm.

1. Entry occurs when IAM software authenticates an identity and allows access based on the current login decision, even if that identity has accumulated stale or excessive entitlements.
2. Escalation follows when over-entitled roles, never-expiring exceptions, or one-off admin grants remain valid because no governance process revalidates them across the lifecycle.
3. Impact appears when toxic access, SoD conflicts, or unreviewed privileged paths lead to financial misstatements, failed audits, or insider abuse without a clear revocation trail.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.

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 is an enforcement layer, not a governance answer: Identity software can authenticate users, apply conditional access, and grant session-level access, but it cannot decide whether access is still appropriate. That distinction matters because organisations often mistake successful login control for a complete identity programme. The practical conclusion is that IAM without IGA is a front door with no ongoing entitlement challenge.

Access review failures are governance failures, not process noise: When quarterly reviews live in spreadsheets and app owners rubber-stamp lists, the organisation has already lost the control objective. The issue is not review frequency alone. The issue is that access validity is not continuously testable across systems, so toxic combinations survive until audit or incident exposure forces them into view. Practitioners should treat manual review dependence as a material control gap.

Federated identity governance is the missing control plane for complex estates: Once ERP, SaaS, cloud directories, PAM, and business-unit approvals diverge, no single application owns the full risk picture. A federated model matters because it can normalise entitlements, apply business-level SoD rules, and keep evidence coherent across systems. That is the only defensible way to govern who can move money, change data, or ship code at scale.

Non-human identities raise the stakes for lifecycle governance: The same access governance discipline now has to cover service accounts, tokens, bots, and AI-driven actors as well as humans. If governance treats those identities as operational leftovers, standing privilege and orphaned access multiply faster than manual review can catch them. The implication is that lifecycle governance must be designed for every identity class, not just employees.

Continuous governance is the named concept here because static entitlement review no longer matches enterprise risk: Access can be granted in seconds, reused across systems, and never revisited unless a separate governance layer forces the check. That makes continuous governance, not point-in-time login control, the real control objective. Practitioners should therefore evaluate identity programmes by revalidation depth, not by authentication volume.

From our research library:

• Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.

What this signals

Continuous governance: IAM tools can confirm identity at login, but they do not answer whether access remains justified after the initial decision. That gap matters most in estates where approvals, exceptions, and role changes outlive the transaction that created them.

When access review logic is distributed across spreadsheets, local app owners, and disconnected workflows, the control becomes difficult to evidence and even harder to standardise. The programme signal is clear: mature identity governance is now a cross-application operating model, not a feature inside a single login platform.

For practitioners

• Define IAM and IGA as separate control layers Document IAM as the authentication and session enforcement layer, and IGA as the entitlement validity and evidence layer. Make sure architecture, ownership, and metrics reflect that split so login success is never mistaken for governance coverage.
• Inventory high-risk entitlements across applications Build a consolidated view of finance, production, admin, and other sensitive access across ERP, SaaS, directories, and PAM. Use the inventory to find where business-critical actions can be taken today without a corresponding review trail.
• Replace spreadsheet reviews with policy-driven certifications Move periodic access certification into a governed workflow that routes reviews to the right owner, applies SoD rules, and records approval or revocation decisions in a defensible audit trail.
• Extend lifecycle governance to non-human identities Bring service accounts, tokens, bots, and AI agents into the same review and revocation model as human users. If an identity can act in production, it needs an owner, an expiry expectation, and a governance trail.

Key takeaways

• IAM software controls access at the point of authentication, but it does not continuously validate whether entitlement remains appropriate.
• The governance failure in large enterprises is often manual review, not missing login controls, which allows toxic access to persist.
• Identity programmes need a separate governance layer so access can be reviewed, justified, and revoked across the full lifecycle.

Key terms

• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• 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.
• Federated identity governance: Federated identity governance distributes control across platforms and business units while keeping policy, evidence, and accountability aligned. It is used when identities and permissions are managed in multiple systems, but the organisation still needs one risk view and one governance standard.
• Continuous governance: An identity governance model that checks and enforces policy as activity happens rather than on a schedule. It is designed to catch drift, misuse, and orphaned access while the identity is still active, which matters when risk unfolds in minutes instead of review cycles.

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 IAM programme, it is worth exploring.