How to Evaluate IAM and IGA Solutions Without Getting the Decision Wrong

Introduction

IAM software is evaluated on governance features: role modeling, access certifications, lifecycle workflows, policy engines. These features describe what the platform can define. They do not describe what it can enforce. One determines whether you pass a vendor demo. The other determines whether the same audit finding shows up again six months after deployment.

The distinction matters because IAM products have converged on the same feature set. Every serious IGA platform offers role modeling, certifications, and lifecycle management. Every identity provider with a governance add-on offers some version of the same. When every vendor checks the same boxes, the evaluation defaults to secondary factors: pricing, analyst rankings, which sales team ran the better demo. None of those factors predict whether the platform will change the access environment after it's deployed.

What separates top identity governance solutions from the ones that become expensive documentation systems is how governance decisions connect to the systems where access is actually provisioned, modified, and removed. That connection is invisible in a feature checklist because it depends on integration architecture, not feature presence.

A concrete example: two IGA tools both offer "automated lifecycle management." One triggers a workflow that sends a task to the IT team's ticketing system, where a human manually removes access from each application. The other triggers API calls to Okta, Google Workspace, and the target SaaS applications to deprovision the accounts directly. Both claim lifecycle automation. One actually automates it. The evaluation spreadsheet gives both the same checkmark.

Why Governance Decisions Don't Reach the Systems That Matter

Identity governance and administration tools are designed to answer the question "should this person have this access?" They define policies, approval chains, and review cycles. What they are not always designed to do is answer the follow-up question: "and did the access actually change?"

Most IGA software operates as a governance layer that sits above identity and access systems. It records decisions. It does not always execute them. An access review determines that a former contractor's Salesforce account should be deactivated. The IGA platform records that decision, generates a task, and routes it to the application owner. Whether that application owner actually deactivates the account within a reasonable timeframe depends on their workload, their attention to the task queue, and whether they have admin credentials to Salesforce. The governance decision was made. The access persists.

This shows up in three places consistently.

Provisioning after approval is the most visible. A manager approves an access request in the IGA platform. The provisioning action requires someone to open the Okta admin console, navigate to the right group, add the user, and update the ticket. In organizations with dozens of access requests per day, that manual step creates a backlog. New hires wait days for the tools they need because the governance system processed the approval instantly and the provisioning system (a person) works on a different schedule.

Deprovisioning on offboarding is where the problem becomes a security finding. IGA platforms trigger deprovisioning workflows when an employee exits, but the workflow is only as complete as the connector coverage. Applications outside the IGA platform's integration library require manual removal. SaaS tools provisioned through direct signup rather than SSO are invisible to the governance system entirely. The offboarding workflow completes in the IGA platform. Three accounts in unmanaged applications persist until someone notices or an auditor flags them.

Access modification on role changes is the least visible and most damaging. An employee transfers from engineering to product management. Their new role triggers provisioning for product tools. Their old role does not trigger deprovisioning of engineering tools, because the IGA platform's role model maps new access to new roles but does not map removal of old access unless someone built that logic explicitly. Most implementations skip this. Access accumulates.

What Integration Depth Actually Means

Every identity governance solution advertises a connector catalog. The number is always large. What the number does not tell you is whether those connectors read entitlements, write changes, or both.

A read-only connector imports data from a target application into the IGA platform. The platform can display who has access, include that data in certification campaigns, and flag anomalies. It cannot act on the results. When a reviewer revokes access during a certification, the IGA platform records the revocation and generates a fulfillment task. Someone carries out the task manually. The connector gave the platform visibility but not control.

A read-write connector imports data and provisions changes. When a reviewer revokes access, the platform sends an API call to the target application and deactivates the account. No manual step. No fulfillment task. The governance decision translates directly into an access change.

The ratio of read-only to read-write connectors in any given IGA tool determines how much of the access environment is actually governed versus merely observed. Enterprise IAM solutions with large connector libraries often have deep read-write coverage for a core set of infrastructure tools (Active Directory, Okta, Google Workspace, major SaaS platforms) and read-only or partial coverage for everything else. That "everything else" is usually where the ungoverned access lives, because it sits in applications the identity team does not directly manage.

Evaluators should ask a specific question for every application in their top 20 by user count: does the connector for this application support automated provisioning, deprovisioning, and entitlement changes? If the answer is no for more than a third of the list, the IGA platform will govern the center of the identity environment and miss the edges. The edges are where audit findings come from.

The Mover Problem as the Real Test of IAM Software

