Identity Governance and Administration (IGA) is the security and compliance framework that manages what happens to user access after authentication. While your identity provider verifies who a user is and controls whether they can log in, IGA governs whether their access is still appropriate, whether it was granted through a documented process, and whether it's being used in ways consistent with organizational policy.

The distinction matters in practice: an identity provider doesn't know that an employee who moved from Finance to Engineering three months ago still has Salesforce admin access. It doesn't know that a contractor account from a project that ended last year is still active. It doesn't know that no one has verified whether the sales team's access to customer data is still appropriate since the last audit. IGA is the framework that answers those questions continuously rather than discovering the answers during an annual audit.

IGA vs. IAM: The Practical Difference

IAM (Identity and Access Management) operates at the moment of access — it makes real-time decisions about authentication and authorization. When a user tries to log in, IAM verifies their identity, checks their credentials, enforces MFA, and grants or denies the session. IAM is the operational layer.

IGA operates on a longer time horizon and answers governance questions rather than authentication questions. It's concerned with the lifecycle of access: how it was requested, who approved it, whether it's still appropriate for the user's current role, and what happens when the user leaves. IGA is the governance layer.

A useful frame: IAM is the front door control. IGA is the ongoing audit of who has keys, whether they still need them, and whether they're using them appropriately.

The two layers are complementary. IAM enforces the access that exists; IGA governs whether what exists should exist. Organizations that invest in IAM without IGA typically discover the gaps during compliance audits — orphaned accounts, over-privileged users, and access that accumulated through role changes without a corresponding cleanup.

Core Capabilities of an IGA Platform

Identity Lifecycle Management (Joiners, Movers, Leavers)

The JML lifecycle covers three identity events that occur continuously in every organization:

Joiners — new employees who need access provisioned. IGA automates this by connecting to the HRMS as the authoritative source of truth. When HR adds a new employee, the IGA platform detects the event and runs an onboarding workflow that provisions the appropriate access based on the employee's role and department — without requiring a manual IT ticket for each application.

Movers — employees changing roles or departments. This is where access accumulation happens. Without automation, an employee who moves from Sales to Engineering gets their new Engineering access provisioned, but their Sales-specific access is rarely removed at the same time. IGA mover workflows run both sides of the transition simultaneously: deprovisioning old role access and provisioning new role access in the same automated run.

Leavers — employees departing the organization. IGA offboarding playbooks systematically revoke access across every application the departing user had access to — not just the applications connected to SSO, but the full access footprint including shadow IT and non-SSO tools discovered through the platform's discovery layer.

Access Requests and Approvals

Rather than routing access requests through IT queues or email chains, IGA platforms provide a structured self-service model. Employees browse an approved application catalog, request the access or license tier they need, and the request routes automatically to the designated approver — their manager, the application owner, or a compliance team member depending on the application's risk classification.

Once approved, the IGA platform provisions the access automatically for connected applications or generates a tracked task for manual fulfillment when automation isn't possible. The approval chain, the timestamp, and the provisioning action are all logged for audit purposes.

Access Reviews and Certifications

Access certifications are periodic audits where managers or application owners verify that their team members' current access is still appropriate. IGA platforms automate the campaign scheduling, surface risk signals to help reviewers make informed decisions (inactive accounts, unusual privilege levels relative to peers, accounts from users who have changed roles), and capture the approve/revoke/modify decision with a mandatory justification.

The output is a timestamped, non-editable compliance report that documents who reviewed what, what decisions were made, and when access was revoked. This is the evidence format required for SOC 2, ISO 27001, HIPAA, and SOX access review controls.

Role and Entitlement Management

Role-based access control (RBAC) assigns access based on job function rather than by individual. IGA platforms support the definition and management of these roles — mapping job titles and departments to the specific applications, license tiers, and permission levels appropriate for each function.

Role mining is the more advanced capability: analyzing actual usage patterns across the organization to identify where the assigned roles match actual usage and where they don't. This surfaces over-provisioned roles (users have access to applications they never use), under-provisioned roles (users frequently request access that their role doesn't include), and privilege accumulation patterns.

