Identity Governance and Administration (IGA) is the layer of identity management that decides what access exists, who approves changes to it, and how to prove it later. It sits on top of authentication (IAM) and covers provisioning, access certifications, access requests, audit trails, and policy enforcement across every system a user can touch.
A working IGA program answers four questions at any moment.
- Who has access to what?
- Why do they have it?
- Is it still appropriate?
- Can we prove the answer to an auditor?
If a company can't answer these without manually digging through admin panels and spreadsheets, the IGA layer is missing or broken.
What IGA includes
The components are well-defined, even if vendors emphasize them differently.
Provisioning and deprovisioning. Granting and revoking access across apps as people join, change roles, and leave. Covers human identities, contractors, and non-human identities (service accounts, API keys, AI agents).
Access requests. The flow that runs when someone needs access beyond their birthright bundle. Routing, approval, audit trail.
Access certifications (also called access reviews). Periodic or continuous review of who has what, with explicit approve-or-remove decisions per entitlement.
Policy enforcement. Role-based access control (RBAC), attribute-based policies (ABAC), separation of duties (SoD) rules, segregation between sensitive resource access.
Audit trail. A timestamped record of every grant, change, and revocation, mapped to the policy that authorized it.
Identity lifecycle. Joiner-mover-leaver (JML) flows triggered from the HRIS or another authoritative source.
How IGA differs from IAM and SSO
IAM (Identity and Access Management) is the broader category covering authentication, authorization, and access management. SSO (Single Sign-On) is a specific IAM capability: a user authenticates once and gains access to multiple systems through federated tokens.
IGA is the governance layer on top of IAM. SSO answers "can this person log in?" IGA answers "should they have this access in the first place, and how do we prove we made that decision deliberately?"
In practice, most companies have IAM and SSO running (Okta, Entra, Auth0, Google Workspace) and then face a separate decision about IGA. The two categories are increasingly bundled (Okta Identity Governance, Entra ID Governance), but the depth of governance varies significantly across products.
When a company needs dedicated IGA
The signal is usually one of these.
- 50+ employees with 30+ SaaS apps, and growing
- Compliance pressure (SOC 2, ISO 27001, HIPAA, NERC CIP, ITAR, FDA) with audit deadlines approaching
- A near-miss involving access: ex-employee with active credentials, contractor with persistent access, orphaned service account
- A board or customer questionnaire that asks about access governance specifically
- An IT manager who can't generate a current "who has access to X" report inside an hour
Before these signals, manual identity work (spreadsheet access reviews, Slack-based access requests, runbook offboarding) is usually sufficient. After, the manual approach starts to break, and the gaps accumulate into audit risk.
How IGA tools compare
Three categories often get confused.
Legacy enterprise IGA. SailPoint, Saviynt, Oracle Identity Governance. Built for 5,000+ employee organizations. Multi-month implementations, dedicated administrators, $300K+ entry pricing. Configuration-deep, slow to change.
Modern IGA, SCIM-first. Lumos, ConductorOne, Zluri, Opal. Designed for cloud-native SaaS stacks. Provisioning through SCIM where apps support it; ticket-based fallback for the rest. Faster to deploy than legacy. Coverage limited to SCIM-supported apps in practice.
Modern IGA, full-coverage. Iden. Built to govern SCIM apps, API-supported apps, browser-only admin panels, custom internal apps, and non-human identities. No SCIM-tier upgrade required. Designed for 50 to 2,000 employee companies.
The category gap between Okta's SSO and SailPoint's enterprise IGA is where most mid-market teams currently operate, often without realizing it. The IGA work is happening; it's just being done manually.
Common adjacent terms
Often used interchangeably with IGA or as components of it.
- Identity Lifecycle Management (ILM). Narrower: the joiner-mover-leaver portion of IGA.
- Access Management. Narrower: the runtime authorization layer.
- Identity Provisioning. Narrower: the create-and-modify-user portion.
- Access Certification. The periodic-review portion of IGA.
- Privileged Access Management (PAM). Adjacent: focused on elevated credentials specifically.
- Customer Identity and Access Management (CIAM). Adjacent: external-user-facing identity, distinct from workforce identity.
These are not synonyms. They're components, adjacent disciplines, or subsets.