Joiner and leaver lifecycle events receive most of the attention in identity governance because they are clean signals. An HRIS record is created; provisioning fires. An HRIS record is terminated; deprovisioning fires. The input is unambiguous and the expected output is straightforward.

Mover events are fundamentally harder, and how an IAM solution handles them reveals more about real-world effectiveness than any other capability. A role change is not a clean signal. An employee moves from Sales to Customer Success. Their HRIS record updates. What should happen to their Salesforce permissions, their Gong access, their HubSpot seat, and their access to the sales team's Google Drive folder?

The correct answer depends on the specific organization's policies, and those policies are rarely defined at the entitlement level. Most organizations define access policies at the role level: "Customer Success gets these applications." Few define the inverse: "When leaving Sales, these specific permissions are removed." Without that inverse definition, the IAM product provisions the new role's access and leaves the old role's access in place.

IGA platforms that handle movers well require upfront investment in role modeling that maps not just what each role gets, but what each role loses on transition. That modeling work takes weeks or months and requires input from application owners who understand the entitlement structures of their systems. Most implementations defer this work. The result is an identity governance program that provisions correctly on hire, deprovisions correctly on exit, and lets access accumulate silently on every role change in between.

Evaluators should test mover scenarios during proof-of-concept, not just joiner and leaver flows. Ask the vendor to demonstrate what happens when a user changes departments in the HRIS. If the answer involves a manual review step or a fulfillment task routed to an admin, the platform has not solved the mover problem. It has documented it.

When Access Reviews Become Compliance Theater

Periodic access certifications are the most visible output of any IGA program. They are also the most frequently misunderstood. Reviews are a governance mechanism, not a security control. They detect access that should not exist. They do not prevent it from being granted in the first place.

The quality of an access review depends entirely on what information the reviewer receives. A manager reviewing their team's access sees a list of application names and a binary choice: approve or revoke. Without context about what permissions each application grants, what the user actually does with the access, or how their access compares to peers in the same role, the rational decision is always to approve. Revoking access that someone might need creates an immediate operational problem. Approving access that someone does not need creates no visible consequence until the next audit.

IGA solutions that produce useful certifications attach context to each review decision. Peer comparison data shows whether the access being reviewed is standard for the role or an outlier. Usage data shows whether the application has been accessed recently. Risk scores flag accounts with privileged or sensitive entitlements that warrant closer scrutiny. Without that context, access reviews are a quarterly exercise in approving everything, producing audit evidence without producing security outcomes.

The best IGA solutions are moving toward continuous access evaluation rather than periodic campaigns. Continuous models trigger reviews when access conditions change (a role change, a new entitlement, a period of inactivity) rather than on a fixed schedule. That shift produces fewer reviews with higher signal, which means reviewers make better decisions. But continuous models require deeper integration with identity and application systems, which returns to the same constraint: how well the governance layer connects to the systems it governs.

Where Access Automation Fits in the Identity Stack

The pattern across all of these failure modes is the same. Governance decisions are made in one system. Access changes happen in another. The space between them is filled by humans doing manual work in admin consoles. IAM solutions that document that space produce better audit reports. IAM solutions that eliminate it produce actual security outcomes.

A category of tools has emerged that focuses specifically on this execution layer. Rather than building a governance platform that also provisions, these tools build a provisioning and automation platform that enforces governance decisions at the point of request. The approach inverts the typical IGA architecture.

Where a traditional IGA platform starts with a role model and works down toward connectors, an execution-layer tool starts with the integration to the target system and works up toward policy. Access requests arrive through Slack or Teams. Predefined policies evaluate whether the request should be auto-approved, routed for approval, or blocked. On approval, the system provisions access through the target application's API. When the access period expires, the system revokes it automatically. The entire chain, from employee request to provisioning to scheduled revocation, runs without anyone opening an admin console.

This is not a replacement for enterprise IGA software in organizations that need fine-grained entitlement certification, role mining, or segregation-of-duties analysis. Those are governance functions that require the data model and analytical capabilities of a dedicated IGA platform. What execution-layer tools replace is the manual provisioning and deprovisioning work that persists in most identity environments regardless of what governance platform sits above it.

The two approaches are complementary. An IGA platform governs entitlements across the full application portfolio. An access automation platform executes the provisioning actions for the most common request types: application access, group membership changes, time-bound permissions, and offboarding workflows. Organizations that deploy both find that the IGA platform's certification campaigns produce fewer findings because the provisioning and deprovisioning work is actually being carried out rather than sitting in a task queue.

User provisioning automation is where most identity governance programs either succeed or stall. The policy layer can be as sophisticated as the IGA vendor's product team can build. If the provisioning layer depends on a human opening three browser tabs and copying data between them, the governance is decorative.

