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 inside 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 load-bearing for the IGA.
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 something the IT or security buyer gets to hand to finance.
That's the reverse of how SaaS-management-first vendors work:
Nobody needs finance to convince security or IT to invest in identity governance. What IT and security need is for finance to say yes when the budget conversation happens, and the SMP is precisely what turns that conversation.
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 end up glad it was there.
An IGA buyer doesn't need to want SaaS management. They need what it does to the rooms they walk into.
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.
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 lives in the 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 in the platform, 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. 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. The SaaS management side is how that buyer walks into the finance conversation with something to give rather than something to ask, often without having known, at evaluation time, that this was the piece that would make their stakeholders love the purchase.
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 finance or procurement buys and any governance capability has to win over a security team that didn't choose it. Here, the security buyer chooses the platform, and the SMP is what they hand finance to turn a budget gatekeeper into an advocate.
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)
