The 80/20 problem in IGA: why the last 20% of apps eats 80% of your budget
The hidden math of IGA programs — and why your real scope is bigger than your roadmap.
The hidden math of IGA programs — and why your real scope is bigger than your roadmap.
Talk to enough IAM leaders and a pattern emerges. The IGA platform covers somewhere between 30 and 80 applications. The actual environment has three to five times that. The gap is held together by a shared inbox, a couple of contractors, and a quarterly access review that everyone signs without reading too carefully.
This isn't the exception. It's the median.
Most IGA programs follow the same shape. A small set of tier-1 applications get the full treatment — SCIM, SAML, automated provisioning, certification workflows, the line items that show up on the program roadmap. Everything else lives in a long tail that absorbs most of the program's actual cost without ever appearing on a strategy slide.
Why this happens
Three structural reasons, none of which reflect on the IAM team's competence.
Connector economics. Pre-built connectors exist for the top 50-100 SaaS applications. For everything else, you're looking at $15-40K per connector in custom development, plus ongoing maintenance every time the upstream app changes.
Vendor incentives. IGA vendors rationally invest in the connectors with the broadest demand. Your regional broker-dealer platform, your custom mainframe app, the legacy commodities trading system your firm runs because the alternative is rewriting it — none of those are on anyone's roadmap.
Internal prioritization. IAM teams are graded on visible wins. SSO coverage. MFA enrollment. Top-app provisioning automation. The long tail is invisible until an audit, and by then the conversation is about remediation, not strategy.
This isn't a failure of IAM teams. It's the predictable output of how the industry has structured itself.
The real cost
When IGA leaders calculate program cost, they usually count licenses and professional services. The hidden cost is in four other categories that almost nobody fully sums:
-
Direct labor. Manual JML tickets at 20-45 minutes each, multiplied by your annual joiner-mover-leaver volume across every app in the long tail. For a 5,000-person enterprise, that's typically 8,000-15,000 ticket-hours per year.
-
Audit exposure. Findings on applications outside IGA scope. Remediation hours. External auditor cycles spent re-validating manual processes. The cost compounds because findings tend to repeat year over year on the same long-tail apps.
-
Risk-adjusted breach cost. Orphaned accounts in the long tail are where actual incidents happen. Industry breach data consistently shows that the apps least connected to identity infrastructure are the most likely vector. Your tier-1 apps are not your real risk.
-
Opportunity cost. Senior IAM cycles spent firefighting long-tail tickets instead of building program maturity, evaluating new controls, or supporting M&A integration.
A rough worked example. A 5,000-employee enterprise with 250 long-tail applications. Conservative inputs — $35/hour fully loaded for ticket labor, two audit findings per year at $40K each, one risk-adjusted incident every three years at $500K, a senior IAM hire's worth of opportunity cost — put the annual hidden cost between $1.8M and $2.4M.
Most IGA programs are already spending that money. They're just spending it across five budgets nobody connects.
What good looks like
The real solution has a specific shape, independent of which vendor delivers it. It covers any application regardless of whether the application exposes an API. It deploys in days, not months, per app. It doesn't require custom development for each new connector. And it integrates with the IGA platform you already run rather than replacing it.
The 80/20 distribution isn't a bug in IGA programs. It's the predictable consequence of how the industry has structured itself around the apps that are easy to connect. The leaders who'll get ahead in the next three years are the ones who stop treating the long tail as overhead and start treating it as the actual scope of their program.
Where Torch fits in
Torch is built specifically for the long tail.
Connecting an application used to require either a cooperative API or a brittle script that broke when the UI changed. Most of the long tail offers neither.
Modern AI agents change that. They navigate applications the way a human administrator does — reading the interface, handling unexpected dialogs, recovering when something moves. Torch pairs deterministic automation on the happy path with AI-based recovery on the edges.
Connectors deploy in days instead of months, work on any application regardless of API support, and integrate with the IGA platform you already run. You extend what you have rather than replace it.