In our last post, we established that most enterprise application environments have a significant identity coverage problem. Fewer than 7% of applications support SCIM. On-premises and private apps resist federation by design. And for everything that falls outside IAM and IGA control, manual execution is the default.
For leaders immersed in talk of modernization and transformation, this might sound like a temporary problem, one that will resolve itself as vendors mature, standards proliferate, and legacy systems are retired.
It won't. The app gap is sustained by a combination of misaligned vendor incentives, the stubborn persistence of on-premises infrastructure, and the limits of the custom solutions organizations typically turn to. Understanding each is essential to understanding why the problem isn't going away.
App vendors have few incentives to add support for identity standards
App vendors aren't dragging their feet on identity standards support. They're making a rational business decision not to build it. And waiting for out-of-the-box support for SCIM or user management APIs is not an effective strategy.
Waiting puts the future of your operational efficiency and security in the hands of other companies, and those companies have little reason to prioritize your integration needs over their own roadmap.
To understand why, we need to understand how app vendors prioritize their roadmaps. For most, the list looks something like this:
- Core product features
- Performance and reliability
- Integrations that drive growth
- …And somewhere further down, identity standards
Unless enterprise customers are actively demanding it, SCIM and user management APIs rarely make the cut. Three structural reasons explain why:
Engineering complexity and maintenance
Implementing identity standards correctly is not trivial. It requires specialized expertise that most product teams don't have in-house, and once built, these integrations require ongoing maintenance as standards evolve. For a small SaaS team weighing that investment against shipping core product features, the math rarely works out in favor of identity standards.
Product prioritization and resource constraints
Most SaaS vendors are running lean teams with competing priorities. Identity standards support is rarely a growth driver, and it won't show up in a product demo. Until enterprise customers make it a procurement requirement, it stays at the bottom of the backlog.
Identity standards are monetized as premium features
When vendors do build support for identity standards, they rarely offer it to all customers. SSO, SCIM, and user management APIs are frequently bundled into enterprise licensing tiers, reserved for customers willing to pay a significant premium. For vendors who aren't primarily selling to large enterprises, there's little financial incentive to build these capabilities at all, and for those who do, restricting access to premium tiers is how they monetize the investment.
The result is a market where identity standards support is the exception, not the baseline. And paying a "standards tax" to unlock basic lifecycle management capabilities across your application portfolio, or even just the most critical apps, is neither scalable nor sustainable.
“Legacy” on-prem and private apps aren’t going anywhere
Despite the ongoing adoption of SaaS applications, the reality is that on-premises and private apps will remain vitally important pieces of the IT ecosystem for the foreseeable future.
Several forces are keeping these systems in place:
- So-called “legacy” apps often form the heart of business operations and continuity, and a well-earned “don’t fix what isn’t broken” policy means that the apps themselves will rarely, if ever, be modified or replaced
- Digital sovereignty initiatives (e.g., regulatory and data sovereignty requirements) are causing companies to consider moving even more apps in house
- Privacy and security policies may require certain workloads (e.g., those using sensitive data or AI models) to remain local
As long as these systems remain in place, identity lifecycle processes cannot rely solely on standards-based integration. Many of the applications that matter most to business operations will continue to sit outside the reach of traditional lifecycle automation.
Custom solutions are slow, expensive, and brittle
Third parties can build custom integrations between your IAM solution and each of your apps. Unfortunately, such engagements often present significant long-term sustainability challenges.
First, such initiatives are slow, complex, and costly because they tackle each app one by one. The amount of custom work varies wildly based on available APIs, internal app architecture, and specific version requirements.
This bespoke approach is inherently expensive, as even a single application may require multiple custom connectors to account for different versions in use, making it nearly impossible to achieve comprehensive coverage across an enterprise library.
Second, and perhaps most importantly, the result of custom development is often a collection of static integrations. These are brittle by nature; because they are hard-coded to a specific application state, they can stop working without warning if a vendor pushes a UI update or changes a private API endpoint. This leaves IT teams with a mounting "maintenance tax," where they must spend more time fixing existing connections than building new ones.
It's also worth noting that custom connectors and these types of engagements are only viable when an application actually exposes APIs or SCIM endpoints to integrate against. For the large portion of the app ecosystem that offers neither, there is no integration path to build, custom or otherwise. These applications simply cannot be connected to IAM and IGA systems through conventional means, leaving manual processes as the only option regardless of budget, tooling, or intent.
An inconvenient truth
The inconvenient truth is that disconnected applications don't represent an edge case. They are a permanent liability. Their resistance to automation creates a growing list of operational, governance, and security risks that most organizations are only beginning to reckon with.
The consequences rarely surface in a helpdesk ticket. They show up in breach investigations, audit findings, and acquisition due diligence, often long after access should have been removed. In our next post, we'll explore what happens in the absence of identity automation and why the business and security costs are larger than most organizations realize.
Curious what manual identity execution is costing your organization? Download the infographic, The Real Cost of Manual Identity Execution, for a data-backed breakdown of the hidden impact.
