Nobody wants to admit it, but many IGA programs end up sharing the same challenge:
“We are unlikely to onboard everything through the current model. We’ll get the primary applications done and manage the rest in spreadsheets.”
The tools are not the only issue. You can always buy another connector, dashboard, workflow wizard, but what actually breaks when you try to scale identity governance is the operating model wrapped around it. The more coverage you push through a centralized model, the more it fights back—through bloated certifications, role models nobody trusts, brittle SoD rules held together by exceptions, and identity data that never quite lines up.
This isn’t a story about “optimizing campaigns” or “improving adoption.” It’s a stress‑test: if you doubled your in‑scope applications and nonhuman identities in the next 12–18 months, where would your current IGA model snap first—and why do federated models hold up better under the same pressure?
The real IGA stress test: coverage and time‑to‑coverage
If you strip away the platform branding and project milestones, identity governance comes down to two questions:
- How much of our real risk surface is under effective governance?
- How quickly can we bring new risk under that same standard?
That is coverage and time‑to‑coverage.
Coverage is not “number of connected systems” on a dashboard. It’s the share of your truly critical estate that is actually governed:
- Which SOX‑in‑scope and business‑critical systems are under defined policy, monitoring, and periodic review.
- What percentage of human and nonhuman identities in those systems follow standard lifecycle and review patterns.
- Which high‑risk actions—payments, approvals, master‑data changes, configuration changes—are subject to enforceable controls and evidence.
Time‑to‑coverage is how long it takes to move a new application, integration, or automation from “we found it” to “it meets our governance standard.” When finance adds a new SaaS approval tool or an integration platform starts posting journals, how many days or weeks pass before its identities, roles, and critical actions are discovered, onboarded, and reviewed like everything else?
By those measures, many IGA deployments that look fine on paper are failing the stress test. They deliver strong control where they are deployed—joiner–mover–leaver for ERP and HR, quarterly reviews on a narrow set of systems, dependable evidence for the same core stack every year. Meanwhile, risk spreads outward into SaaS, regional finance tools, workflow platforms, custom apps, and nonhuman identities that sit outside formal governance.
Dashboards may say “green.” Coverage and time‑to‑coverage say something else.
What breaks first when you scale centralized IGA
When you try to expand coverage beyond the first 20–30 systems on a centralized operating model, four failure modes show up.
Certification fatigue: when reviews turn into noise
Centralized IGA loves campaigns. At first, reviews feel like visible progress: more systems onboarded, more approvers involved, more reports for audit.
Then you expand the scope. Finance adds SaaS tools that can move money. Operations adds workflow platforms. Regional teams bring in their own systems. The same central team is now expected to design and run reviews across dozens of heterogeneous applications.
For reviewers, it looks like this:
- They receive large certification campaigns that mix systems they understand with systems they’ve never heard of.
- Entitlements are exposed as cryptic role names and technical codes, with inconsistent descriptions and minimal risk context.
- They’re given tight deadlines and reminded repeatedly until they click “approve” on long lists they can’t truly evaluate.
Rubber‑stamping is inevitable. Not because people don’t care, but because the centralized model is asking them to make high‑quality decisions on low‑quality information, at a scale that no one can sustain.
You see it in the data and the behavior:
- Campaigns that technically complete on time with almost no entitlement changes.
- Reviewers complaining more about “pointless emails” than about actual access risk.
- A widening gap between what audit assumes those reviews mean and what reviewers are actually doing.
Tweaking reminders or UI does not fix this. The problem is structural: one central team designs generic campaigns for everyone, while everyone treats those campaigns as a quarterly chore. As you add systems, you scale the noise, not the judgment.
Role explosion: models nobody trusts
Role‑based access control is supposed to make governance scalable. In practice, centralized role models tend to collapse under their own weight as coverage grows.
In a centralized IGA model:
- Role design sits with IAM or central IT, not with the people who run the processes behind those roles.
- Each new application arrives with its own local roles and entitlements, which are then wrapped in enterprise roles that don’t quite fit how work actually gets done.
- Over time you accumulate global roles, app roles, composite roles, and “temporary” roles that never get retired.
You end up with symptoms everyone recognizes:
- Thousands of roles, many used by only one or two people.
- Overlapping role definitions with subtle differences no one can explain.
- Business owners who no longer trust the catalog and fall back to local groups, manual approvals, or direct assignment.
The more you push centralized modeling to keep up with more systems and more teams, the faster this mess grows. Every attempt to “rationalize roles” turns into another project that only solves a slice of the problem, and only for a while.
At scale, the role model stops being a tool for governance and becomes another thing people work around.
SoD brittleness: rules held together by exceptions
SoD is another area where centralized IGA looks strong at first and then slowly cracks as you try to scale.
Most SoD libraries are written around a small set of core systems—primarily the ERP and a few major finance and procurement platforms. They use the roles, transaction codes, and data structures of those systems as their frame of reference.
As risk moves into SaaS and regional platforms, three stresses hit the centralized model:
- Extending SoD logic into each new system becomes a custom initiative—new mappings, new technical rules, new test cycles—handled by the same central team.
- When that team falls behind, changes to rules either don’t propagate or are watered down to remain manageable.
- Business units, faced with rigid rules that don’t fit how their process actually runs, request “temporary” exceptions that never close.
The result is a SoD landscape that looks thorough on paper but behaves poorly under change:
- Difficult to adapt when processes or applications change.
- Hard to understand outside the few people who wrote the rules.
- Increasingly dependent on untracked or long‑lived exceptions.
The more systems you add, the more brittle this becomes. A single policy change can require coordinated updates across multiple platforms, teams, and spreadsheets. You can push this structure for a while, but under real stress it turns into a pile of technical debt.
Identity data inconsistency: every app is a mini‑project
The least visible, and most fundamental, stress is identity data inconsistency.
Every system models identities, access, and activity differently—user objects, group structures, roles, entitlements, transaction logs, configuration records. That diversity is normal. What breaks centralized IGA is how it tries to normalize that diversity at scale.
In most programs:
- Connectivity is handled case by case: REST here, SOAP there, JDBC for one system, flat files over SFTP for another, direct directory integration for a fifth.
- After connection, each application requires custom mapping and transformation before the governance platform can use its data—field by field, object by object.
- Much of that logic lives as bespoke ETL in scripts, integration tools, or hidden configuration that only a few specialists really understand.
At small scale, this is painful but manageable. At large scale, it shuts down expansion. Each new application becomes a mini‑project with its own connector work, mapping rules, schema translation, workflow design, and testing cycles.
From a CISO’s vantage point, the consequence is simple:
- Cost per application onboarded stays high.
- Time per application stays long.
- The backlog of “next wave” systems never really clears.
Coverage stalls around the original core. The long tail remains under shadow governance.
Why centralized operating models amplify all four stresses
These four failure modes are symptoms of the same underlying design choice: everything important flows through a central team and a central platform.
That team is expected to:
- Connect every in‑scope system.
- Normalize every data model.
- Design and maintain roles and policies.
- Configure certifications and workflows.
- Author and tune SoD rules.
- Own exception queues across the estate.
When the estate was smaller and slower, centralization felt efficient. Today it turns into a permanent bottleneck.
From the outside, it can still look successful. The IGA platform shows more integrated systems, more campaigns, more approvals. But those are implementation statistics, not risk outcomes. They say “we did a lot of work,” not “we govern most of the places where money can move and data can be changed.”
Under stress—more SaaS, more automation, more nonhuman identities—the centralized model behaves predictably:
- Certification volume grows faster than anyone’s capacity to review.
- Role catalogs grow faster than anyone’s ability to understand them.
- SoD updates become slower and more fragile as they spread across more systems.
- Integration work absorbs more time, leaving less capacity to tackle the backlog.
Coverage plateaus. Time‑to‑coverage stretches. And the systems that matter most in day‑to‑day operations often live outside the formal perimeter.
You can’t fix that with more dashboards. You fix it by changing the operating model.
How federated identity governance absorbs the same stress
Federated identity governance is not “yet another IGA platform.” It is an operating model and control‑plane architecture built to survive the stresses that break centralized deployments.
Two design choices matter:
- Centralize intent and oversight, not every decision. Policy, risk models, SoD patterns, standards, and evidence expectations live in a control plane you can show to audit and the board.
- Distribute execution and ownership. Application and process owners implement those standards locally—using their own roles, workflows, and logs—but within common patterns and guardrails.
This only works if you are deliberate about where things live:
- Identity sources (directories, HR, authoritative systems) stay where they are.
- Execution systems (ERP, SaaS, custom apps, integration platforms, infrastructure) keep doing the work they already do.
- Federated governance control plane sits above them, coordinating policies, ownership, onboarding patterns, and evidence across domains.
Once you make that separation, you can let each stress land in a place where it can be absorbed instead of amplified.
Certifications with local ownership and shared standards
Under a federated model:
- Central teams define what a “good” review looks like: minimum data per entitlement, risk scoring, frequency, evidence.
- Application and process owners define entitlements, groupings, reviewers, and review flows for their systems, using templates that enforce the central standard.
- Data is normalized once through a shared connect–transform–govern pattern, so that reviewers see consistent, meaningful descriptions and risk indicators, regardless of the underlying system.
Campaigns become smaller, sharper, and owned by the people with context, not broadcast from one place to everyone else.
When you push more coverage through this model, you add more targeted reviews, not more noise in the same inboxes. Review quality can improve as coverage expands because each domain is accountable for its own slice of the picture under clear rules.
Role modeling where the process lives
Federation shifts roles back to where they belong: close to the applications and processes they represent.
- Central teams define common patterns and constraints: how to tag roles, how to classify risk, what SoD boundaries matter, and what metadata is required.
- Application owners define and maintain roles that make sense in their context, then map them into a universal schema the control plane uses for analysis and reporting.
- Because the mapping is standardized, you can still answer cross‑system questions—“who can approve payments?”—without forcing every app into a single global role hierarchy.
The stress of change—new apps, new processes, reorganizations—lands with the people who understand those changes, bounded by standards that keep the overall model coherent.
SoD and controls as patterns, not hard‑coded rules
In a federated model, SoD is expressed as patterns and guardrails in the control plane, not just as hard‑coded rules in one IGA engine.
- SoD policies are written once in business language: which combinations of capabilities or approvals are toxic.
- Each application maps its roles, transactions, and configuration objects to those patterns during onboarding, using a standard template.
- Exceptions are requested and approved locally but logged, monitored, and periodically reviewed centrally.
When a policy changes, the control plane drives that change through the existing mappings rather than triggering a fresh round of bespoke rule‑writing in every system.
You still have to manage change. But the effort scales with the number of patterns and domains, not with every individual rule instance scattered across platforms.
A universal onboarding fabric instead of bespoke integrations
Federated governance depends on a standardized way to connect systems and transform their data—what you might think of as an application onboarding factory.
Two capabilities underpin that factory:
- A universal connector layer that knows how to talk to ERP, SaaS, databases, files, and directories in the ways they already support, so “connect” is a solved problem.
- A transformation engine that guides teams through mapping local identity and access data into a shared schema, so you don’t keep writing one‑off ETL.
On top of this fabric, every in‑scope system follows the same pattern:
- Connect through the universal connector.
- Transform and normalize into the shared schema.
- Govern through the control plane—policies, reviews, SoD, monitoring, evidence.
That pattern is what changes the economics. Onboarding stops behaving like a bespoke project and starts behaving like a repeatable process. Cost per application falls. Time‑per‑application falls. Parallel onboarding becomes realistic.
Crucially, this works for nonhuman identities as well as human ones—service accounts, integration users, bots, and agents can be onboarded, owned, and reviewed through the same fabric and control plane.
Rerunning the stress test on a federated model
If you rerun the same stress test—coverage and time‑to‑coverage—on a federated operating model, you’re testing a different set of assumptions.
Under centralized IGA, coverage stutters because every new system depends on the same small team for integration, modeling, policies, and reviews. Time‑to‑coverage stretches because there is no standard pattern; each application is its own mini‑project. Meanwhile, certification fatigue, role explosion, and SoD brittleness get worse as you add more into the same funnel.
Under a federated model with a real control plane and onboarding fabric:
- Coverage can extend out to the long tail of ERP modules, SaaS, custom apps, and nonhuman identities because each domain follows a consistent onboarding pattern and owns its piece of execution.
- Time‑to‑coverage shrinks because connection, transformation, and control application are standardized; teams don’t start from a blank page for every new system.
- Certifications, roles, and SoD rules hold up better under load because you’ve separated global intent from local execution and given each domain clear responsibility inside shared guardrails.
The board doesn’t care whether you call this IGA, GRC, or something else. They care about whether you can answer three questions credibly:
- What percentage of our critical applications—human and nonhuman access—are under effective governance?
- How long does it take us to bring a new in‑scope system or automation under that same standard?
- When something changes, can we show who owns it, what policy applies, and what evidence we have?
Federated identity governance is about being able to answer with evidence: which systems and identities are governed, how quickly new risk comes under control, and who owns the decisions.
