Walk into any vendor conversation in this space and you'll hear "IAM" and "IGA" used as if they're synonyms. They aren't. They sit next to each other in the org chart of identity work, but they answer different questions, use different tools, and break in different ways.
The confusion costs companies time. Teams buy IAM when they actually need IGA. Teams scope IGA inside the IAM project and discover the gap eighteen months later. Vendors blur the line because the bundling story is cleaner.
This piece is the plain distinction. What each one is, what each does, where they overlap, and how to tell which problem your company is hitting.
The definitions
Identity and Access Management (IAM). The broader category that covers authentication, authorization, and access management at runtime. IAM answers: "can this person prove who they are, and what can they currently do?" Auth0, Okta Workforce Identity, Microsoft Entra ID, Google Workspace, Ping Identity, and similar tools are IAM platforms.
Identity Governance and Administration (IGA). The discipline of deciding what access should exist, who approves it, and how to prove it later. IGA answers a different set of questions: "should this person have this access? When did we grant it? Who approved it? Is it still appropriate?" SailPoint, Saviynt, Lumos, ConductorOne, Iden, and similar tools are IGA platforms.
IAM is the runtime layer. IGA is the governance layer. They run on top of each other.
What IAM does
The IAM stack covers four functional areas.
Authentication. Verifying who someone is. Username and password, MFA, biometrics, social login, federated identity from another IdP. The IAM platform issues a token (SAML assertion, OIDC ID token, OAuth access token) that downstream apps trust.
Single Sign-On (SSO). The user authenticates once with the IAM platform and gains access to multiple downstream apps through federated tokens. SSO is a feature of an IAM platform, not a separate category.
Authorization at runtime. Once authenticated, the user's request to access a specific resource gets evaluated against policy. Most IAM platforms handle coarse-grained authorization (group memberships, claims-based access). Fine-grained authorization is usually delegated to the application itself or to a dedicated policy engine.
Directory. The IAM platform maintains a directory of users, groups, and the relationships between them. The directory is the system of record for "who exists" from an authentication perspective.
What IAM is good at: making sure the right person is on the other end of the request. The "who are you" question.
What IGA does
The IGA stack covers a different set of functional areas.
Provisioning. Granting access to specific systems based on roles, attributes, or explicit requests. Includes deprovisioning when someone leaves or changes roles.
Access certification. Periodic or continuous review of who has what access, with explicit approve-or-remove decisions per entitlement.
Access requests. The flow that handles "I need access to X" when the access isn't already part of the user's role bundle. Routing, approval, audit trail.
Policy enforcement. Role-based access control (RBAC), attribute-based access control (ABAC), separation of duties (SoD) rules.
Audit trail. A timestamped record of every grant, modification, and revocation, mapped to the policy or human approval that authorized it.
Lifecycle. Joiner-mover-leaver workflows triggered from an authoritative source, typically the HRIS.
What IGA is good at: making sure the right access exists, and that someone deliberately decided it should. The "should this access exist" question.
Where the line is
The line between IAM and IGA is the difference between runtime and lifecycle.
IAM is concerned with what's happening right now. A user is logging in. A request is hitting an API. A session is active.
IGA is concerned with what should be set up so the runtime layer behaves correctly. Roles have been mapped to permissions. Reviewers have approved access. Stale grants have been removed.
A useful test: if the answer to a question changes by the second, it's IAM. If the answer should be stable for days or months, it's IGA.
"Is this user logged in?" Runtime question. IAM.
"Should this user have admin on the staging database?" Lifecycle question. IGA.
"Is the request authorized?" Runtime. IAM.
"When was that authorization granted, and by whom?" Lifecycle. IGA.
Why teams confuse them
A few reasons the confusion is so common.
The vendor messaging. Both IAM and IGA platforms claim adjacent capabilities. Okta has Okta Identity Governance. SailPoint markets some IAM features. Microsoft has Entra ID Governance bundled with Entra ID itself. The taxonomy line is real; the marketing line is fuzzier.
The historical sequence. Most companies buy IAM first (SSO is more visibly urgent), then discover the IGA gap when the SSO doesn't handle the governance work. Because IGA shows up second in the timeline, it sometimes feels like an extension of IAM rather than a separate discipline.
The directory overlap. The IAM platform maintains a directory of users for authentication. The IGA platform consumes that directory to drive its lifecycle. From the outside, "the system that has the users" sounds like one system. It's two systems doing different work on the same data.
The terminology drift. "Identity management" gets used as a generic term for both. "Lifecycle management" gets used by both IAM and IGA vendors. The shared vocabulary papers over the functional difference.
Vendor map
A quick map of who plays where in the current market.
Pure IAM, SSO-first. Auth0, Okta Workforce Identity, Microsoft Entra ID, Google Cloud Identity, JumpCloud (directory side), Ping Identity. Federation, SSO, MFA. Some basic lifecycle for SCIM-supported apps.
Pure IGA, legacy enterprise. SailPoint, Saviynt, Oracle Identity Governance. Long implementations, high cost, deep configuration. Built for 5,000+ employee organizations.
Pure IGA, modern. Lumos, ConductorOne, Zluri, Opal, Iden. SaaS-native, faster to deploy. Differences across this set: SCIM-first vs full-coverage, depth of certifications, contractor and NHI handling.
IAM with IGA add-on. Okta + Okta IGA, Microsoft Entra + Entra ID Governance. Bundled with the SSO. Coverage limited to what the SSO can reach via SCIM. Useful for teams already invested in the IAM platform.
PAM-first, IGA-adjacent. CyberArk, BeyondTrust. Specialize in privileged access management with some IGA-like features layered in.
SaaS management with IGA leanings. Productiv, Torii, BetterCloud. Started as SaaS visibility tools; some added IGA capabilities. Coverage varies.
What you actually need
The question that matters: which gap are you hitting?
If users are sharing passwords, logging into apps individually, or you have no MFA enforcement, the gap is IAM. Fix authentication first.
If users have SSO but no one knows who has access to what, offboarding takes a week, and access reviews are a spreadsheet exercise, the gap is IGA. The IAM is doing its job. The governance layer is missing.
If both are gaps, fix IAM first. The IGA layer needs IAM in place to function: the IGA tool reads from the IdP, integrates with the directory, uses SSO for authentication. Building IGA on top of broken authentication doesn't work.
For most mid-market companies (50 to 2,000 employees), the typical sequence is:
- Buy SSO (Okta, Entra, Google Workspace).
- Operate manually for 6 to 18 months.
- Hit the IGA wall (compliance event, near-miss, growth threshold).
- Add an IGA layer.
The deferral is rational, but the right tool for step 4 should be chosen knowing it's a separate decision from step 1.
Where Iden fits
Iden is in the IGA category specifically. It plugs into whatever IAM platform you already have (Okta, Entra, Google Workspace, mix). It doesn't try to be your IdP. It's the governance layer that sits on top of the IdP and handles the work the IdP wasn't built for.
If you're trying to figure out whether you need IAM or IGA, the distinction in this piece is the answer. If you're trying to figure out whether you need Okta IGA, Lumos, ConductorOne, or Iden, the choice depends on your stack's non-SCIM coverage needs, your contractor and NHI requirements, and your compliance pipeline. Those decisions are downstream of the IAM-vs-IGA distinction itself.