Most organizations didn't choose to run IGA on four separate tools, it happened one purchase at a time. And most "converged" platforms didn't converge everything either. In this piece, we break down what disparate and converged actually mean, what fragmentation costs, and the four specific types of convergence that decide whether a platform closes the gaps or just rebundles them.
Most organizations don't choose a disparate identity governance and administration (IGA) model on purpose. It's what happens when lifecycle management, access reviews, and segregation of duties (SoD) get bought separately, by different teams, at different times, and nobody goes back to unify them.
In short: disparate IGA means separate point solutions for provisioning, reviews, SoD, and discovery, each with its own data, its own login, and its own partial view of identity. Converged IGA means one platform, one identity data model, and one place every governance function draws from.
But here's the part most comparisons skip: convergence isn't one thing. A platform can genuinely unify reviews and SoD on one data model and still be blind to shadow IT, still route movers through a manual ticket, and still leave review decisions sitting in a queue nobody executes.
"Converged" tells you the governance functions share a data model. It doesn't tell you which functions were converged, and the ones vendors leave out are usually the ones that were causing the pain.
So the useful question isn't "disparate or converged?" It's "converged where?" There are four types of convergence that determine whether the model actually works:
- Discovery converged with governance, so the platform governs everything that exists, not just what's routed through SSO
- Access requests converged with lifecycle management, so movers stop being a ticket that grants new access without revoking the old
- Access reviews converged with provisioning and deprovisioning, so a "revoke" decision executes instead of becoming another ticket
- IGA converged with SaaS management, so the same data that powers governance also powers license and spend visibility
The rest of this piece walks through the disparate model, what basic convergence fixes, and then each of the four types in turn.
What "Disparate" IGA Actually Means
A disparate IGA model is what you get when governance functions are handled by separate, independently chosen tools rather than one unified platform. Lifecycle management might run through one system, access reviews through a spreadsheet or a dedicated review tool, SoD checks through yet another, and discovery of what's actually in use might not be owned by any tool at all.
Each piece does its job reasonably well in isolation. None of them share a common, up-to-date picture of identity.
Almost nobody sets out to build this deliberately. It's usually the result of buying decisions made at different times, by different teams, to solve immediate problems:
- An access review tool purchased ahead of an audit deadline
- A provisioning tool adopted when HR integration became painful enough
- An SoD point solution brought in after a specific finding
Each purchase made sense in isolation. The accumulation is what creates the fragmentation.
The Costs of Staying Disparate
Identity data doesn't reconcile across tools. The same person can look different in each system, a formatting difference, a stale HR sync, a manually entered account, and nothing forces those records to match up. Getting an accurate answer to "what does this person actually have access to" means checking multiple systems and manually cross-referencing what each one says.
Policy enforcement is inconsistent by design. A least-privilege rule enforced in your provisioning tool has no way of knowing what your SoD tool considers a toxic combination, because the two were never designed to share that logic. Conflicts that should be caught automatically slip through the gap between systems instead.
Reviews take longer and catch less. A reviewer working through access certifications often has to pull context from two or three different places to make an informed decision, since the review tool itself frequently only shows what it was told, not what's actually true across every connected system. That's exactly the kind of context-poor approval that turns a review into a rubber stamp.
Audit prep becomes a reconciliation project. Producing a clean, defensible answer to "who had access to what, and when" means exporting data from every tool in the stack and manually stitching it into something coherent, every single audit cycle, rather than pulling one accurate report.
Total cost of ownership is higher than the sum of the licenses. Beyond the direct cost of running multiple platforms, there's the integration work to connect them, the internal expertise needed to operate each one, and the ongoing reconciliation labor none of the individual tools were priced to include.
What "Converged" IGA Actually Means
A converged IGA model runs discovery, lifecycle management, access reviews, SoD, and access requests on one platform, against one identity data model. Every function draws from the same real-time picture of who exists, what they have access to, and how that access was granted, rather than each tool maintaining its own partial version of the truth.
That single data model is what makes the rest of convergence possible. SoD checks can evaluate access across every connected system, not just the ones a given point tool happens to see. Reviews surface complete context automatically instead of requiring a reviewer to go find it.
Offboarding is the clearest example. A departing employee's access gets revoked everywhere at once, because there's one identity record driving every connected system, not several disconnected ones each waiting on a separate manual step.
Disparate vs Converged IGA, Side by Side
That's the baseline case for convergence. But it's only the baseline, because "one data model for governance functions" still leaves the four questions below open, and different platforms answer them very differently.
The Four Types of Convergence, and Why Most Platforms Only Deliver Some
Type 1: Discovery Converged With Governance
Even a genuinely converged platform, one running lifecycle, reviews, and SoD on a single data model, can still be governance-first: you tell it which apps to govern, typically by connecting your IdP or SSO, and it manages access for whatever you've pointed it at.
Anything outside that scope simply doesn't exist to the platform, apps never routed through SSO, shadow IT, tools individual teams adopted directly.
That gap survives convergence. A platform that only sees what your IdP tells it to see still leaves you needing a separate SaaS discovery tool to find everything else, which quietly recreates the disparate model this whole comparison is trying to get away from: governance functions unified, discovery still a separate purchase.
Zluri's convergence starts from the opposite direction. Rather than governance-first with discovery added on top, it's visibility-first: the discovery engine, eight methods covering SSO and IdPs, direct integrations, HRMS, MDM, finance systems, CASBs, directories, and browser extensions, builds the identity and app inventory first, and governance runs on that complete picture rather than whatever subset happened to be connected through SSO.
Type 2: Access Requests Converged With Lifecycle Management
Most lifecycle management automates the two easy events and leaves the hard one to a ticket queue. Onboarding and offboarding are the events platforms handle well, because the trigger is clear (an HRMS entry, a termination date) and the end state is unambiguous: give them the standard kit, or give them nothing.
Movers are where that automation quietly stops. A role change, a department transfer, a promotion, none of these have a fixed answer for "what access should this person have now" the way onboarding and offboarding do.
In practice, most mover scenarios get handled the way ungoverned access always gets handled: someone opens a ticket requesting access for the new role, an admin grants it manually, and nobody circles back to revoke what the old role no longer needs. The person ends up with the new access plus all the old access, indefinitely.
That's the standing-access problem happening inside a platform that calls itself converged, because access requests aren't actually connected to lifecycle management. Requests get logged and fulfilled as isolated tickets. They don't feed back into a role's defined entitlement set, and the lifecycle event, the transfer itself, doesn't automatically trigger a review of the access that transfer should have removed. For the full picture of why movers specifically fall through, see joiners, movers, and leavers as a complete lifecycle problem.
Real convergence here means access requests and lifecycle management run on the same trigger logic, not just the same data model. A department transfer detected via HRMS should drive both directions automatically: provision the new role's access and flag or revoke the old role's access that no longer applies, in the same workflow.
Type 3: Access Reviews Converged With Provisioning and Deprovisioning
Here's a convergence gap that hides in plain sight: what happens after a reviewer clicks "revoke"?
In a disparate model, and in plenty of nominally converged ones, the answer is: a ticket. The review tool records the decision, exports a list of revocations, and someone in IT works through them manually across each app's admin console. The review and the deprovisioning are separate systems, so the decision and the execution are separate events, sometimes separated by weeks.
That gap is where review programs quietly fail. The certification gets completed on time, the audit evidence shows decisions were made, and the risky access stays live because execution depended on a queue nobody was measuring. Auditors are increasingly wise to this too: a completed review with unexecuted revocations is a finding, not a pass.
Reviews converged with provisioning treats reviews and management as two wings of access governance that only work as one system: the review decision is the deprovisioning action. The reviewer clicks revoke, and the same platform that runs the review executes the removal through its integration with the app, then records the completed change in the same audit trail. No export, no ticket, no second system, no gap between deciding and doing.
A review program should be measured on revocations completed, not certifications submitted. Convergence between reviews and provisioning is what makes those the same number.
This also runs in the other direction: because reviews and JML automation share one data model, review scopes stay accurate automatically. A leaver processed through offboarding drops out of the next review cycle on their own, instead of showing up as a stale row a reviewer has to puzzle over.
Type 4: IGA Converged With SaaS Management
Most converged IGA platforms stop at governance functions. Zluri converges further, running IGA on the same platform as SaaS management: application portfolio visibility, license usage, and spend, drawing on the same identity and app data that already powers discovery, reviews, and lifecycle.
Security and IT rarely touch the SaaS management side directly for governance decisions, but that doesn't make it dead weight in the platform. Finance teams, who are rarely part of an IGA buying conversation at all, end up genuinely valuing the platform for the license spend visibility and savings it surfaces.
That relationship matters more than it might seem for how sustainable an IGA program actually is. A platform finance can point to concrete savings from is one finance has a reason to defend, not just tolerate, when budget and renewal conversations come up.
The data overlap is also real, not just a packaging convenience. An unused license and an unused entitlement are the same fact seen from two angles: one is wasted spend, the other is unnecessary standing access. A platform that sees both can act on both from one dataset.
We've covered this specific comparison in far more depth, what each discipline answers, where the seam breaks when they're separate, and the actual dollar cost of running them apart, in identity governance vs SaaS management and why IGA is incomplete without SaaS management.
The Quick Test: Which Types Does a "Converged" Platform Actually Have?
When a vendor says "converged," these four questions sort out what they mean:
A platform can miss one of these and still be worth buying, depending on where your pain actually is. But you should know which types you're getting before you sign, because the missing type is the one you'll be filling with a point tool, a ticket queue, or manual labor, which is the disparate model sneaking back in through the side door.
Is Converged Always the Right Answer?
Not automatically. It's worth being honest about the tradeoffs rather than treating convergence as a universal fix.
Organizations with deep, specialized investment in a best-of-breed tool for one specific function, a mature PAM platform, for instance, may reasonably keep that tool rather than replace it, particularly if it's solving a narrow problem exceptionally well. Convergence is most valuable where fragmentation is actively causing the costs above, not as a reason to rip out something that's already working.
Migration itself carries real costs too. Moving from several disparate tools to one converged platform means data migration, workflow redesign, and a transition period where teams are learning a new system, which is a legitimate reason some organizations delay even when they recognize the disparate model isn't serving them well.
Enterprise vs Mid-Market: The Calculus Changes by Size
Company size changes this decision more than almost any other factor. The complexity that justifies staying disparate in a large enterprise is often the same complexity a mid-market program simply doesn't have.
Large enterprises often have a legitimate case for staying disparate in specific functions, because the problems genuinely vary enough, and are complex enough, to justify that depth. A global organization running privileged access across dozens of legacy and cloud systems has requirements a general governance platform may not fully address. That's a reasonable trade, provided it's a deliberate choice for a specific function rather than the default state of the entire program.
Mid-market organizations are usually the clearest case for converging, and it's not a matter of having less expertise. Most mid-market organizations still run a dedicated identity or IT security team, just a smaller one, often one or two people covering discovery, lifecycle, reviews, and SoD rather than a specialist owning each. A team that size can competently run one well-integrated platform.
Asking the same team to also be the integration layer between four or five separate tools, learning each one's admin console, and reconciling their data by hand, is a staffing problem. A converged platform removes that problem. It doesn't require a more complex team to solve it.
How to Decide
The clearest signal isn't a checklist, it's whether your current setup is actively producing the costs described above, and which of the four convergence types would remove them.
- Reviews take days of reconciliation, and revocations sit in a queue? Types 1 and 3 are your gap: discovery feeding reviews complete data, and reviews executing their own decisions.
- Transfers keep leaving people with old access? Type 2: requests and lifecycle on the same trigger logic.
- Audit prep is a recurring scramble across tools? That's the baseline convergence case, one data model.
- Renewals keep surprising finance? Type 4 turns the same platform into their tool too.
If your current tools are working reasonably well and the friction is manageable, the case for convergence is weaker, and the migration cost may not be worth it yet.
Zluri's discovery methods, covering SSO and IdPs, direct integrations, HRMS, MDM, finance systems, CASBs, directories, and browser extensions, are what make a converged model possible in the first place: without a complete, accurate picture of every identity and every app, provisioning, reviews, and SoD checks all end up working from the same incomplete data a disparate model would have given you, just under one roof instead of several. Once you've decided, our guide to evaluating IGA software covers how to validate all four convergence types before you sign, and our implementation guide covers the rollout itself.
Frequently Asked Questions
What are the main types of convergence in an IGA platform? Four matter in practice: discovery converged with governance (the platform finds apps itself rather than governing only what SSO shows it), access requests converged with lifecycle management (a transfer grants new access and revokes old access in one workflow), access reviews converged with provisioning (a revoke decision executes automatically instead of becoming a ticket), and IGA converged with SaaS management (the same data powers governance and license spend visibility). Most platforms marketed as "converged" deliver some of these, not all.
Can you converge gradually, or does it have to happen all at once? Gradual convergence is common and often more practical than a full cutover. Many organizations start by consolidating the functions causing the most pain, access reviews and SoD checks are common starting points, before migrating lifecycle management and other functions onto the same platform.
Does converged IGA mean giving up best-of-breed tools entirely? Not necessarily. A converged core platform can still integrate with a specialized tool for a specific function, like PAM, rather than replacing everything. The distinction that matters is whether identity data is unified across what you keep, not whether every function lives in a single product.
How do we know if our current disparate setup is actually costing us, or if it's fine as is? Look at how much manual reconciliation your team does around audits, reviews, and offboarding. If that work is minimal and access data stays reasonably accurate without much intervention, the disparate model may be functioning well enough. If reconciliation is a recurring, time-consuming task, that's the direct cost of fragmentation showing up in practice.
Is converged IGA more expensive than running several point solutions? Often less, once the full cost of the disparate model is counted, including integration work, the internal expertise needed to run multiple tools, and the labor spent reconciling data across them, not just the sum of the individual license costs.
If a vendor says their IGA is "converged," does that mean it's also visibility-first? Not necessarily, and it's worth asking directly. Convergence describes whether governance functions share one data model. It says nothing about how that platform finds apps and identities in the first place. A converged platform can still be limited to whatever's connected through your IdP, which means shadow IT and non-SSO apps stay outside its governance scope regardless of how unified the governance functions themselves are.
Doesn't lifecycle management already handle role changes and transfers, not just joiners and leavers? Often only in name. Many platforms market "lifecycle management" as covering joiners, movers, and leavers, but the mover half frequently isn't automated the same way, it routes through a manual access request instead. Worth checking specifically whether a role or department change in your HRMS triggers both the new access grant and the old access revocation automatically, or whether only the grant is automated and the revocation depends on someone remembering to file a second ticket.
What happens to review decisions if reviews and provisioning aren't converged? They become tickets. The review tool records the revoke decision, someone exports the list, and IT works through the revocations manually across each app. The certification looks complete while the risky access stays live until the queue gets worked, which is exactly the gap auditors have started probing: they increasingly ask for evidence that revocations were executed, not just that decisions were recorded.
.svg)