Segregation of Duties (SoD)

SoD controls prevent one person from holding access rights that would allow them to initiate and complete a transaction without oversight — the person who can request payment shouldn't also be the person who approves it, and the person who can create a vendor record shouldn't also be able to process payments to that vendor.

IGA platforms enforce SoD by defining conflicting access combinations and preventing them from being granted to the same user. For organizations subject to SOX, SoD controls are a specific audit requirement rather than an optional governance enhancement.

Policy Administration

Beyond SoD, IGA platforms enforce broader access policies: applications classified as restricted require additional approval tiers, external contractors cannot hold admin roles in production systems, access to certain data categories requires documented business justification. These policies are enforced at provisioning time rather than discovered during audits.

Why Organizations Implement IGA

Regulatory compliance. SOC 2, ISO 27001, HIPAA, and SOX each have access management control requirements that IGA directly addresses: periodic access reviews with documented evidence, access removal upon termination, Segregation of Duties enforcement, and audit trails for access grants and revocations. Organizations that lack IGA typically satisfy these requirements through manual processes — which work once and fail to produce consistent evidence across audit cycles.

Security risk reduction. Privilege creep — the accumulation of access beyond what a user's current role requires — is a real attack surface. An attacker who compromises a long-tenured employee's credentials often gains access to applications from roles that employee held years ago. IGA reduces this surface through periodic certifications that remove accumulated entitlements and mover workflows that clean up role transitions rather than only provisioning new access.

Operational efficiency. Manual IT provisioning is a bottleneck that scales linearly with headcount. IGA automates the repeatable work — standard onboarding for each role, routine access requests, scheduled deprovisioning — so IT time is spent on exceptions and governance rather than manual ticket execution.

The Three Questions IGA Answers

The clearest way to understand what IGA does is through the three governance questions it's designed to answer continuously:

Who has access to what? This requires discovery — not just what was formally provisioned through IT, but what applications users actually have access to, including tools adopted outside the formal IT process. The answer is the complete access inventory that makes governance possible.

Should they have that access based on policy? This requires evaluating current access against current role, current employment status, and organizational access policies. A terminated employee with an active account is a policy violation. An employee in a standard user role with admin privileges is a policy violation. Access review certifications are the mechanism for continuously answering this question.

What are they doing with that access? This is the emerging frontier of IGA, moving toward integration with activity monitoring and ISPM (Identity Security Posture Management) to understand not just whether access is appropriate but whether it's being used in ways consistent with expected behavior.

Frequently Asked Questions

What is the difference between IAM and IGA?

IAM handles real-time authentication and authorization — who can log in and what they can access at the moment of login. IGA governs the lifecycle of access over time — how it was requested, whether it was approved through the right process, whether it's still appropriate for the user's current role, and what happens when the user leaves. IAM is the front door control; IGA is the ongoing audit of who holds access and whether they should.

What are access certifications in IGA?

Access certifications (also called access reviews) are periodic audits where designated reviewers — typically managers or application owners — verify that their team members' current access is still appropriate. IGA platforms automate campaign scheduling, surface risk signals to inform reviewer decisions, capture decisions with mandatory justification, and generate timestamped compliance reports. These reports are the primary evidence artifact for SOC 2, ISO 27001, and similar compliance frameworks.

What is the JML lifecycle in identity governance?

Joiner-Mover-Leaver (JML) describes the three core identity lifecycle events: a new employee joining (provisioning), an existing employee changing roles (access adjustment), and an employee leaving (deprovisioning). IGA platforms automate all three from a single HRMS source of truth, ensuring access is provisioned correctly on day one, adjusted accurately during role transitions, and completely revoked when employment ends.

What is Segregation of Duties in IGA?

Segregation of Duties (SoD) controls prevent one person from holding conflicting access rights that would allow them to complete a sensitive transaction without oversight. A classic SoD violation is a user who can both initiate and approve financial transactions. IGA platforms define which access combinations are conflicting and enforce the policy at provisioning time, preventing violations rather than detecting them after the fact.