Your IGA platform is live, reviews run, dashboards look healthy—yet you still see repeat audit findings, unmanaged SaaS, privileged service accounts, and non‑human identities with no clear owner.
This is happening while identity attacks dominate the threat landscape: recent data shows nearly 80% of breaches involve stolen credentials or other identity‑based methods. And non‑human identities now outnumber human identities by at least 50 to 1 in many enterprises.
The common thread is the operating model. A centralized, project‑by‑project IGA approach pushes every connector, data mapping, workflow, and review through one team. As SaaS, integrations, and automations grow, that team becomes the bottleneck. Coverage stalls around 20–30 core systems; the rest of the estate runs on local admin practices, spreadsheets, and email approvals.
In other words, the tool is doing what it was designed to do. The way you distribute governance work is not. Until governance shifts from centralized execution to centralized policy with distributed execution, you will keep seeing the same pattern: strong control in a narrow center, weak or no control at the edges where new risk appears.
The playbook you followed and why it stalled
Most CISOs, CIOs, and identity leaders followed a sensible sequence.
First, get the foundations in place: directory, HR, ERP, and a small set of flagship SaaS applications. Implement joiner-mover-leaver workflows. Stand up access reviews. Strengthen audit evidence where it matters most.
That work typically succeeds and creates real value in the initial scope.
The challenge begins when the application estate keeps growing. Finance, procurement, operations, and regional teams adopt their own SaaS platforms. Custom and on-prem applications remain in use. Integration platforms multiply. Service accounts, integration users, bots, API credentials, and AI agents spread across the environment with far less lifecycle discipline, ownership, and certification rigor than workforce identities.
The scale of that shift is easy to underestimate. Many organizations now operate with large pockets of unmanaged SaaS, and some recent research suggests that as much as 90% of SaaS applications and 91% of AI tools inside organizations remain unmanaged. At the same time, nonhuman identities now outnumber human identities by roughly 50 to 1 in many environments, and a significant share of them have no clear owner.
Every onboarding request queues behind the same central specialists:
- connector development
- entitlement mapping
- workflow design
- policy configuration
- access review setup
- exception handling
- audit support
As the business accelerates, governance slows down.
Adding more items to the roadmap does not solve this. It simply extends a model that was not designed to scale in the first place.
When project metrics hide a governance coverage problem
Most identity programs are still measured as implementation projects rather than governance operating models.
These numbers are straightforward to report, but they describe activity inside the platform, not control across the estate.
For CISOs, that creates four recurring pain points: audit findings that keep returning, unclear ownership for access exceptions, unmanaged privileged activity outside core systems, and no defensible answer when the board asks how much identity risk is actually governed.
Two questions cut closer to what boards, audit, and security leaders actually care about: how much of the true risk surface is under effective governance today, and how quickly can new applications, identities, and high-risk activities be brought under that level of governance when they appear.
Those questions point to two more meaningful metrics.
Coverage is the new maturity model.
- The first is governance coverage: the share of SOX-in-scope and business-critical applications, human and nonhuman identities, privileged roles, toxic combinations, and high-risk transactions that are under defined policy, monitoring, review, remediation, and evidence.
- The second is time-to-coverage: the time it takes, from the moment a new ERP module, SaaS platform, integration, or automation goes live, until it reaches that governed state.
Viewed through this lens, many “completed” IGA deployments look different. They have strong controls in a narrow band of core systems, while large parts of the estate rely on local admin practices, spreadsheets, email approvals, and other ad-hoc mechanisms.
This is also why many programs feel more mature than they are. In one recent IAM maturity report, only 28% of respondents said access management was governed with policy or process and integrated into the IAM platform. The gap is not just in technology. It is in how success has been defined.
Why centralized IGA turns identity teams into a permanent bottleneck
Under a centralized model, almost everything flows through a small group of specialists.
They solve connectivity for each application: REST here, SOAP there, JDBC somewhere else, files over SFTP for another. They translate local data models into something the platform can handle: roles, entitlements, high-risk actions, ownership, privileged access. They build and adjust workflows, approvals, and reviews for systems they do not manage day to day. They respond to change requests, exceptions, and audit queries across dozens or hundreds of environments.
That structure can work for a limited set of systems. It often does not scale to hundreds.
At some point, the central team’s capacity and attention become the limiting factors on coverage and time-to-coverage. The business continues to move, applications continue to appear, and identities continue to proliferate. When the formal model cannot keep up, informal workarounds fill the gap.
The issue is not effort or intent. It is the expectation that a small central team and a central workflow engine can remain the execution layer for governance across an entire enterprise.
The Transition Required: Centralized Policy, Distributed Execution
There is another dimension that traditional IGA architectures rarely address explicitly: the need for a repeatablel onboarding fabric.
Most implementations treat connectivity, transformation, and normalization as one-off project tasks. In practice, they are the recurring work that determines whether coverage can ever extend beyond the first wave of systems.
Without a universal fabric, every new application is a bespoke exercise. Time-to-coverage remains high because each onboarding effort starts from scratch. Nonhuman identities often remain outside standard lifecycle and review patterns because integrating their data is too costly or brittle.
A modern identity governance program needs three clearly defined layers: a data fabric, a control fabric, and a federated operating model.
First, repeatable connectivity: a connector layer capable of reaching ERP, SaaS, databases, files, directories, and integration platforms without treating each system as a custom engineering problem.
Second, standardized transformation: a data layer that converts system-specific models into a universal governance schema — users, roles, entitlements, transactions, ownership, and control-relevant activity — in a repeatable way.
Third, a federated control plane: a governance layer that keeps policy intent, risk models, lifecycle patterns, reviews, and evidence standards centralized, while allowing execution — access decisions, approvals, certifications — to sit with application and process owners who understand local context.
Without these three layers working together, coverage and time-to-coverage remain constrained by the capacity of the central team, regardless of which IGA tool is in place.
Federated identity governance, built on the right fabric
Federated identity governance is a response to both the organizational and technical realities described above.
In a federated model, central security and identity teams define global policies, SoD rules, risk models, minimum control standards, and evidence requirements. Business domains and platform teams own how those policies are applied in their systems, including local roles, approvers, and application-specific rules. Application and process owners have clear responsibility for day-to-day access decisions, reviews, and exceptions in their areas. The control plane provides a consistent, enterprise-wide view of access, high-risk actions, and approvals.
This approach keeps policy and oversight centralized while distributing execution to where activity actually occurs. It reflects how large organizations already operate, rather than assuming all meaningful control can be run from a single point.
However, a federated operating model alone is not enough. If each domain still has to solve connectivity, transformation, and workflow design independently, the organization has simply moved the complexity from the center to the edge.
Federation needs to sit on top of a shared onboarding fabric. Otherwise, the economics of onboarding remain unchanged.
How Technology Should Support the Operating Model
Federated identity governance requires technology that supports distributed execution rather than reinforcing centralized bottlenecks.
That means:
-
universal connectivity rather than bespoke integrations
-
standardized normalization rather than custom mapping
-
centralized policy
-
delegated execution
-
shared evidence
Whether organizations extend an existing IGA platform or introduce complementary capabilities, the objective is the same: reduce the effort required to bring new applications under governance while maintaining consistent policy and oversight.
SafePaaS was designed around this model by combining application onboarding, normalization and a federated control plane that extends existing IAM and IGA investments rather than replacing them.
Five questions to stress-test your governance operating model
A brief set of questions can clarify whether the current model can realistically get you where you need to go.
- What percentage of SOX-in-scope and other business-critical applications are under identity governance today — not just integrated for SSO, but under policy, monitoring, review, and evidence?
- How long did it take to bring the last new ERP module or SaaS application to that standard, end-to-end?
- What portion of service accounts, integration users, bots, API credentials, and AI agents have named owners, approved purpose, least-privilege access, lifecycle controls, and periodic certification?
- For a typical new application, how much of the onboarding effort is still bespoke connector setup, data mapping, and workflow design?
- In a representative business application, who effectively owns access decisions and exceptions: the application owner, or a central team that does not run the process day to day? If your identity team doubled in size tomorrow, would governance coverage double or would onboarding still remain largely bespoke?
If the answers point to limited coverage, long time-to-coverage, significant custom work per application, and ambiguous ownership, the issue is unlikely to be resolved by more configuration on the existing toolset. It points to the absence of the universal onboarding fabric and federated control plane that make broad, sustainable coverage achievable.
A more scalable path forward
Many organizations have already done the difficult work of establishing identity governance in core systems. The next challenge is to extend that governance across the wider application and identity surface without recreating the same bottlenecks.
A more scalable path typically includes redefining success around coverage and time-to-coverage, rather than just project completion metrics; shifting from an IT-centric execution model to a federated one, with clearly defined responsibilities for central teams, domains, and application owners; and introducing a universal onboarding fabric for connectivity and normalization, so new systems can be brought under governance through repeatable patterns instead of bespoke projects.
SafePaaS is designed to support that shift. It combines the connector and transformation with a federated control plane so organizations can finish what IGA started: governing ERP, SaaS, custom applications, and nonhuman identities under one set of policies, controls, and evidence.
The next generation of identity governance won’t be defined by who has the biggest IGA deployment. It will be defined by who can continuously extend governance across an ever-changing application and identity landscape without creating new bottlenecks.
