A 40-app backlog is not an execution problem. It is an architecture problem. If your IGA platform requires 2-3 months of manual discovery work before it can govern a single application — questionnaires, RBAC documentation, auth flow mapping, integration point inventory — the bottleneck is structural. Hiring more identity engineers or pressuring app owners harder does not fix it. It just adds friction to a process that is already slow by design.

The question is whether the 90-day cycle is inherent to IGA as a category, or inherent to how legacy enterprise IGA platforms were built. The answer matters a lot for what you do next.

Why Legacy IGA Onboarding Takes So Long

SailPoint and similar enterprise platforms were built around a model that requires complete, static access profiles before governance can begin. Before the platform can manage an application, someone has to document: what roles exist in the application, what permissions each role carries, how the application authenticates, what integration points exist, what the RBAC model looks like. That documentation then has to be reviewed, validated, and translated into the platform's internal model.

That process has two structural problems that compound each other.

App owners are the wrong source. The people who know how an application actually works technically are rarely the people who bought it or who own it in the org chart. The person who originally configured the auth model may have left. The app owner may know the business purpose but not the permission structure. Getting accurate technical information out of the app owner — when they are busy, when they do not know it themselves, or when the documentation was never written — is where most of the 2-3 months goes.

Discovery goes stale before onboarding completes. As practitioners in this thread noted, by the time you finish gathering the information, validating it, and completing onboarding, the details have already changed. The app added a new role tier. A permission was renamed. The department reorganized and the RBAC model no longer reflects reality. You documented a snapshot of a moving target and governed it for three months after the snapshot was taken.

The 40-app backlog is what this arithmetic produces at scale: a process that takes three months per app, applied to a catalog that grows faster than the team can process it.

What Actually Shortens the Cycle

Pre-built integration catalogs. For modern SaaS applications, the technical discovery phase should not exist. If the IGA platform maintains a pre-built catalog of integration configurations — the exact API scopes required, the data points available, the workflow actions supported — onboarding a catalog application becomes configuration, not discovery. The platform already knows how the application works. The team maps their specific access model to that knowledge rather than building it from scratch.

The question to ask any IGA vendor: how many applications are in your pre-built catalog, and what does onboarding look like for an application that is already in it? The difference between "three months" and "three days" is often the difference between building an integration and applying a pre-built one.

Centralizing authentication as the first move. One practitioner in this thread made a point worth carrying forward: if every new application is required to centralize its authentication and authorization through your identity provider — Entra ID or equivalent — the onboarding path becomes repeatable. Applications that conform to the standard model (SCIM provisioning, SSO via OIDC or SAML, group-based access managed in the IdP) can be onboarded in days because the heavy technical work has been done by the application's existing integration with the IdP. The bespoke apps that do not conform are still hard, but they become the exception rather than the rule.

Establishing this as a procurement requirement — new SaaS purchases must support SSO and SCIM before IT will onboard them — is organizational policy work, not IGA configuration work. But it is the lever that most dramatically shrinks the category of hard onboarding cases.

Role mining from usage data rather than documentation. Instead of asking an app owner to document what their roles mean and who should have them, modern IGA platforms analyze actual user access patterns and usage data to infer role structures. When the platform can look at who has what access and how they use it, and generate policy recommendations from that analysis, the documentation burden on app owners is substantially reduced. The platform deduces the RBAC model rather than requiring a human to explain it.

AI-driven browser automation for non-API applications. The hardest onboarding cases are applications without usable APIs — legacy tools, niche software, applications that restrict API access behind expensive licensing tiers. Traditional IGA approaches require custom connector development for these apps, which is expensive, slow, and brittle. If the application changes its UI, the connector breaks.

The more durable approach is AI-powered browser automation: the platform navigates the application's interface the way a human administrator would, dynamically interpreting UI elements to discover users, read roles, and execute provisioning and deprovisioning actions. When the application's layout changes, the AI adapts rather than breaking. This removes the dependency on both API availability and technical documentation from the app owner — if a human administrator can log in and manage access through the UI, the platform can do the same.

The Discovery Staleness Problem

The observation from this thread that rings most true for teams running large backlogs: the data goes stale between discovery and onboarding. You finish documenting an application three months after you started, and the documentation no longer reflects reality.

The only way to solve this structurally is to move away from point-in-time documentation toward continuous discovery. Instead of gathering information about an application once and then governing based on that snapshot, the platform maintains ongoing visibility into the application's actual access state — what users exist, what roles they hold, whether that matches what it is supposed to be.

Continuous discovery does not require manual questionnaires. It requires the platform to maintain a live connection to the application and periodically reconcile actual access state against policy. For applications in the pre-built catalog, this is a configuration option. For non-API applications using browser automation, the same automation that handles provisioning can handle periodic discovery runs.

The implication for your backlog: if you onboard an application in a way that gives the platform ongoing visibility, the staleness problem largely disappears. The platform keeps itself current rather than depending on a human to re-document what changed.

What to Do With a 40-App Backlog Right Now

The backlog is probably not uniformly hard. A rough segmentation usually reveals something like:

• A handful of applications that are genuinely complex and will require significant work regardless of tooling
• A larger group of modern SaaS applications that would onboard in days if the platform had pre-built connectors for them
• Some applications where the access model is simple but nobody has gotten around to them

Triaging by complexity and pre-built connector availability lets you clear a significant portion of the backlog quickly while isolating the genuinely hard cases for dedicated attention. Applications that support SCIM and SSO and exist in the platform's pre-built catalog should not be in a three-month queue. Applications without APIs and with no documentation are legitimately hard and should be treated as such.

Separately, any application being purchased or evaluated now should be subject to a procurement standard: SSO and SCIM support before IT onboards it. The backlog you have is the result of years of purchases without that standard. The backlog you accumulate going forward is something you can control.

FAQ

Why does IGA application onboarding take so long?

Legacy IGA platforms require complete, manually documented access profiles — RBAC models, auth flows, integration points — before governance can begin. This documentation depends on app owners who often do not have the technical knowledge, and the process takes long enough that the information is outdated by the time onboarding completes.

How can you speed up IGA application onboarding?

Pre-built integration catalogs eliminate the technical discovery phase for modern SaaS apps. Centralizing authentication through an identity provider creates a repeatable onboarding path for compliant applications. Role mining from usage data replaces manual RBAC documentation. AI-driven browser automation handles non-API applications without custom connector development.

What is the best way to handle apps without APIs in IGA?

AI-powered browser automation navigates the application's UI to discover users, read roles, and execute provisioning actions — the same way a human administrator would. Unlike traditional RPA, AI-based automation adapts when the application's layout changes rather than breaking, making it more durable for long-term governance of non-API applications.

How do you manage an IGA application backlog?

Triage by complexity: applications with pre-built connectors and SCIM/SSO support can onboard quickly and should be separated from genuinely complex cases. Apply a procurement standard requiring SSO and SCIM support for all new SaaS purchases to prevent backlog growth. Use continuous discovery rather than point-in-time documentation to avoid staleness.