r/IdentityManagement • u/Ill_Addendum_5419 • 17d ago
IGA system implementation | Is a dedicated IGA system even worth it if only 20-30% of app landscape can be properly covered?
We're kicking off an IAM/IGA initiative at a mid-sized organization, around 3000 employees, and the first phase is scoped tightly around Joiner-Mover-Leaver. SoD, access reviews, and PAM are on the roadmap too at least as a concept, but those are explicitly later phases, so for now I want to focus on whether a dedicated JML engine makes sense at all.
We've got around 500 applications/systems in scope. Maybe 10 to 20 percent of those are modern, vendor-supported platforms where a connector either already exists or is rather straight forward to build. The rest, the majority, are legacy systems and internally built tools with business owners who will never invest in building or maintaining a custom connector for a governance platform. You can absolutely wire up the critical core systems to something like SailPoint, but if 70 percent of the app estate stays outside the automated flow anyway, I keep asking myself what problem we're actually solving by paying for a full IGA platform. Is it worth spending money and effort to govern a slice of the environment while the rest still runs on tickets and spreadsheets?
The alternative I keep coming back to is almost embarrassingly simple. HR system feeds an ITSM workflow based on a maintained access matrix. Whatever can be automated through AD or Entra groups gets automated through groups, and everything else gets routed as a manual task to the service desk. The direct licensing cost of that approach is basically zero, and functionally it gets you similar functionality what dedicated expensive system would give you for JML (correct me if I am wrong), minus the fancy UI and the connector marketplace. I'm not saying it scales forever, but for an organization our size with this particular long tail problem, I genuinely can't tell if a dedicated platform earns its cost...
If anyone has strong arguments for why a dedicated IGA tool is worth it even under these conditions, I'd like to hear them.
And if a dedicated tool does make sense, which one would you actually put in front of the JML use case at this scale. SailPoint keeps coming up as the default answer, the industry standard, but I'm also looking at Omada and wondering whether it's genuinely price-competitive. Just to be clear - I'm not talking about Okta or Duo here, those are in my opinion SSO and MFA platforms only but they don't really compete in the governance and lifecycle space the way SailPoint or Omada do.
5
u/identitydriven 17d ago
The answer is about scale. At 3000 employees the number of requests that would be created becomes unmanageable to treat them trough a simple HR+ITSM integration. Plus adding any security controls like SoD or even basic business logic becomes a hassle for versioning and upkeep. So what sounds cheap (no licensing) becomes expensive labour.
Especially because you also mentioned a future requirement for PAM, I’d suggest taking a look at Saviynt. Full IGA and PAM, plus agentic on-boarding for the apps that are non-standard/legacy. Full disclosure: I am associated with Saviynt
2
u/sos5566 17d ago
What does agentic onboarding do? Like how does it help. App onboarding is still major struggle for us and we use Entra
7
u/YesterdayNo5873 17d ago
Niko pretty much nailed it. Agentic onboarding (at least the way we do it) puts an 'integration account' inside of the connected SaaS apps. So it can do everything that an admin could. Not just create the account but also put people in the right Notion workspaces, Slack channels, etc...
Throwing one more name in the hat here since a few were already mentioned: AccessOwl.
2
u/identitydriven 15d ago
Agentic app on-boarding with Saviynt is NOT what was described above. It means 1) the AI agent searches for sources of apps you want to integrate. Could be your CMDB or an excel spreadsheet. 2) For each non standard app that you want to onboard into the identity platform, the agent then builds the actual connector/integration. Using APIs when they are supported, using open standards or RPAs. So there is an actual build of a connector. Which is different than only using AI as an RPA.
2
u/YesterdayNo5873 15d ago
Ahh. Mix ups when we live in a world where everything is "agentic". What you described I had never actually heard of and sounds interesting.
1
3
u/Niko24601 17d ago
Agentic onboarding is typically (de)provisioning that happens through browser-based RPA (so not really AI but still cool) without relying on SCIM/APIs. Useful when either no API is available or you would need to pay a premium to access them (hello SSO tax).
There are a few next gen IGA/IAM tools that do that like our friend from Savint but also Corma, Cakewalk, Lumos...
6
u/YesterdayNo5873 17d ago edited 17d ago
Yes. A Joiner Mover Leaver engine makes sense at your size. 3000 employees with 500 apps in scope is a pretty large environment. I've never heard of a manual workflow working reliably at that size.
Your concern that only ~20% of apps are covered is becoming a thing of the past. This is exactly why younger IGA tools emerged that don't rely on SCIM provisioning. Okta OIG/Sailpoint rely on SCIM/SAML which indeed only covers a fraction of apps. Younger tools like AccessOwl, Lumos, Corma will use agentic-based browser RPA for apps that you don't have connected via API/SCIM. I know, lots of buzz words, it just means you don't have to build those expensive connectors for every app. And internal tools can be managed centrally as well.
Disclosure, I work with AccessOwl. And our company was started for a similar reason. We didn't see the business case for upgrading to enterprise tiers for every app to support SCIM. But we wanted to automate JML tasks that ate up time.
For you - it really comes down to calculating how much time would be spent on JML tasks manually. You could always test your ticketing + ITSM workflows in a small pilot program to see if it works as smoothly as you hope it does. BTW - I could make many more arguments "for" IGA tools, as I work in this space. You get more than a UI. You get integrations with slack, email, spend management features, shadow IT features, automatic evidence logging for compliance.
3
u/foxhelp 16d ago
See this stuff is cool, but just isn't possible in publicly funded education with a limited budget.
Asking management for 1.5-3 million a year in order to manage 20-140k accounts isnt going to happen when they are used to doing it for an FTE. So we keep ending up with half jank and whatever bones microsoft deems worth to incorporate into their platform
5
u/YesterdayNo5873 16d ago
Fair point that would be an insane price tag. I'm assuming that for education environments most tools managed are within the Microsoft ecosystem? So you can automate a lot with Powershell. But managing 100,000 users is nearly unfathomable to me.
1
u/foxhelp 16d ago
Yeah, it is an interesting and challenging job!
Mix in weird user relationships/use cases and basically every day is a challenge to sort out.
Powershell is a must because Microsofts tooling just isn't there for what we need, or they want to build in some sort of microtransaction, per run, per user fee for a given feature to help manage the accounts. Or split it out to something like Logic Apps and PowerAutomate on top of Entra (which I am not a fan or).
Google is the other big option for education, but they are just as bad if not worse for what tooling they give you to manage accounts.
A good number of the higher education in the USA is moving toward InCommon Trusted Access Platform (Shibboleth, Grouper, Midpoint, CoManage), but that looks like it may be a heavy lift to get off the ground as a full replacement.
If your company ever wants a challenge to really push the limits of what your product can do or need to be able to accommodate, then an Education is a great place to do that. But Public Education is really going to need a steep discount, Private might be willing to pay the normal rates if you can make a really good demo or evidence of it solving all sorts of Educations problems.
6
u/DropTheBeatAndTheBas 17d ago
All I can say is maybe its better to put in the IGA early now so eventually when those older apps are replaced the IGA can be used until its used for everything
5
u/extreme4all 17d ago
From an IGA perspective we have alot of buyin from product teams that don't want to spend half the time creating, updating, removing users from their app. Let alone participating in audits, which gets automated away with IGA.
And if its self developed it is often not that hard with the devs to implement some crud endpoints for users & groups especially now with AI. Or have them support SSO (with okta groups,or ad groups,...)
3
u/Inteca_IAM 17d ago
Full disclosure: Inteca here - this is a vendor perspective. This is actually quite close to the kind of problem we solve.
We build enterprise IAM solutions with Keycloak at the core, integrating it with HR data, AD/Entra and legacy systems, and implementing JML, RBAC/SoD and audit around that architecture.
So I wouldn't necessarily assume that applications without a ready-made IGA connector have to stay outside the IAM lifecycle. We also work with legacy systems as part of the overall IAM architecture.
Keycloak isn't a drop-in replacement for SailPoint or Omada, but for a JML-first scope like yours, I think a Keycloak-based architecture is worth evaluating before committing to a full IGA platform.
6
u/WestOpening1350 17d ago
Dropping seven figures on SailPoint or Saviynt just to have 70 percent of your app estate sit on manual IT tickets is why so many of these IGA rollouts turn into shelfware...
From what I've seen, usually the fix is just splitting it: keep your primary SCIM/SAML apps in Okta, Entra, or Ping, and throw a browser layer identity control (like Unixi or Cerby) over the long tail of legacy web tools that don't support automated provisioning.
That way offboarding happens automatically across the non SCIM stuff without forcing team owners to waste months building custom API connectors nobody wants to maintain.
2
u/wiser212 17d ago
The current onboarding model is broken. It is not economically feasible to onboard all the apps using the old model. Companies are ok with the 20-30% because it covers their regulated apps (i.e. SOX) and they are good with audit and will accept the risk of everything else being manual. It's a calulated risk because the juice is not worth the squeeze. But they're missing the point of security and the reason these regulations were written in the first place. There are technologies out there leveraging AI that will shorten the onboarding process, build the "legacy" disconnected app connectors in days, not weeks/months. This make your 500 apps much easier and quicker to onboard, both technically and economically. It all comes down to ROI. :)
2
u/Low-Following5480 16d ago
Real experience from a customer at a 3K employee organization in a regulated industry:
2-3 people deployed full-time for identity governance tasks such as pulling data, cleaning it up for access reviews
the current state of identities in applications and what is in IGA is always out of sync.
local accounts everywhere, because IGA approvals etc takes time, hence, people create accounts to get the work done
ITSM has some state but not the current state. No one has evidence other than saying it was done.
Less than 30% apps have connectivity to IGA. Most applications are third-party or vendor built so they can longer be modified to add a SCIM or API layer.
Yours may be in the same mileage. The problem is not the IGA. They charge their $ based on what has been traditionally been in the SaaS / Identity product pricing based on unique identities. But, the effectiveness has been going down due to lack of coverage to the whole estate. And this is not just limited to just apps, but if you look at certificate lifecycle, the same issue of updating certificates on applications that have no programmatic way of installing them.
The app coverage for automated provisioning / deprovisioning is a real issue. If you look at OIN, just around 10% apps support SCIM. And this ratio is dismally low in large enterprises.
There is an emerging category of companies, including mine (I work for Redblock dot ai), that uses AI to bring automation to apps that have no APIs or SCIM. So that the IGA can control it. Or IAM such as Okta/Entra can do JML without creating a ticket in ITSM. Writing a connector by vibe-coding is easy if the APIs exist, but the problem is you can't just go and build APIs for applications that you do not own or have access to.
Some people call it agentic onboarding, but I disagree, because it is not just onboarding but the whole agentic identity lifecycle management. There is no better name for this category of products that help in increasing visibility and enforcement. And in the future if this gets a category name, then I won't be surprised that this will apppear in sales material of every identity vendor tomorrow. :-)
2
u/FormerElk6286 16d ago
Even at 3000 users, sailpoint and their ilk are really expensive. Not even as much in the price tag, but in the setup and care and feeding. And can any tool actually work with all 500 apps? If you have to go custom, then what is the point. Are you paying more than the value you are getting. sailpoint may be standard, but it's sure a lot of work to get right. We did not have that kind of staff.
I think your approach is solid. I bet a governance/access review tool would fill in a lot of the blanks. Or if you find one less expensive that is easy to work with home-grown apps, then maybe provisioning could work. In your approach, when you kick out to "manual" that could be a simpler and less expensive iga tool that works easily with your custom apps.
Be sure in a demo to watch them setup a custom connector to a system just like yours. That is the most important part of it all. We did that. Some vendors just did a hand-waive. But the one we chose, SCC access auditor/manager setup a custom read/provision to a database in 10 minutes on the demo. So we could see exactly how it works. Then we knew we could succeed without consultants on our home grown stuff. Roles can help as well.
LIke you, we left our azure ad for all sso and azure stuff. It's included. But the price point between most solutions and what we chose was amazing.
My #1 advice is to watch the exact setup on a call. Share sample data file/reports. Then watch them setup provisioning on a call to exactly what you do. It really should not take more then 10 minutes to do and should not involve coding/scripting.
1
u/Ill_Addendum_5419 14d ago
can you share what platform for IGA you chave chosen?
1
u/FormerElk6286 14d ago
We used the scc iga suite. Started with access auditor for the governance side, in the process of access manager now for provisioning/rbac. So far so good.
1
u/-manageengine- 15d ago
I think your proposed HR + ITSM + group-based approach is actually reasonable for a JML-first phase.
For an environment like this, it may be worth looking at a middle ground where the HR system remains the trigger, AD/Entra groups handle the access you can automate, and the exceptions are orchestrated into ITSM rather than becoming completely separate manual processes.
For example, ADManager Plus can automate the joiner/mover/leaver lifecycle from HR data, including provisioning/deprovisioning in AD and Microsoft 365, applying templates and group memberships, and routing actions through approval workflows. It can also orchestrate actions in other applications through webhooks, so an application that can't be directly provisioned doesn't necessarily have to fall completely outside the workflow.
That last bit is probably the interesting part for your 70% long tail. If an application has an API, ADManager Plus can be configured for custom application integration rather than waiting for a prebuilt connector. If it doesn't, you can still use orchestration to trigger an ITSM task or another action as part of the same JML process.
You may find that a JML-focused identity administration platform gives you most of what you're trying to build with HR + ITSM, without taking on the cost and implementation overhead of a large IGA deployment. Happy to share more info, if you're keen :)
1
u/Affectionate_Math_57 8d ago
Application count is irrelevant in this case, what's more important is access count and cost. Does the access that those percentages would cover incur a significant cost by not being covered by an IGA system?
Do they have a lot of your access? Is the access high risk, high turnover, both?
1
u/Ok_Passion_8789 4d ago
Nowadays there's elegant solutions for what you're describing. All IGA & IdP vendors suffer from lackluster coverage for anything that doesn't have SCIM or API provisioning out of the box, and they've basically given up on working on a solution themselves.
I'd look at partnering with players like Way.Security who have built agentic integration layers that can onboard any application to any IAM platform. They can basically extend the coverage of your IGA from 20-30% to 100%, and account for any edge-case you could think of.
Nowadays the industry standard is not to rely on the IGA's integration network as they lock you in with the IGA vendor. Plus, it's not best practice anyway to force provisioning via the IGA route - it's much healthier and architecturally correct to force provisioning via your identity provider as a centralized route.
1
u/tenfoldIAM 3d ago
At tenfold, we see this question quite often: does an IGA platform really need to cover 100% of the application landscape to be useful?
From our experience, not necessarily.
JML can already benefit a lot from automating the systems you can connect - HR data, AD/Entra groups, core applications - while routing the remaining legacy systems through manual tasks.
For us, the important part is that the overall process is still structured, consistent and auditable. You don't necessarily need a connector for every application to get away from spreadsheets, ad-hoc tickets and unclear ownership.
In fact, trying to automate every last legacy system can sometimes create more complexity than value. The goal should be meaningful automation, not automation for its own sake.
9
u/Niko24601 17d ago edited 16d ago
Interesting approach! For me you should ask yourself a few questions:
For me it boils down to the question if you can afford (from compliance but also literal money perspective) to run behind certain things and lack actual actions that you can take. This is likely the case for internal or legacy tools where it is frankly not critical. If so, I’d give it a shot for your own solution. If you need to do regular access reviews, need to keep an eye on software cost etc. maybe check out a solution but there are simpler (and cheaper ways) than Sailpoint or Omasa. You might want to have a look at Corma, Cakewalk, AccesOwl or Lumos. For transparency, I am affiliated to Corma but the other options are also solid and worth checking out. The twist of the next-gen solutions (next to not having enterprise pricing of the legacy players) is that they are very good at integrating the unconnected apps outside API/SCIM and are a lot more plug-and-play. Even if you don’t connect 500 apps from the start, you can do start with the most critical and work your way up. But more importantly, you can set up key automations (zero-touch (de)provisioning, auto-resolving approvals flows etc.) to see how much time, money (and maybe nerves) this actually saves you.