What Evaluators Should Ask That They Usually Don't

Most RFPs for identity governance solutions cover features, compliance certifications, and connector catalogs. They do not cover the operational questions that determine whether the platform works after deployment.

• For each of your top 10 applications by user count, can the platform provision and deprovision access without manual intervention? The answer will expose the real connector depth faster than a catalog count. Vendors will distinguish between applications where full lifecycle automation is supported and applications where fulfillment requires a manual task. If most of the top 10 fall in the second category, the platform will not materially change how provisioning works. User provisioning tools that cannot write changes to the systems your employees actually use produce governance without execution.

• What happens when an employee changes roles in the HRIS? Walk through the exact sequence from the HRIS event to the entitlement changes in two target applications. This question tests mover handling, which is the lifecycle event most IAM products handle poorly. Listen for whether the answer includes automatic removal of the previous role's access or whether it only covers provisioning the new role's access. If the vendor cannot demonstrate clean mover handling in a proof-of-concept, the access accumulation problem will persist after deployment.

• What percentage of access review decisions in your average customer environment result in revocation? Vendors who track this metric know whether their certifications produce real governance or rubber-stamp exercises. Industry benchmarks suggest that fewer than 5% of review decisions result in revocation. Platforms that consistently produce higher revocation rates typically offer better reviewer context (peer comparison, usage data, risk scoring). If the vendor does not track this metric, their certifications are not instrumented to improve over time.

• What is the actual cost to operate the platform in year two, including internal headcount? License fees are the smallest component of total cost for most IGA platforms. Professional services for implementation, connector customization, role model development, and the dedicated admin headcount required to maintain the platform post-deployment determine the real number. Access governance software that costs $300K in licensing but requires two full-time administrators and annual consulting engagements for role model updates costs over $700K annually. Evaluators who budget only for the license discover this after the contract is signed.

FAQ

What are IAM solutions?

IAM solutions are the platforms, tools, and systems used to manage digital identities and control who has access to what across an organization's applications and infrastructure. The category spans identity providers (Okta, Microsoft Entra ID), identity governance and administration platforms (SailPoint, Saviynt), and access automation tools that execute provisioning and deprovisioning workflows. Most organizations use multiple IAM products in combination because no single platform covers authentication, governance, and automated provisioning with equal depth.

What is the difference between IAM solutions and IGA solutions?

IAM is the broader category covering authentication, directory services, and access control. IGA is a subset focused on governance: how access decisions are made, reviewed, and enforced over time. An identity provider like Okta is an IAM product. An identity governance platform like SailPoint is an IGA product. Many IAM vendors now offer IGA capabilities as add-ons, which blurs the boundary. The practical distinction is that IAM controls who can authenticate and what they can access today, while IGA governs whether that access is appropriate over time through certifications, lifecycle management, and policy enforcement.

How do IGA platforms handle automated user provisioning?

IGA platforms handle provisioning through connectors to target applications. When a governance decision is made (an access request is approved, a lifecycle event triggers, or a certification results in a change), the platform sends provisioning instructions through its connector. Whether those instructions execute automatically depends on the connector type. Full-lifecycle connectors provision and deprovision accounts through API calls without manual intervention. Partial connectors create fulfillment tasks that require a human to complete the action manually. The ratio of full-lifecycle to partial connectors in a given IGA tool determines how much of the provisioning work is actually automated versus queued for manual execution.

What should small and mid-market teams look for in identity governance tools?

Mid-market teams evaluating identity governance tools should prioritize time-to-value and operational simplicity over feature depth. Enterprise IGA software (SailPoint, Saviynt) requires dedicated headcount and a multi-quarter implementation. Lighter IGA tools that focus on SaaS discovery, account-level access reviews, and basic provisioning automation deploy in weeks and do not require a systems integrator. The right starting point for most mid-market teams is a tool that answers "who has access to which applications" and automates the most common provisioning requests, rather than a full IGA platform that governs fine-grained entitlements across hundreds of systems.

Can user provisioning software work alongside a separate IGA platform?

Yes, and in most enterprise environments it should. An IGA platform governs the policy layer: which roles get which access, who approves exceptions, and when certifications run. User provisioning software and access automation tools execute the resulting changes in target systems. The two layers solve different problems. Governance without execution creates documentation. Execution without governance creates uncontrolled access. Organizations that deploy both typically see faster provisioning for common requests (because the automation handles them end-to-end) and better audit outcomes (because the governance platform's decisions are actually being enforced).