Every IGA platform on the market revokes access when someone leaves. Licenses get freed, seats open up, money is technically saved. Almost none of them can tell you how much. We kept SaaS management alongside our IGA for exactly that reason, and one more that matters even more.
We get asked about this in analyst briefings and sales calls alike: why does an identity governance platform still carry a full SaaS management product? The implication is usually that it's a leftover, something from our origin we haven't gotten around to shedding as we went deeper into governance.
It's the opposite. SaaS management is its own product on the same platform, and customers who want IGA alone can run exactly that. But it's also load-bearing for the IGA in ways that only show up when the two sit side by side, which is why so many IT and security teams who came for governance end up loving the SMP: it makes their stakeholder management genuinely easier.
Remove it and two things break:
- The budget conversation that gets IGA funded in the first place
- The visibility-first architecture the whole platform stands on
Here's both, in the order they usually matter to a buyer. (For the broader comparison of what each category does and how much the two disciplines share, see identity governance vs SaaS management. This piece is the narrower story of why we build both as one.)
First, Who Actually Buys This, and Who It Wins Over
One clarification up front, because it shapes everything that follows.
Zluri is an identity security platform, and our buyers are IT and security teams. IGA and SaaS management are both part of the platform, alongside ISPM and IVIP, but the buyer has never been ambiguous to us. They come to us for governance, for lifecycle automation, for access reviews that hold up to an audit.
The SaaS management side isn't a second product aimed at a second buyer. It's the part of the platform IT runs and finance plans with, and choosing a platform that serves both is the IT/security buyer's call, made once, that keeps paying off across departments.
What the single platform actually adds, drawn from how our customers already run it:
Nobody needs finance to convince security or IT to invest in identity governance. What IT and security need is a budget conversation where the platform's value is already visible on finance's own terms, and the SMP is precisely what makes it visible: documented spend data finance was already looking for, produced by the same platform governance runs on.
Here's the pattern that surprises buyers themselves. Most IT and security teams don't know, at evaluation time, that they need SaaS management for stakeholder alignment. It's not on their requirements list. It's not what they came to solve.
Then, months after deployment, those same customers tell us the SMP is one of the things they love most about the platform. The telling part: many of them barely use it directly. Who actually uses it:
- Their finance team, for spend visibility and renewal planning
- Their procurement lead, for contract and negotiation data
- Their department heads, checking usage before renewals
The IT or security buyer hears "this is really useful" from teams they've spent years trying to win goodwill with, and that goodwill flows back to them and to the governance program they actually came here to run.
And to be clear: none of this means the SMP is only ever a happy accident. Plenty of buyers evaluate Zluri wanting both from day one, IGA for their own team and SaaS management for the organization, and buying it that way is every bit as valid. The point isn't that you shouldn't want SaaS management. It's that even the buyers who didn't want it end up glad it was there.
You don't have to want SaaS management. Your stakeholders will.
Reason One: It Makes the IGA Self-Funding, and Provably So
The budget problem with IGA is that it's a cost-center pitch. The ROI of governance is real but hypothetical: breaches avoided, audit findings that didn't happen, fines not paid. Finance teams don't dispute that value, but they can't book it, and a business case built on avoided hypotheticals competes badly against projects with revenue or savings attached.
Even the ROI that IGA does produce directly, the hours saved by automating provisioning and deprovisioning, is soft savings. Time back for the IT team is genuinely valuable, but it doesn't reduce a line item; nobody's software bill goes down because a workflow ran faster.
SaaS management produces the other kind: hard savings. A reclaimed license, a downgraded tier, a cancelled redundant subscription, each one shows up as a smaller number in the accounts. That's the evidence finance and boards weight most, because it isn't an estimate of value created, it's a cost that visibly went down.
The split isn't marginal, either. Per our ROI research, 43% of the total savings the platform produces are hard savings, and that's precisely the share you can't prove without an SMP. Without one, the business case is reduced to asserting that removing unused licenses would obviously save something, an argument finance has heard from every vendor, backed by no number they can check.
SaaS management changes what you're walking into that conversation with. Concrete, attributable dollars come from:
- License reclamation at offboarding and from unused seats
- Tier downgrades for users on premium plans with standard-tier usage
- Eliminated redundant subscriptions across departments
- Renewal negotiations backed by real usage data
The pitch stops being "fund our governance program." It becomes "the documented software savings cover the cost of the platform, and the governance comes with it." That's a categorically easier conversation, and one your finance stakeholders can champion instead of merely tolerate.
Other IGA platforms create some of these same savings. They just can't prove it, and the rest they can't create at all.
Three categories of savings, and they behave very differently depending on whether SaaS management runs alongside the IGA on one platform:
Savings Category 1: Revocation Savings, Which Other IGAs Create but Can't Prove
Every IGA on the market revokes access at offboarding. Every one of them, in doing so, frees licenses. Those savings exist.
But without a SaaS management layer, the platform has no idea what those licenses cost. No contract data to price the reclamation against. No reporting that ties a governance action to a dollar figure.
Attributing the savings becomes a manual project: someone exporting revocation logs, cross-referencing them against contracts finance keeps somewhere else, building the analysis by hand. In practice, that project doesn't happen. The savings stay invisible, and the IGA keeps getting defended at renewal as a pure cost.
Savings Category 2: Downgrade Savings, Which Other IGAs Can't Create at All
License tier downgrades aren't a revocation. They're a modification, and modify isn't a verb most IGA platforms have.
Executing a downgrade requires knowing the license tiers, their prices, and the user's real usage. That's SaaS management data by definition.
An IGA-only platform doesn't miss these savings because it lacks reporting. It misses them because nothing in its architecture can see the opportunity or perform the action.
Savings Category 3: Consolidation Savings, Which Other IGAs Can't Even See
The third category sits even further outside an IGA-only platform's field of view: redundancy across the portfolio itself. It shows up in three recognizable shapes:
- Three departments running three different tools that do the same job
- The same vendor's product purchased separately by two business units
- The same tool running in separate environments across locations, each on its own contract, pricing, and renewal date, with no one aware the others exist
Spotting any of this requires seeing the entire application portfolio with its spend, ownership, and usage side by side, which is precisely what an IGA has no reason to ever assemble.
Once visible, the money is real twice over. Consolidating similar apps eliminates whole subscriptions. Consolidating fragmented instances of the same tool into one negotiation converts scattered small contracts into the volume leverage that gets better pricing and better terms.
No governance action produces consolidation savings. Only portfolio visibility does.
With SaaS Management Alongside the IGA, All Three Categories Work
The revocation savings other IGAs create invisibly, we attribute automatically. The downgrade savings other IGAs can't create at all are just another workflow. The consolidation savings come from the portfolio-wide view that only the SaaS management side ever builds.
The evidence, cost versus spend, per app, per action, generates itself across all of it. That's the savings analysis finance actually accepts, and most of it comes from opportunities an IGA-only platform couldn't have seen, let alone acted on.
There's a second version of this problem worth naming: finance or IT running a separate SaaS management platform next to the IGA. That means duplicate effort, two teams maintaining two inventories, and two sets of integrations doing overlapping work. But the most expensive part is the conflicting figures. Two platforms counting apps, licenses, and spend independently will not agree, and every budget conversation starts with reconciling whose numbers are right.
Conflicting figures put finance and IT on opposite sides of the table. One platform, one set of numbers, makes them partners instead. What running the two sides as separate tools costs in full, including these savings that never materialize, is its own analysis: the real TCO of running IGA and SaaS management separately.
Reason Two: SaaS Management Is What Makes Visibility-First Possible
The second reason is architectural, and it's the one we'd keep even if the finance argument didn't exist.
An IGA without a discovery layer is governance-first by construction: it manages what you tell it to manage. Feed it an application list and it will provision, review, and certify against exactly that list, competently and completely, while everything outside the list stays ungoverned and invisible. The inventory is inherited from the identity provider, the identity provider sees the federated minority of the environment, and the risk concentrates precisely in the part nobody's watching.
Traditional IGA even has a name for the project this forces: role mining. A months-long exercise of extracting entitlement data, mapping users to access, and reconstructing who holds what. And after all those months, it only covers the applications already known and connected to the platform.
Worth being precise about the left column. Full access mapping across the entire environment isn't just slow for an IGA-only platform. It's something most of them simply can't do at all.
A platform with no discovery layer has no mechanism for even learning that an unconnected application exists, let alone mapping the access inside it. The mapping doesn't happen late; it never happens. The most expensive phase of the deployment produces a map of the smallest part of the territory.
SaaS management is what collapses that. Discovery runs continuously across finance and expense data, browser and desktop agents, direct integrations, and the IdP alike. The shadow IT, the team-purchased tools, the apps on a corporate card: those enter the picture through SaaS discovery, and then governance applies to the complete picture rather than the declared one.
Strip the SMP out, and the visibility-first architecture goes with it. What's left is another governance-first tool with a better interface, managing a list and calling it an environment.
The Thing That Only Exists Because Both Live Together: Modify, Not Just Grant and Revoke
Most IGA operates on a binary: grant access, revoke access. Those are the two verbs the category was built on, and they're the right verbs for joiners and leavers.
But a huge share of real access risk and real software waste lives in between, in access that shouldn't be removed but shouldn't stay as it is. Acting on that middle requires knowing two things at once: the entitlement structure inside the app, and the economics of the license attached to it.
That's why our platform has a third verb. Downgrading someone from admin to user is a least-privilege win that doesn't cost the person their tool: the kind of remediation reviewers actually approve, because it fixes the risk without generating a complaint. Downgrading a license tier is the same motion pointed at spend, and it carries a security win too, since higher tiers bundle more capability and therefore more blast radius.
On a platform that only knows how to grant and revoke, both of these are invisible options. The review flags the over-privileged admin, and the only lever available is removal, which nobody wants to pull, so nothing happens.
Grant and revoke govern the edges of the lifecycle. Modify governs everything in the middle, and the middle is where most of your users are.
What This Adds Up To
We didn't keep SaaS management out of attachment to where we started. We kept it because the IGA is better with it in three ways that can't be replicated by integration:
- A budget case built on documented savings instead of avoided hypotheticals
- An inventory built by discovery instead of declaration
- A remediation vocabulary that includes modify, the middle ground where most real-world access decisions actually live
And underneath all three, a simpler point about who this platform is for. Our buyer is the IT or security team that came for governance. Choosing a platform where SaaS management serves IT and finance alike, while IGA stays IT and security's own program, is what turns the budget conversation into a shared case rather than a request, often before the buyer knew, at evaluation time, that this was the piece their stakeholders would value most.
Two products stitched together could approximate some of this. One platform, one data model, is what makes all of it just how the system works.
Frequently Asked Questions
Who is Zluri actually built for, IT and security teams or finance teams?
IT and security teams are the buyers; finance is a stakeholder who benefits. Zluri is an identity security platform, IGA and SaaS management together, alongside ISPM and IVIP, and the purchase decision runs through the teams who own governance and access risk. That's the reverse of SaaS-management-first tools, where IT and finance buy together and any governance capability has to win over a security team that didn't choose it. Here, the security buyer chooses the platform, and finance gets a genuine working stake in it, spend visibility and renewal data they'd otherwise be assembling by hand, which is what turns the budget conversation from a defense into a shared case.
Doesn't bundling SaaS management make the IGA more expensive?
No, and that's rather the point: the SaaS management capabilities come with the platform without a meaningful cost addition, while the savings they produce, reclaimed licenses, tier downgrades, eliminated redundancies, are concrete and documented. For most customers, those savings materially offset the platform cost, which is what makes the finance conversation work.
Other IGA platforms revoke access too. Doesn't that produce the same savings?
It produces some of the same savings, the revocation-driven kind, and none of the proof: without license cost and contract data in the same platform, a revocation is just a revocation, and building the savings analysis manually is enough effort that it rarely happens. But two whole categories don't happen on those platforms at all. License tier downgrades require modification, a verb IGA-only platforms don't have, plus pricing and usage data they don't hold. And consolidation savings require a portfolio-wide view of spend and usage that an IGA has no reason to ever build. Those savings aren't unproven elsewhere. They're nonexistent.
What if we don't think we need SaaS management?
Most of our buyers didn't either, at evaluation time, it's rarely on an IT or security team's requirements list, because it isn't the problem they came to solve. The pattern we see repeatedly is that the same customers tell us months later that the SMP is one of their favorite parts of the platform, often without using it much themselves: their finance, procurement, and department teams use it, find it genuinely valuable, and say so. For the buyer, that's stakeholder goodwill they didn't have to campaign for, attached to the governance program they actually came to run.
Can we buy the IGA specifically because we also want the SaaS management?
Of course. Everything above describes the buyers who arrive for governance alone and discover the SMP's value later, but plenty of teams evaluate Zluri wanting both from the start: IGA for the IT or security team's own program, SaaS management for finance, procurement, and the wider organization. If you already know your stakeholders need spend visibility and license optimization, that's not a secondary use case, it's the platform working exactly as designed, just with the discovery phase skipped.
Can't I just integrate a standalone SMP with a standalone IGA and get the same result?
You can get part of it. What's hard to replicate through integration is the shared data model: modify-style actions like role and license downgrades require entitlement structure and license economics visible to the same workflow at the same moment, and savings attribution requires the governance action and the cost data to live in one system. A sync between two products gives you two views that mostly agree, not one action that does both jobs.
How is this different from role mining in traditional IGA?
Role mining is traditional IGA's answer to "who has access to what": a months-long project of extracting and mapping entitlement data before governance can meaningfully start, and it only covers applications already connected to the platform. Full access mapping across the whole environment, including unconnected and shadow apps, isn't something an IGA-only platform does slowly; it's something it has no way to do at all, because it has no discovery mechanism to learn those applications exist. Zluri produces that complete picture in days, because the SaaS management layer is continuously building the inventory rather than waiting for a one-time mapping exercise scoped to known apps.
Is modifying access really that different from revoking and re-granting it?
Operationally, yes. Revoke-and-regrant interrupts the user, requires a new approval cycle, and in practice means reviewers avoid flagging over-privilege at all because the only remedy is disruptive. A native downgrade, admin to user, premium tier to standard, fixes the risk or the spend in one step without taking the tool away, which is exactly why those remediations actually get executed instead of deferred.
.svg)
