Most Identity Governance and Administration programs don’t fail; they stall. The first wave of systems goes live with heavy effort—directory, HR, ERP, and a few key SaaS platforms—and the dashboards look reassuring. Underneath, finance workflow tools, regional SaaS, procurement platforms, custom apps, and integration users still run on local admin practices, spreadsheets, and email approvals. Service accounts and automations can move money or change master data with almost no consistent oversight, so SOX and ITGC requirements apply on paper but many organizations cannot credibly prove governance across the estate.
That gap does not exist because your IGA product is bad; it exists because the onboarding model never changed. Every new application still behaves like its own integration project, so unit economics never improve and coverage never catches up. Many deployments struggle once they move beyond the first wave, while the average company now uses roughly 100+ SaaS applications and non‑human identities outnumber human users by about 50 to 1. You don’t close that gap by adding a few more connectors and review campaigns. You close it by standardizing how applications, identities, and high‑risk actions come under governance.
That is the role of an application onboarding factory: a repeatable way to bring any critical application—including the non‑human identities behind its integrations and automations—under federated identity governance without turning each one into a custom project.
Why every new application becomes a mini‑project
Most programs stall in the same way for the same reasons.
Every additional application arrives with its own combination of:
- Connectivity quirks: REST in one place, SOAP or proprietary APIs in another, flat files and JDBC somewhere else.
- Different data models: inconsistent ways of representing users, roles, entitlements, and “privileged” access.
- Local business rules: different owners, approvers, escalation paths, and exceptions.
So each onboarding effort turns into a familiar, expensive pattern:
- Build or adapt a connector.
- Reverse‑engineer the access model and what “high‑risk” means locally.
- Hand‑craft mappings and transformations.
- Design one‑off approval and review workflows.
The cost and time per application never meaningfully go down. The central team becomes the choke point for every connector, mapping, and campaign. You end up with deep control in a handful of systems and thin or informal control across the rest.
If you measure success by coverage and time‑to‑coverage—how much of your genuinely critical estate is governed, and how quickly new risk comes under control—it’s obvious this one‑off project model can’t keep pace with SaaS growth or the explosion of non-human identities.
From projects to an onboarding factory
An application onboarding factory replaces that one‑off pattern with a standard one:
- Connect
Reach the application through a reusable connector layer that speaks the protocols you already run—databases, SaaS APIs, directories, files, integration platforms. - Transform
Normalize users, roles, entitlements, and high‑risk activity into a common data model that your governance platform understands. - Govern
Apply shared policies and controls—ownership, segregation of duties, sensitive access checks, lifecycle patterns, certification workflows—consistently across applications.
Many vendors claim they can do this but, most IGA and access review tools only start once the data is already clean and normalized. Connectivity is handled by a patchwork of connectors and scripts. Transformation lives in custom ETL or one‑off integration projects. Governance runs on top of whatever data it gets.
That gives you automation for a small, well‑behaved core. It does not give you a factory that can absorb the complexity of the whole estate.
To get the factory you’ve sketched on the whiteboard, you either:
- Assemble your own stack—connectors, ETL, data platform, plus a governance layer—and invest continuously in keeping it all working, or
- Use a platform that is designed to connect, transform, and govern as one fabric.
A platform like this has to be described in concrete terms: a unified system that connects to every app, normalizes their access models, and runs consistent workflows for provisioning, approvals, and reviews. The focus is on making onboarding repeatable and governed by design, so each new application can be brought under control without custom projects or local exceptions.
The fabric that makes the factory real
A true onboarding factory platform doesn’t bolt governance on top of someone else’s data plumbing; it brings connectivity, transformation, and federated control into a single operating model.
Three capabilities make that possible.
1. Universal connectivity – stop reinventing access
You need a connector layer that can reach into ERP systems, SaaS applications, databases, directories, and file sources using the protocols you already use—REST, SOAP, JDBC, SFTP, and more.
The point isn’t just having “lots of connectors.” It’s turning connection and discovery into a repeatable, governed step. A new application no longer starts with “how do we even get to this data?” It starts as a standard onboarding candidate that the connector layer can reach in a known way.
Without that layer, you’re back to custom integrations and vendor‑specific plugins every time you expand scope.
2. Standardized transformation – make onboarding a pattern, not a project
Most tools sidestep the hardest part: turning inconsistent application data into something governance can use at scale. That work gets buried in ETL jobs, custom scripts, and consulting projects.
An onboarding factory platform puts that logic into a visible, repeatable engine. Teams use a guided, no‑code experience to:
- Select source objects (users, roles, entitlements, transactions).
- Map local fields into a universal schema.
- Define, test, and version transformation rules.
- Validate the final dataset before it feeds governance.
Patterns you build for one finance SaaS app can be reused for the next three with minor tweaks. You’re not starting from zero each time; you’re extending a library of onboarding patterns.
Without this kind of transformation fabric, you can have the best certification workflows in the world and still be stuck, because every new application demands fresh ETL and schema work buried out of sight.
3. Federated control plane – governance by design, not by accident
On top of connectivity and transformation, you need a federated control plane for policy, risk, and evidence.
Central teams use it to define:
- Global standards for access, segregation of duties, and high‑risk actions.
- Minimum requirements for reviews, approvals, and logging.
- How evidence should look for SOX, ITGC, and internal audit.
Application, platform, and process owners then operate inside that framework:
- They use normalized data instead of raw application dumps.
- They make access decisions with clear ownership and risk context.
- They run reviews and manage exceptions in patterns the central team can trust.
That is federated identity governance in practice: centralized intent and visibility, distributed decisions and enforcement, all running on the same onboarding fabric.
Why this effectively narrows the field to one kind of solution
Could someone theoretically build their own version of this with multiple products and a lot of engineering? Yes. But the bar is high:
- A universal connector layer that can handle the mix of ERP, SaaS, databases, files, and directories you actually run.
- A transformation engine that turns any application’s model into a reusable, governed schema without writing custom ETL for each one.
- A federated control plane that ties policies, access decisions, reviews, and evidence back to that shared data model.
Most IGA and user access review tools give you the last part, assuming the first two mysteriously already exist. Most data integration tools give you the middle, but nothing about access decisions, segregation of duties, or audit‑ready evidence.
A true onboarding factory platform brings all three together as one system. That’s what turns the “application onboarding factory” from an idea into something you can actually run.
In practical terms, you have two options:
- Keep treating every new application, integration, and machine identity as a mini‑project, hoping your IGA deployment doesn’t join the many that end up in “distress.”
- Standardize on an onboarding factory pattern—connect through a universal connector layer, transform through a governed data fabric, and govern through a federated control plane—and bring every critical application under governance through a repeatable pattern.
The first option is how you got stuck in the first place. The second is how you finally finish what IGA started.
