The observation that IAM and IGA secure different threat vectors is correct, and the distinction matters more than the terminology suggests. Organizations that treat them as interchangeable end up with a mature authentication layer and unreviewed privilege accumulation, or robust governance processes running against an identity foundation that isn't trustworthy.

The practitioner consensus from this thread is clear: IGA is a subdomain of IAM, not a separate discipline. You can't do IGA without IAM — governance requires a trusted "who," and that comes from the identity and authentication layer. But IAM alone leaves internal risk largely unaddressed.

What IAM Actually Covers

IAM is the real-time enforcement layer. It answers the question "can this person authenticate and access this resource right now?" and enforces the answer. The core components are:

Authentication — verifying identity through passwords, MFA, passwordless methods, certificates, or hardware tokens. The strength of authentication determines how hard it is for an attacker to impersonate a legitimate user.

Authorization — determining what an authenticated user is allowed to do. This covers role-based access control (RBAC), attribute-based access control (ABAC), conditional access policies, and Privileged Identity Management (PIM) for temporary elevated access.

SSO and federation — connecting identity to applications so users authenticate once and access multiple systems through a trusted token. This also means the identity provider becomes the control point for access to all federated applications.

The key characteristic of IAM: it operates at the moment of access. When someone tries to log in, IAM makes a decision. When someone is assigned to a group, IAM enforces what that group can access. IAM does not concern itself with whether that access is still appropriate six months later, or whether the access was granted through a documented approval process, or whether the person who granted it had the authority to do so.

What IGA Covers That IAM Doesn't

IGA operates on a different time horizon and answers different questions. Where IAM asks "can this person access this now," IGA asks "should this person have this access at all, and is there evidence that someone verified that?"

The three questions IGA continuously addresses — who has access to what, should they have that access based on policy, and what are they doing with it — are governance questions, not authentication questions. IAM enforces the access that has been granted. IGA examines whether what has been granted is still appropriate.

Privilege creep is the canonical IGA problem. As employees change roles, join projects, and are granted temporary access that never gets revoked, they accumulate entitlements that no longer match their current job function. IAM enforces every entitlement that exists in the directory. IGA is the process that periodically verifies which entitlements should still exist and removes the ones that shouldn't.

Orphaned accounts are the offboarding failure that IAM doesn't catch. Disabling an Okta account cuts off SSO-federated applications. It doesn't touch the 60% of enterprise applications that aren't connected to SSO — the tools departments bought independently, the services employees signed up for with their work email, the shadow AI tools that appeared in the last year. IGA's discovery layer maps what users actually have access to, not just what's visible through the identity provider.

Audit readiness is the compliance dimension. SOC 2, ISO 27001, HIPAA, and SOX require evidence that access is periodically reviewed, that decisions are documented, and that access is removed when no longer appropriate. IAM systems log authentication events. IGA systems produce the access review records, the approvals trail, and the certification evidence that auditors require.

How They Fit Together in Practice

The maturity sequence practitioners recommend is: IAM first, then IGA. One commenter in this thread put it directly: IGA can be temporarily substituted with scripts, but there's no compensation for weak authentication. If your authentication is broken — easily phished credentials, no MFA, shared accounts — governance processes won't save you. An attacker with valid credentials looks the same as a legitimate user to every layer of the stack.

Once the authentication foundation is solid, IGA addresses the second category of risk: internal risk from accumulated entitlements, missed deprovisioning, unreviewed access, and compliance gaps. The security value of IGA is less visible in day-to-day operations and more visible in three contexts: when an audit happens and you need to produce evidence, when an employee leaves and you need to verify that all access was revoked, and when a security review finds that former employees have active accounts in systems no one knew about.

The Entra ID example from the thread is instructive: base Entra handles identity repository, authentication, and authorization (the IAM layer), while Entra ID Governance handles access packages, ordering workflows, access reviews, and reporting (the IGA layer). The same platform, two distinct capability sets with different security functions.

Where Each Layer Has Blind Spots

IAM's blind spots are primarily on the internal and SaaS sides. IAM secures the perimeter against unauthorized access. It has limited visibility into what users are doing inside the applications they legitimately access, whether their access is still appropriate relative to their current role, and what's happening in applications that aren't federated to the identity provider. Applications outside SSO are entirely outside IAM's governance scope.

IGA's blind spots are on the real-time enforcement side. IGA identifies that someone has access they shouldn't have. It doesn't prevent them from using that access until the next review cycle runs. For time-sensitive security events — a compromised account, an employee who should be immediately terminated — real-time IAM controls (account disable, session revocation, conditional access) are what actually stops the threat. Governance is retrospective; authentication is immediate.

The two layers are complementary rather than competitive. As one practitioner in this thread framed it: IAM protects against outside threats and slightly from insiders; IGA protects from insiders and slightly from outside threats. The word "slightly" in both cases is where the overlap lives.

The Shadow IT Problem: Where IGA Fills an IAM Gap

The shadow IT scenario deserves specific attention because it's where the theoretical IAM/IGA distinction becomes a concrete security gap.

An employee signs up for an AI tool with their work email. IT doesn't know it exists. The tool isn't connected to SSO. When the employee leaves, IT disables their Okta account — and the AI tool account remains active indefinitely because IAM has no visibility into it and never did.

IGA's discovery approach — pulling usage data from browser agents, financial system integrations, and SSO OAuth logs — surfaces these tools and maps them to users regardless of whether they went through formal provisioning. This brings them into the offboarding scope and into the periodic access review scope. IAM can't govern what it can't see; IGA's discovery function is what extends the governance boundary beyond the SSO perimeter.

Frequently Asked Questions

What is the difference between IAM and IGA?

IAM covers the real-time enforcement of identity: authentication (verifying who you are), authorization (determining what you can access), SSO, MFA, and session management. IGA covers the governance of identity over time: who has access, whether that access is appropriate based on current role and policy, periodic access reviews, audit trail of how access was granted, and automated lifecycle management when people join, move, or leave. IGA is a subdomain of the broader IAM domain that focuses specifically on governance and compliance.

Which should you implement first, IAM or IGA?

IAM first. Governance processes run against an identity foundation — if the authentication layer is weak or untrusted, access reviews and lifecycle automation don't provide meaningful security improvement. Once authentication and authorization are solid, IGA addresses the second category of risk: privilege creep, orphaned accounts, and compliance gaps that accumulate over time. IGA can be partially compensated with scripts and manual processes while you mature; weak authentication has no equivalent compensating control.

What security risks does IGA address that IAM doesn't?

IGA specifically addresses long-term internal risk: entitlement accumulation as employees change roles (privilege creep), access that persists after employees leave (orphaned accounts), applications outside the SSO perimeter that aren't visible to the identity provider (shadow IT), and the compliance requirement for periodic documented access reviews. IAM enforces access that exists; IGA governs whether that access should exist.

What is privilege creep and how does IGA prevent it?

Privilege creep is the gradual accumulation of access entitlements as employees change roles, join projects, and are granted temporary access that never gets revoked. Over time, users end up with admin rights or application access from roles they held months or years ago. IGA prevents this through periodic access certification campaigns where managers review and attest to their team members' current access, automated deprovisioning when role changes occur, and Segregation of Duties enforcement that flags conflicting access combinations.