App Onboarding Was Never Designed to Scale

The Protocol That Was Never Built to Scale

Every IGA program starts with the same pitch: govern your applications, enforce least privilege, reduce breach exposure. The business case is clear. The regulatory pressure is real. The investment gets approved.

Then implementation begins, and the model breaks.

Not because the strategy is wrong. Not because the teams are under-qualified. But because the underlying protocol for bringing applications under governance was designed for a world that no longer exists.

In that older world, enterprises ran a manageable number of applications. Onboarding each one was slow, expensive, and consultant-dependent; but the estate was small enough that the pace felt acceptable.

Today, the average enterprise runs more than 200 SaaS applications, plus a long tail of custom-built tools, legacy systems, and disconnected apps that have never seen a governance policy. The onboarding model never changed. The application estate grew by an order of magnitude.

Something had to give. What gave was coverage.

‍

What "Onboarding" Actually Means and Why It Takes So Long

Before diagnosing the failure, it helps to be precise about what application onboarding for IGA actually involves. It is not simply flipping a switch or pointing a connector at an API.

A complete onboarding engagement requires:

• Scoping the application's identity objects, data flows, and access model.
• Schema modeling to map roles, entitlements, and permission structures into the IGA platform's framework.
• Connector development or configuration, either building a custom connector or adapting a pre-built one to match the application's actual API behavior.
• Policy authoring to define governance rules, access certifications, and provisioning logic.
• Testing and validation against live system behavior.
• Documentation and break-fix playbooks for your ops team.

Done properly, this is a significant technical and coordination effort. Done the traditional way (with a traditional external systems integrator leading the work) it takes six to eight weeks per application and costs $50,000 to $150,000.

Those numbers look manageable for three applications. They become impossible for over a 100 apps.

‍

The Coverage Math That Never Works Out

Here is the arithmetic most IGA programs quietly avoid:

An organization with 150 applications in its governance backlog, using a traditional consultant-led model, is looking at a minimum of 900 weeks of onboarding work,  roughly 17 years at the pace of one application at a time. Even with parallel work streams, reaching full coverage inside a single budget cycle is not a realistic outcome.

So organizations prioritize. They start with the applications that are easiest to justify to a compliance auditor: regulated systems, high-visibility platforms, Tier 1 infrastructure. Those get onboarded. The second tier gets deferred to next quarter. But the next quarter never arrives.

By then, the IAM team is stretched. The budget is tighter. The applications that were hardest to onboard (the legacy systems, the custom-built tools, the apps with no API support) have become even harder to fund. The backlog grows and coverage barely increases.

The industry average reflects this reality: most enterprises govern fewer than 30% of their applications under active IGA policy. The other 70% are either unmanaged or manually audited at best.

‍

The Applications Left Behind Are the Real Risk

This is the part of the conversation that tends to get avoided in board-level governance reviews: the applications that don't get onboarded are not the unimportant ones.

Legacy systems frequently hold sensitive access permissions that were granted years ago and never reviewed. Custom-built internal tools often lack any access control architecture at all. Disconnected applications (those with no API support for IGA connectors) are almost never included in governance programs, even when they contain critical business data.

These are not fringe edge cases. According to industry research, approximately 60% of enterprise applications are either custom-built or legacy systems, precisely the categories that traditional IGA programs skip first.

The attackers do not follow the coverage roadmap. A well-governed Salesforce instance does not protect an unmanaged HR portal running on a legacy LDAP integration. Selective governance creates a false sense of control while leaving the most difficult-to-audit systems entirely exposed.

‍

Why the Backlog Is Structurally Self-Reinforcing

The onboarding backlog is not a prioritization problem. It is a structural problem with a specific economic signature.

When onboarding a single application requires:

• A systems integrator engagement.
• Multiple coordination cycles between the SI, the application team, and the IAM team.
• Custom connector development.
• Weeks of testing and validation

‍

...then the threshold for "worth onboarding" becomes very high. Only applications with a clear, auditable compliance justification can clear that bar. Everything else stays in the queue.

‍

The application estate does not stand still while the queue grows. New SaaS tools get adopted. Old systems get replaced. Applications that were worth onboarding eighteen months ago may be approaching end-of-life by the time they make it to the front of the queue. The cost-benefit calculation quietly turns negative, and the program stalls.

‍

When the economics stop working, governance becomes a rationalized compromise. Executives stop asking how to govern the full application estate and start asking how much unmanaged exposure is acceptable. That is not a security strategy. It is an organizational accommodation to a broken model.

‍

The Real Fix: Change the Onboarding Model

The instinctive response to this problem is better prioritization: smarter frameworks, risk-tiered roadmaps, more focused governance investments. These help at the margin. They do not fix the root cause.

The root cause is that the onboarding model is too slow and too expensive to achieve coverage at enterprise scale. Prioritization optimizes which 30% gets governed. It does not change the fact that 70% remains unmanaged.

What has to change is the onboarding timeline itself.

AI has to collapse what currently takes six to eight weeks of consultant-heavy work into a process measured in days. Not days with a large asterisk. Days as the operating model, minimal application team involvement, minimal IAM team coordination, production-ready delivery at the end.

Here is what that looks like in practice, compared to the model most enterprises are still running today:

‍

‍

The economic difference compounds quickly. A 200-application backlog that would take years and tens of millions of dollars under the traditional model becomes a quarter-long program under the AI-assisted one.

More importantly, the coverage threshold changes entirely. When onboarding is fast and inexpensive, the question shifts from "which applications are worth governing?" to "is there any reason not to govern all of them?" That reframe is the shift that actually matters.

‍

What Comprehensive Coverage Actually Enables

The value of full application coverage is not just a better audit posture. It is a structurally different security position.

When every application in the estate is under active governance:

• Access certifications reflect the actual identity surface, not a curated subset of it.
• Least-privilege enforcement applies to legacy and custom systems, not just Tier 1 infrastructure.
• Provisioning and de-provisioning become consistent across all applications, eliminating the orphaned account problem.
• Breach investigation scopes compress because the access model is fully documented.

These are not incremental improvements. They represent the difference between a governance program that reduces risk at the edges and one that actually controls the full access surface.

‍

The Klyro Approach

Klyro was built specifically to close this gap. The platform applies AI across the entire IGA integration lifecycle (from connector research and schema modeling to role mapping, entitlement configuration, and ongoing maintenance) for every application in the estate, including disconnected apps that traditional connectors cannot reach.

The result is application onboarding measured in days, not weeks. No repeated coordination cycles. No connectors that break silently when vendors push API updates.

The goal is straightforward: make 100% application coverage the default outcome, not an aspirational target that gets deferred indefinitely.