The expensive mistake isn't staying on legacy IGA. It's spending a year migrating off it, landing on a "modern" platform that inherited legacy's biggest blind spot, and discovering you've paid for the upgrade without getting one.
A large share of organizations still run legacy IGA. The usual explanation is inertia: fear of migration downtime, sunk cost, "it isn't broken."
But there's a second, quieter reason the market is stuck, and it's the one this article is really about: buyers who did modernize and found that the new platform automated their old blind spots instead of removing them. Reviews got faster, but they still only covered the apps connected to the identity provider. Provisioning got automated, but only down to "create account, add to group."
This article covers that gap in two parts:
- Legacy versus modern: an honest, vendor-neutral comparison of what actually changed when the category moved to the cloud.
- Where we think modern still stops short, and what we've built at Zluri to go further. That second part is our position, not a neutral industry category, and we've tried to be explicit about the difference.
"Modern IGA" fixed deployment, integration, and cost. It didn't fix the two things that actually determine whether governance works: where the app inventory comes from, and how deep automation reaches. Judge any platform, ours included, on those two questions.
Legacy vs Modern IGA, At a Glance
The rest of this article is the substance behind that table: legacy's four failure patterns, what modern genuinely fixed, and the three gaps that survived the cloud migration.
Legacy IGA: Built for an Environment That No Longer Exists
Legacy IGA is first-generation governance software, installed and maintained on your own servers, either home-grown or an on-prem commercial product. It was designed for a world where the application count was fixed, everything lived in the data center, and identities changed slowly.
Every assumption in that sentence is now false, which is why the same four failure patterns show up in nearly every legacy deployment.
Integration is a coding project, not a configuration, and it makes you dependent on professional services to get there. Legacy platforms are built on proprietary technology, so connecting them to anything modern means custom development work, which in practice means bringing in the vendor's own consultants or an implementation partner rather than configuring it yourself. One customer put a number on it for us: a 1,000-employee company can expect to spend somewhere between $300,000 and $500,000 on implementation alone, most of it professional services fees, and the process takes years, not quarters. Every new SaaS app your teams adopt widens the gap between what the IGA system governs and what actually exists, and closing that gap means going back to the same consultants again.
Everything runs on manual effort. Legacy IGA predates automation as a design principle. IT chases app owners for access data, creates and revokes accounts by hand across systems, and reviewers validate access from exported spreadsheets. The consequences compound: slow provisioning, missed offboarding, human error in exactly the records auditors examine, and certification cycles that overshoot deadlines.
The cost never stops. Servers, backup systems, networking gear, patching, and the specialized staff or consultants needed to operate proprietary software. In Omada's survey, 60 percent of respondents said the total cost of ownership of their legacy IGA system is high. That's the majority of the installed base describing their own tool.
Security posture is reactive by design. Legacy systems investigate breaches once they've already happened, detect policy violations only in hindsight, and revoke access only once it's been misused. Modern security models (zero trust, least privilege, continuous verification) assume capabilities these platforms simply weren't built to have, and retrofitting them means modifying restricted or brittle source code, with real risk of breaking what still works.
A customer summarized the retrofit problem better than we could: legacy IGAs were built for on-prem and only later adapted to the cloud, and the cloud capabilities they offer are very basic.
It can't tell when two accounts belong to the same person. Most organizations authenticate through one tool, manage app access through another, and audit through a third, each storing identity data in its own format. Legacy IGA pulls from all three but doesn't reconcile them: a new hire recorded as "J. Rivera" in one system, "Jordan.Rivera" in another, and "JRivera" in a third shows up as three separate, unlinked users on the dashboard instead of one person.
The practical result is duplicate records, access reviews that can't be trusted because nobody's sure which record is authoritative, and IT manually piecing together a single person's actual footprint before they can even start deciding what to revoke.
Modern IGA: What It Genuinely Fixed
Modern IGA is the cloud-native rebuild of the category, and the improvements over legacy are real, not marketing.
- Integration became configuration. REST and SOAP APIs, SCIM, LDAP for directories, webhooks, and libraries of pre-built connectors replaced bespoke coding. Connecting a standard SaaS app went from a development project to a settings screen.
- Workflows became no-code. Provisioning rules, approval chains, and review campaigns moved from something an engineer scripted into the platform's backend to something an IT admin builds through a visual interface. Changing a policy went from a change request to a form.
- Automation replaced the spreadsheet economy. Account creation, access grants, mid-lifecycle changes, revocation at departure, and real-time access data collection for reviews all run as workflows. The gains are measurable: in Zluri's State of Access Reviews research, organizations on automated platforms cut review error rates by roughly 40 percent, brought review cycles down to about 4 days, and reduced the headcount managing reviews by around 30 percent.
- The cost model inverted. No data centers, no server patching, no specialist team just to keep the software alive. A subscription replaced capex, and non-technical admins replaced consultants for day-to-day operation.
- Proactive security became possible. Zero trust verification, least-privilege enforcement, and regular micro-certifications are native capabilities rather than aspirations.
So why isn't this article over? Because adoption tells you something: Zilla's 2025 State of IGA survey found only around 6 percent of organizations have deployed fully automated IGA. Part of that is migration inertia. But part of it is that buyers who looked closely at modern platforms found three recurring gaps.
Where Modern IGA Stops Short
The app inventory is inherited, not discovered. This is the big one, and it's the legacy blind spot that survived the cloud migration. Most modern IGA platforms build their picture of your environment from the identity provider's federated app list, plus whatever SCIM-compliant apps you connect. Everything outside that boundary, the unfederated tools, the team-purchased apps on a corporate card, the AI applications nobody registered, is invisible.
In most organizations that invisible portion is 60 to 70 percent of the actual footprint.
Governance that covers a third of your environment isn't a third as risky. The risk concentrates precisely in the ungoverned part, because that's where nobody is looking.
Automation is broad but shallow. Creating an account and adding a user to a group is automated; what happens inside the app often isn't. Many modern platforms can't run workflows on conditional logic, can't set variable-based triggers, can't customize approval paths per policy, and can't execute closed-loop remediation after a review flags something. The workflow finishes, and a human picks up the rest.
The pricing has trapdoors. Per-integration fees and paid add-on modules are common across the category, which means the total cost of ownership drifts upward as your stack grows, exactly the dynamic subscriptions were supposed to end.
None of this makes modern IGA a bad purchase. It makes "modern" an incomplete specification, and here's specifically what we think that specification is still missing.
How Zluri's Next-Gen IGA Differentiates From Modern
To be clear about what this section is: it's our case, not a third industry-recognized category everyone agrees on. "Next-gen" gets used loosely across the market, often as a label modern platforms apply to themselves without changing much underneath. What follows is specifically how we've built Zluri to go further than what modern IGA typically does, and why.
Zluri vs Modern IGA, At a Glance
The sections below cover each of these in depth.
If you only check one row before you go further, it's the offboarding coverage. Most modern IGA revokes access within RBAC roles and IdP-connected apps only, which excludes shadow IT from every offboarding by definition. That's the gap most worth pressure-testing in a demo.
Visibility-First, Not Governance-First
A next-gen platform doesn't limit its inventory to what the identity provider federates. Our discovery engine runs eight discovery methods and cross-references them into a single inventory:
- SSO and IdP
- HR systems
- Finance and expense tools
- Direct API integrations
- MDM
- CASBs
- Directories
- Optional browser and desktop agents
The IdP remains a first-class source, it's just one of eight lenses instead of the only one. That's how the inventory ends up including the unfederated apps, the non-SCIM apps, the shadow IT, and the non-human identities (service accounts, API keys, AI agents) a federation-derived list will never contain.
Governance then applies to the complete picture, not the declared one. It's also why "next-gen" isn't just "modern plus AI features": if the inventory stops at the IdP boundary, no amount of intelligence layered on top governs the apps that aren't in it.
Complete Access Governance on One Platform, So a Review Actually Fixes What Caused It
Modern IGA typically treats access reviews and access management as connected features, not a connected loop. Ours share one data model by design: Access Reviews, Access Management, and Segregation of Duties. For the full architecture, see inside Zluri's IGA platform.
That matters because of what happens after a review finds something:
- On most platforms: a reviewer flags an issue, it gets remediated as an isolated fix, revoke this grant, close this violation, and nothing prevents the same issue from recurring next cycle.
- On Zluri: a recurring finding traces back to the provisioning rule that keeps creating it, and the fix happens upstream. Correct the rule, and the issue stops generating new instances instead of getting cleaned up by hand every quarter.
You stop correcting the same problem again and again.
Movers Handled as a First-Class Scenario, Not an Afterthought
Most IGA, modern platforms included, is built around joiners and leavers: clean onboarding, clean offboarding. What happens in between, someone changing teams, taking on a new project, moving from IC to manager, is where access quietly accumulates, because mover workflows are often just onboarding run twice: adding new access without reliably removing the old.
Access Management and Access Requests work together specifically to close that gap:
- A role change triggers automated adjustment of what should be removed, not just what should be added.
- Net-new access requested mid-role routes through the same policy-based approval as anything else.
The mover scenario gets the same rigor as the join and the leave, instead of being the gap between two well-covered edges.
Granularity That Goes Into the App, Under Conditions You Define
Legacy and even modern platforms often default to department-based provisioning: everyone tagged "Engineering" gets the same bundle of tools, whether they're a developer who needs a CI/CD pipeline or a network engineer who needs infrastructure access neither role actually shares. That's faster to configure and a worse fit for least privilege, since sharing a department was never the same thing as sharing a job.
Our workflows run 1,500+ in-app actions across 300+ integrations, driven by actual role, usage, and risk rather than department membership:
- Add a user to specific Slack channels on day one
- Set their exact permission level inside an app
- Transfer file ownership to a manager before revoking access at offboarding
- Downgrade a license instead of deleting an account
Conditional playbooks and an automation rule engine sit on top, so policy executes itself: a new Workday record with department = marketing and type = employee triggers the marketing onboarding playbook automatically, with role-based and even context-based conditions (grant only if the user is in an approved region) enforced at grant time.
SaaS Management Included, Which Is What Makes the Governance Program Self-Funding
Modern IGA is priced and pitched as pure cost: governance value that's real but hypothetical to finance, breaches avoided, audits passed, nothing on the ledger.
Because SaaS management runs on the same platform:
- License reclamation, tier downgrades, and eliminated redundancy generate documented, attributable savings as a byproduct of the same access changes IGA is already making.
- Every revocation and downgrade comes with the evidence finance actually wants: cost versus spend, tied to the action that produced it.
That evidence is what lets the savings offset the cost of the program instead of the program competing against other budget lines on hope alone. More depth in why we kept SaaS management alongside our IGA.
Offboarding That Reaches Every App an Identity Actually Touched, Not Just the Ones You Defined Roles For
Most modern IGA revokes access by working backward from what it already knows: the apps tied to defined RBAC roles, or the apps connected to the IdP and SSO. That's a real gap dressed up as complete offboarding, because it only removes what the platform expected to find.
Shadow IT, by definition, was never in that expected set:
- A tool an employee signed up for directly
- A free-tier account
- A contractor's own login to something nobody provisioned
None of it appears on the RBAC list, so none of it gets touched when the person leaves. Zluri's visibility isn't bounded by roles or federation, it covers every app any identity has actually touched: paid or free, provisioned or self-signed-up, employee or contractor, human or non-human.
Offboarding reaches that whole footprint instead of the subset the platform happened to already know about. Same visibility-first foundation as the first point, applied at the moment it matters most: the day someone's access is supposed to end completely.
A Native iPaaS Engine Instead of One-to-One Integrations, Which Is a Reliability Difference, Not Just a Speed One
Most modern platforms build integrations the standard way: one connector, hand-coded, per application, each with its own logic for authentication, pagination, and error handling. That works until it doesn't, a connector breaks when a vendor changes their API, and fixing it means an engineer revisiting that one integration's code in isolation.
Our integrations are declared as schemas against one shared iPaaS engine instead:
- Authentication, rate limiting, retries, and error handling are solved once and apply everywhere.
- When the engine gets better at handling a rate limit, every integration benefits at once, not just the one someone happened to patch.
The practical difference shows up in month eight, not the demo. A sync that silently drops records on a one-to-one integration means your next access review runs on data nobody knew was wrong. A schema-based engine verifies it pulled what it expected to pull and surfaces the gap before it becomes a bad review or a missed audit finding.
Two more traits follow from all of this. Integration coverage reaches beyond standard frameworks too, with SDKs for custom connections covering legacy systems, apps without public APIs, and generative AI tools in weeks rather than months. And our pricing is all-inclusive, because a platform whose premise is complete coverage can't credibly charge you per integration to achieve it.
Which One Are You Actually Buying? Three Questions That Cut Through the Label
Vendor decks all say "modern" or "next-gen," ours included. Don't take the label on faith from anyone, us covered. Ask these instead:
- "Show me the apps you found that my identity provider doesn't know about." Run this against your real environment in a proof of concept. A platform that inherits its inventory will show you a governed version of the list you already had. A discovery-first platform will show you apps you didn't know existed. The difference is visible in the first week.
- "Walk me through offboarding a user who has apps outside SSO." If the honest answer is "we disable the IdP account and the rest is manual," you're looking at modern IGA with a next-gen label, and the gap will be yours to staff.
- "What does this cost at twice my current app count?" Per-integration fees and add-on modules mean the quote you're evaluating is the floor, not the price. Get the two-year TCO in writing against a realistic growth assumption.
These three sit inside a longer evaluation discipline, our full guide to choosing IGA software covers the rest of it, from environment mapping through contract pressure-testing.
Frequently Asked Questions
What is legacy IGA?
Legacy IGA is first-generation identity governance software installed and maintained on an organization's own servers, either built in-house or purchased as an on-premises commercial product. It relies on proprietary technology, requires manual effort across most governance tasks, and was designed for static environments with a fixed set of applications and slow-changing identities.
What's the difference between modern and next-gen IGA?
"Next-gen" isn't a standardized industry category the way "cloud-native" is, it's a label vendors apply to themselves, us included, so treat any vendor's claim to it as something to verify rather than take on faith. What we mean by it at Zluri comes down to two differences from typical modern platforms: where the application inventory comes from (modern platforms generally inherit it from the identity provider's federated app list; we discover it independently, including unfederated and shadow apps) and automation depth (modern platforms typically automate lifecycle basics like account creation and group assignment; we execute granular in-app actions, conditional playbooks, and closed-loop remediation). Ask any vendor using the term to show you both, specifically.
Is cloud-based IGA automatically "next-gen"?
No. Cloud hosting is necessary but not sufficient, and it's also not what separates legacy from modern in any meaningful sense beyond deployment. A cloud platform that builds its app inventory from your IdP and automates only account-level actions is modern IGA by our definition, whatever the marketing calls it. What we mean by next-gen is defined by independent discovery and granular automation, not by where the software runs, and that's a claim worth testing against a vendor's actual product, not their homepage.
How long does it take to migrate from legacy IGA?
The platform side has compressed dramatically: modern and next-gen deployments connect standard integrations in weeks, versus the months-to-years implementations typical of legacy tools. The organizational side, redesigning access policies, retraining reviewers, and running your first certification cycles on the new platform, typically plays out over one to two quarters. Budget the full arc, not just the technical cutover.
Why do so few organizations have fully automated IGA?
Zilla's 2025 survey put fully automated deployments at roughly 6 percent. Migration inertia explains part of it, but so does experience: organizations that modernized onto platforms with inherited inventories and shallow automation found significant manual work remaining, which slows the willingness to invest further. The gap between "we bought an IGA platform" and "our governance is automated" is usually coverage and granularity, not the absence of a tool.
.svg)
