Most IGA programs govern only the 30-40% of applications their IdP can see. In this guide, we cover what identity governance and administration actually involves, when your organization needs it, and why visibility has to come before governance. Written for the IT and security teams who own the program, and the board, HR, finance, and compliance stakeholders who make it work.
Here is a question that sounds simple: who has access to your customer database?
At 200 employees, you can answer it in five minutes. At 1,200 employees, it becomes genuinely impossible. Your identity provider shows 89 users. Application logs show 203. Nobody can explain the other 114, and your last access review certified only the 89 your IdP could see.
That gap is what this guide is about. Most companies that implement IGA still can't answer basic questions about who has access to what, because they implemented governance before establishing visibility.
In this guide, we walk through what IGA is, when you need it, what breaks implementations, and how to sequence the whole thing so it actually works.
What Is Identity Governance and Administration?
The end goal of IGA is simple to state: the right users have the right level of access to the right tools at the right time, and you can prove it to auditors, regulators, and your board.
Every word in that sentence is doing work:
The Two Halves of IGA
IGA has two components that must work together, and most companies are decent at one and weak at the other.
Identity Governance is the "what should be." Defining who should have access to what, reviewing and certifying that access periodically, enforcing segregation of duties so no one holds fraud-enabling permission combinations, and producing the reports that prove compliance.
Identity Administration is the "making it happen." Creating accounts (provisioning), granting and modifying entitlements, revoking access when people leave or change roles, and automating the identity lifecycle end to end.
Most organizations run administration through their IAM/SSO tools, which works for the 20-40% of apps they have federated. Federating each app costs real money and effort, the SSO tax, so the rest never gets connected. And crucially, reviews and provisioning usually live in separate tools, a disparate rather than converged model, so the system that grants access and the system that questions it never talk to each other.
Your IdP typically sees 30-40% of the applications actually in use. The other 60-70% is shadow IT, and for AI tools the shadow share climbs to roughly 80%. Everything your IGA program does inherits this ceiling. You cannot review, revoke, or govern what you cannot see.
IGA vs IAM vs SSO vs PAM
Beginners hit these four acronyms in their first week, so here is the untangling. (The deeper cuts: IAM vs IGA on why passing logins isn't the same as proving access, and identity governance vs identity management on where the disciplines split.)
Privileged access management is trauma surgery: focused, intense, high-stakes. IGA is preventive medicine: continuous and foundational. You need both, and they are not interchangeable.
When Does Your Company Actually Need IGA?
The honest answer every IT and security leader eventually learns: earlier than you think. Here is how the pain curve typically runs.
The phasing for the 500+ crowd matters more than the tool choice. First 30 days: complete discovery, automate offboarding (the highest security risk), and stand up access requests with approval workflows to take pressure off the ticket queue. Next 60: automate onboarding for your top 20 apps or birthright apps, run reviews on critical systems. Next 90: expand everywhere. We've written up the full IGA implementation strategy phase by phase.
Why IGA Implementations Fail (And How to Avoid It)
The classic pattern: problems become unmanageable, leadership says fix it now, the team attempts complete IGA in one shot on a three-month timeline, and it fails. We've cataloged the top reasons IGA projects fail, and run the root cause analysis that traces most of them back to three early decisions. The short version:
IGA isn't just technology. You're changing how the whole organization handles access: how people request it, how managers approve it, how least privilege replaces "give everyone admin." Process and culture change take months even when the software takes weeks.
IGA has stakeholders far beyond IT and security. This is the part first-time buyers underestimate most, so it gets its own section below.
You need time to learn what works. Your first access review will reveal problems you didn't know existed. Start with one component and a bounded set of critical apps, get it working, then expand.
While tool implementation is 2-6 weeks on a modern platform (versus 6-12 months for legacy suites). Process maturity is 6-12 months regardless of tool, because you can't rush human adaptation. Vendors promising "full governance in six weeks" are quoting the first timeline and hoping you don't ask about the second.
The Stakeholder Map: Who Has to Be in the Room
IGA touches nearly every function, and departments never consulted during scoping become the departments that resist adoption later. Securing IGA buy-in before the RFP, not after go-live, is half the project.
Board/CEO provide sponsorship, risk appetite decisions, and the air cover that keeps cross-department participation real. HR owns the events that trigger everything: joiners, movers, leavers, and the HRMS integration that automates them. Finance holds license spend visibility, budget approval, and the cost case for the program itself. Compliance/GRCdefines evidence requirements and faces the auditors. Managers and app owners make the actual review and approval decisions; if they don't understand why, they'll approve everything to clear their inbox. We've laid out how to run stakeholder alignment for a visibility-first program in detail.
How IGA Actually Works: Three Phases
Phase 1, Discover. Build a complete application inventory using multiple discovery methods, not just SSO connectors: identity providers, finance systems, browser extensions, and more, cross-referenced. Then map who has access to each discovered app, at the entitlement level (admin vs read-only, not just "has Salesforce"), including dormant accounts, contractors, and service accounts.
Phase 2, Govern. Define the rules: your identity governance framework of access policies, approval workflows, SoD constraints, and compliance controls. Then verify them through periodic reviews where managers or app owners certify that access is still appropriate, with closed-loop remediation so a "revoke" decision actually revokes something. On the modeling side, pure roles are theoretically beautiful and practically difficult; companies either balloon to 300 roles nobody understands or go the other direction into 20 roles that over-grant. The escape hatch is context-based access control: grants driven by department, location, manager, and other attributes that update themselves.
Phase 3, Administer. Automate the lifecycle. HRMS says "new hire," accounts appear with day-one access. HRMS says "role change," old access goes and new access comes. HRMS says "terminated," everything revokes immediately, everywhere, including the apps IT didn't set up. Add a self-service app catalog on top and 30-40% of your ticket volume disappears.
The sequencing is the whole point. Governance built on an incomplete inventory is exactly why IGA implementations fail in SaaS-first environments: the policies and reviews are rigorous, and they cover the minority of what exists. This is also where identity governance meets SaaS management, because the sprawl problem and the governance problem are the same problem viewed from two departments.
The Three Generations of IGA
Why do tools that dominated the market struggle in modern environments? Because each generation baked in the assumptions of its era. We compare them fully in legacy vs next-gen IGA; the shape of it:
The first two generations share one dependency: if an app doesn't support SCIM provisioning or a pre-built connector, it's invisible to them. The enterprise suites (SailPoint, Saviynt, Omada and peers) serve Fortune-500 environments with dedicated identity teams well. But a 500-person company now faces the same compliance requirements and audit scrutiny as a 10,000-person enterprise, without the ten-person identity team or the consulting budget.
That mismatch is what next-gen platforms exist to close: discovery-first, deployed in weeks, run by the team you already have.
Our roundup of IGA solutions compares the field, our guide to evaluating IGA software covers how to validate discovery claims against your real environment before you sign, and for how the pieces fit together in practice, see inside Zluri's IGA platform.
Where IGA Fits in Modern Security
There is no network perimeter anymore. Apps are in the cloud, people work from anywhere, and identity determines access, not network location. That makes governance the operating layer of identity-first security: every access decision is now a security decision, and every forgotten grant is a vulnerability.
The zero trust principle, never trust, always verify, depends on IGA to function. Reviews provide the continuous verification. Policy-driven provisioning enforces least privilege from the first grant. SoD and rapid deprovisioning contain the blast radius when an account is compromised. IGA is one layer in a defense-in-depth model, and here's where it fits in a layered security approach alongside your other controls. And as AI agents multiply access patterns faster than any human process can track, we've laid out our full position in our manifesto on AI-first identity governance.
Measuring Whether It's Working
Three dimensions, and here's how to measure your IGA program in full:
Coverage. The metric that matters most: what percentage of your total applications have complete access visibility and governance? 90%+ on critical apps means you've succeeded. 30-40% means you've automated the visible portion while shadow IT carries the actual risk.
Automation. Provisioning and offboarding in hours not days, reviews completing in weeks not months, access tickets down by most of their volume.
Outcomes. Fewer incidents, cleaner audit opinions, less license waste. These roll up into the measurable value case that finance and the board actually fund.
Where to Start
If you take one thing from this guide, take the sequence: visibility first, then governance, then automation. Governing the 30-40% you can see while the rest operates in darkness isn't partial governance. It's a compliance and security risk with better documentation.
Start with discovery this quarter. Automate offboarding next, because lingering access from departed employees is the cheapest serious risk to eliminate. Then phase in reviews, policies, and lifecycle automation as the organization adapts. The tool takes weeks. The program takes months. Both are worth it, because identity is the perimeter now, and IGA is how you hold it.
Frequently Asked Questions
Is IGA the same as IAM?
No. IAM authenticates: it proves who you are and gets you into applications. IGA governs: it determines what access you should have, verifies it's still appropriate, and produces the evidence. Most organizations have IAM long before they have IGA, and the gap between the two is where access risk accumulates.
Do we still need IGA if we already have Okta or another SSO?
Yes, once you're past a few hundred employees. SSO makes logging in easier for the apps you've federated, but it can't discover the apps you haven't, review whether access is still appropriate, or control entitlements inside applications. SSO without governance just makes unneeded access more convenient.
How long does IGA take to implement?
Two different answers. The tool: 1-2 weeks on a modern platform, 6-12 months on legacy suites. The program: 6-12 months of process maturity regardless of tool, because managers, HR, finance, and app owners all need to adapt to new workflows. Plan for both timelines and don't let a vendor quote you only the first.
Who should own the IGA program?
A cross-functional owner or steering group, not a single department. IT and security typically run it day to day, but HR triggers the lifecycle events, compliance defines the evidence bar, finance funds it, and the board sponsors it. Programs scoped as one department's tool purchase are the ones that stall.
What should we automate first?
Offboarding. It's the highest-risk manual process (departed employees retaining access is a breach waiting to happen), it's unambiguous (termination should revoke everything), and it produces a visible win that builds momentum for the rest of the program.
.svg)
