Identity governance has not stalled because CISOs lack controls or tools. It has stalled because most organizations are missing the operating fabric that makes federated identity governance scalable: a standard way to connect any application, normalize its identity and access data into a common schema, and bring it under a consistent governance, control, and evidence model.
That missing fabric is why so many identity governance programs look healthy after the first wave of applications. The directory is governed. HR is connected. Reviews run on time. A few major SaaS applications are in scope. Dashboards show activity. Audit evidence exists for the systems that made it into the model.
Then progress slows down and identity governance coverage stops expanding.
The next application needs new connector work. The one after that needs different mappings. Another defines roles differently. Another has unclear owners, strange entitlement structures, or custom approval patterns. Before long, each application becomes its own engineering and governance project. The issue is no longer whether the IGA platform can run reviews. The issue is whether the architecture and operating model can scale identity governance across the ERP, SaaS, custom applications, integrations, and non-human identities the business actually runs.
That is where most IGA programs stall.
The familiar two‑phase identity governance pattern
Most identity governance programs follow the same arc.
In phase one, the organization onboards the systems everyone agrees matter most for IGA: Directory Services, HR, ERP, and a handful of business‑critical SaaS applications. The work is heavy, but it gets done because the business case is clear and executive attention is still strong. This phase creates real value. Lifecycle controls improve. User access reviews become more structured. Audit evidence gets stronger. For those core systems, governance maturity genuinely moves forward.
In phase two, the application estate keeps expanding. More SaaS applications appear across finance, procurement, operations, and regional teams. Custom and on‑premises applications stay in place. Integration platforms, service accounts, API keys, bots, automation users, and AI agents multiply without clear ownership or regular review.
At that point, each new application starts to feel like its own mini‑project. New connectivity. New data interpretation. New schema translation. New approval logic. New review design. New exceptions. Progress slows to a crawl, not because the team lost interest, but because the identity governance operating model underneath the program was never designed to absorb applications at scale.
The result is a truncated identity governance program that is deep in a few places and shallow almost everywhere else.
Why every new application becomes an IGA bottleneck
When leaders say identity governance “stalled,” what they usually mean is that onboarding stopped scaling.
Every new system brings four recurring problems.
First, connectivity is different every time. One application exposes identity and access data through REST APIs. Another depends on SOAP. Another needs JDBC. Another sends flat files over SFTP. Another pulls from directories or proprietary interfaces. Before governance even starts, the team has to solve a new data acquisition problem.
Second, the identity and entitlement model is inconsistent every time. Users, roles, entitlements, transactions, and privileged actions are named and structured differently across applications. The identity team has to figure out what the application really means by a role, what counts as sensitive access, SoD-relevant access, privileged activity, or material risk.
Third, schema translation becomes custom work. Even once the data is extracted, it still has to be transformed into something the IGA or federated identity governance system can understand. That means mapping, normalization, enrichment, validation, and exception handling. In many organizations, this becomes hidden custom ETL work inside every onboarding effort.
Fourth, workflows, evidence patterns, and ownership models have to be reinvented. Every application arrives with different approval paths, review owners, exception rules, evidence expectations, and edge cases. Central teams end up designing user access review workflows for systems they do not actually own, which turns them into the permanent bottleneck for future onboarding and ongoing certification cycles.
None of these problems is surprising by itself. The problem is that they repeat hundreds of times, and identity governance onboarding never becomes easier or cheaper.
Industry commentary increasingly points to a common pattern: many IGA deployments struggle to meet coverage, timing, budget, or functional expectations once programs move beyond the first wave of applications.
The real issue is not effort. It is the identity governance architecture.
This is where the conversation about identity governance needs to change.
Most identity programs are not failing because they need more effort, better project management, one more connector, one more campaign, or one more central workflow. They are failing because there is no reusable fabric between fragmented application data and the governance layer above it.
Without that fabric, every new application forces the same cycle of custom connection, custom interpretation, custom transformation, custom ownership design, custom evidence requirements, and custom workflow design. Cost per application stays high. Time per application stays slow. The ongoing cost of each certification cycle remains heavy. The first 20 or 30 applications may still be justifiable. The next 200 are not.
That is why this is really a unit economics problem disguised as an integration problem.
If the marginal cost of onboarding the next application never drops, broad identity governance coverage will always remain out of reach. The long tail of applications becomes a permanent blind spot, even when those systems sit close to money movement, sensitive data changes, operational workflows, and critical approvals.
Boards and auditors do not care whether the blind spot came from connector limitations, mapping debt, or workflow design complexity. What matters is whether critical access and high‑risk activity are actually under policy, entitlement-level review, SoD analysis, privileged activity monitoring, remediation, and evidence
The missing layer: a standard federated governance and evidence fabric
To break this pattern, organizations need more than another round of custom integrations. They need a standard identity governance onboarding fabric that sits between the application estate and the governance model above it
In practice, that means three repeatable steps — a connect‑transform‑govern pattern:
- Connect: A reusable way to reach ERP, SaaS, custom applications, databases, files, directories, and integration platforms without turning every new source into a separate project.
- Transform: A repeatable way to normalize users, roles, entitlements, ownership data, transaction context, privileged activity, and control-relevant events.
- Govern: Once normalized, the ability to apply shared policies, fine-grained SoD rules, ownership models, entitlement-level user access reviews, mitigation, remediation, privileged activity monitoring, and evidence standards consistently through a central federated governance and evidence layer..
This fabric is what turns a collection of integrations into a federated identity governance model that can actually scale.
Without a standard connect‑transform‑govern pattern, identity governance onboarding remains trapped in a project‑by‑project model. With it, onboarding starts to behave like an operational process instead of a custom build, and full application coverage becomes a realistic goal.
From mini‑projects to an application onboarding factory
Once the right fabric is in place, onboarding no longer has to feel bespoke. It can operate like an application onboarding factory for identity governance.
An onboarding factory standardizes how systems are brought under governance. The connection layer becomes reusable. Transformation follows common rules. Governance patterns become repeatable. Ownership and evidence models become clearer. Teams stop redesigning the process from scratch every time a new application is added.
That changes the economics of the identity governance program:
- Cost per application drops because less custom work is needed.
- Time to onboard falls because teams can reuse proven patterns.
- More applications can move in parallel because progress is no longer limited to a small set of specialists.
- Certification quality improves because reviewers see entitlement-level access, clearer ownership, and more consistent risk context instead of only abstract business roles.
Most importantly, identity governance coverage starts to expand beyond the core systems into the finance, operations, ERP, SaaS, custom applications, and integrations where real access and transaction risk lives.
That is the real promise of an identity governance onboarding factory. It does not just make integrations easier. It gives the organization a credible path to govern the broader estate instead of stopping at the usual core systems.
Why coverage is the metric that matters in identity governance
This is also why traditional IGA success metrics can be misleading.
Many programs still report on how many access reviews were launched, how many approvals were completed, how many remediation tasks closed, or whether campaigns met SLA. Those are workflow metrics. They say something about activity inside the governed perimeter. They say almost nothing about the size of that perimeter.
A program can look mature while leaving large parts of the environment outside governance.
That is why identity governance coverage metrics matter more than workflow volume.
The first question is application coverage: what percentage of critical applications is actually under identity governance, with visible access structures, assigned ownership, applicable policy, regular reviews, and defensible evidence?
The second is identity coverage: what percentage of human and non-human identities, including service accounts, API keys, bots, and integration users, is governed under consistent lifecycle, ownership, entitlement visibility, review rules, and evidence standards
The third is activity coverage: what percentage of privileged, SoD-sensitive, and control-relevant activity in critical systems is actually taking place inside the governed perimeter?
These coverage metrics give leadership a more honest picture of identity governance program health. They show where governance is deep, where it is shallow, and where it is missing entirely.
Why time‑to‑coverage matters just as much
Coverage shows the current state. Time‑to‑coverage shows whether that state can improve fast enough.
Time‑to‑coverage asks how long it will take to bring a meaningful share of the critical estate under identity governance. Not eventually. Not in principle. In operational time.
- How long to reach 50% of critical applications under governance?
- How long to reach 80%?
- How long to bring a newly introduced high‑risk SaaS application, integration, or automation under shared policy and evidence?
If those timelines are measured in years, or if no believable path exists at all, then the problem is not a temporary backlog. The identity governance operating model does not scale.
Time‑to‑coverage makes that visible early. It shows whether federated identity governance is expanding at the speed risk demands, or whether the program has simply become static while the environment keeps changing around it.
This chart is an illustrative model. It visualizes a common pattern we see in identity governance programs: workflow activity keeps rising while coverage plateaus after the first wave of applications, until the onboarding and operating model change.
Why federated identity governance is the operating model that fits
A scalable technical fabric is necessary, but it is not enough on its own. The operating model has to change too.
In a centralized IGA model, the identity team ends up owning every connector, every mapping, every ownership decision, every policy adjustment, every workflow, every exception, and every edge case. That may work for a small number of core systems. It breaks once the organization tries to scale governance across ERP, finance applications, HR platforms, SaaS, operations tools, and nonhuman identities.
Federated identity governance is what makes broader coverage operational.
In a federated model:
- Central teams define standards, risk models, policy guardrails, and reporting expectations.
- Application and business owners take on local decisions.
- They help define roles, validate entitlements, approve access in context and participate in user access reviews.
- They own exceptions closer to the processes where access is actually used.
This is not a loss of control. It is a redistribution of execution.
Policy remains centralized. Oversight remains centralized. Evidence standards remain centralized. But decisions and workflow execution move closer to the systems and business processes where they can be made intelligently and quickly.
That is how identity governance coverage expands without turning the central team into a permanent choke point.
What changes when the federated model works
When the right architecture and federated identity governance model come together, several changes become visible.
The next application looks more like a repeatable onboarding exercise than a custom project. Application owners know their role in reviews and approvals. Nonhuman identities are treated as governed objects rather than technical leftovers. Audit gets more consistent, auditor-verifiable evidence. Leadership can see not just workflow activity, but actual coverage and time‑to‑coverage improving over time.
The core question also changes.
Instead of asking, “How many campaigns did we run?” leadership starts asking, “What percentage of our critical application estate is actually governed, and how fast is that percentage improving?”
That is the question that separates identity programs that look busy from programs that are actually scaling.
What to do next
If the program feels stuck after the first 20 to 30 applications, that should not be treated as normal. It should be treated as a signal that the identity governance architecture and operating model need to change.
Start with three steps:
- Assess identity governance coverage. Identify how many critical applications, human and non-human identities, entitlements and high‑risk activities are truly under governance today.
- Measure time‑to‑coverage. Estimate how long it would take, at the current onboarding rate, to reach meaningful coverage thresholds across the estate.
- Inspect the onboarding model. If every additional application still looks like a mini‑project with custom connection, custom mapping, custom transformation, custom ownership design, and custom evidence requirements, the issue is structural.
That is the bottleneck to break.
And once that bottleneck is visible, the path forward becomes clearer: adopt the standard fabric that makes federated identity governance operational, turn onboarding into a repeatable application onboarding factory, and measure success by coverage and time‑to‑coverage instead of workflow activity alone.
