Key points
- IGA answers governance questions IAM doesn't: who approved this access, when was it last reviewed, does it violate SoD?
- Core capabilities: access requests, approvals, certifications/reviews, role lifecycle, policy enforcement, separation of duties.
- Modern IGA is converging with SaaS Access Governance and SSPM as SaaS sprawl overtakes legacy app sprawl.
- IGA is often the difference between passing and failing SOC 2, ISO 27001, SOX, and HIPAA audits.
- Cloud-native IGA (Lumos, Opal, ConductorOne, Veza, Zilla) competes with traditional suites (SailPoint, Saviynt, Omada).
What is IGA?
Identity Governance & Administration (IGA) is the layer of identity that asks **"who should have access to what, and how do we prove it?" while traditional IAM/SSO focuses on "how do we sign them in?"**
Concretely, an IGA platform handles:
- Access requests — self-service catalogs where employees ask for app or role access.
- Approval workflows — manager approval, role-owner approval, risk-based approval.
- Provisioning and deprovisioning — often via SCIM into downstream apps.
- Access reviews / certifications — periodic campaigns where managers re-confirm or revoke access.
- Role lifecycle — role mining, role definitions, role ownership.
- Policy enforcement — separation of duties, toxic combinations, birthright access on hire.
- Audit reporting — who has what, who approved it, when, why.
Why buyers care
IGA shows up on the roadmap when one of the following hits:
- An auditor asks for evidence of quarterly access reviews and you have a spreadsheet.
- Layoffs reveal that ex-employees still have access to SaaS apps because deprovisioning was manual.
- SOX, HIPAA, SOC 2, or ISO 27001 introduces a separation-of-duties requirement (the requester ≠ the approver ≠ the implementer).
- M&A activity multiplies the number of identity sources and apps overnight.
- The board asks "how much standing privileged access do we have?" and nobody can answer.
Traditional IGA vs modern IGA
Traditional IGA suites (SailPoint, Saviynt, Omada, IBM, Oracle) grew up around on-prem apps, ServiceNow integrations, and complex multi-year deployments. They are deep, configurable, and often very expensive.
Modern, cloud-native IGA (Lumos, Opal, ConductorOne, Veza, Zilla, ConductorOne) started from SaaS-first companies whose pain is access sprawl across hundreds of SaaS apps, not a single mainframe. They emphasize:
- Out-of-the-box SCIM and API integrations to common SaaS.
- Slack / Teams-native access requests.
- Continuous (vs annual) certifications.
- Visibility into effective access across cloud and SaaS, not just identity-source membership.
Most enterprises today need both — a traditional IGA for regulated systems and a modern layer for SaaS.
Common pitfalls
- Treating IGA as a tool problem. Without role ownership and a real access model, the best IGA platform produces nicely-formatted noise.
- Annual mega-reviews. Managers rubber-stamp 500-line reports. Continuous, risk-targeted reviews actually catch things.
- Birthright sprawl. "All engineers get production access on day one" is the kind of birthright that looks innocent until incident response.
How IGA relates to other categories
- SSO + MFA authenticate the user; IGA decides whether they should be able to authenticate to this app at all.
- SCIM is the plumbing IGA uses to actually create and remove accounts.
- PAM governs the small set of privileged accounts; IGA governs the standing access of everyone else.
- CIEM is the cloud-infrastructure cousin of IGA, focused on AWS/Azure/GCP entitlements.
FAQ
Do I need IGA if I have SSO and SCIM?
SSO + SCIM gives you the plumbing. IGA gives you the process on top — requests, approvals, reviews, audit trails. Once you're past ~200 employees or have any compliance obligation, you need both.
Is IGA the same as PAM?
No. PAM specifically governs privileged accounts (root, admin, break-glass) with vaulting, session recording, and just-in-time elevation. IGA governs the broader population of standing access.