Nine failure modes, one root cause pattern. This piece traces the most common IGA implementation failures, low adoption, stalled pilots, integration surprises, back to three decisions that are usually made early, often implicitly, and almost always before anyone notices they're decisions at all. Fix one of the three and several symptoms disappear together. Patch a symptom without touching its root, and the same failure returns under a different name a few months later.
Cataloging failure modes is the easy part. The harder, more useful question is: what decision, made once, is capable of producing this many different failures?
Run that question against nine common failures in an IGA implementation and they collapse into three root causes.
Fix one of these three and several symptoms disappear at once. Miss it, and no amount of symptom-level patching, more training, a longer pilot, more connectors, holds for long. The common failure modes in SaaS environment are well documented elsewhere on blog. This piece is about what's underneath them.
Demonstrating the Method: Tracing One Symptom to Its Root
Take a familiar symptom: low adoption six months after go-live. Managers aren't completing reviews. Employees are emailing IT for access instead of using self-service. The platform works exactly as configured. Nobody's using it.
The instinct is to treat this as a training problem or a communication problem. Running the "why" question repeatedly gets somewhere different.
- Why is adoption low? Managers don't see the reviews as something they're accountable for.
- Why don't they see it that way? Nobody explained what the review interface would ask of them or why it mattered, before it showed up in their inbox.
- Why weren't they told earlier? They weren't part of defining what the platform needed to do in the first place.
- Why weren't they part of that? The requirements process was run entirely by IT and security, without HR, compliance, or the managers who'd actually use the review workflow.
- Why did only IT and security run it? Because the purchase was scoped from the start as a security tool acquisition, not as a program that would change how multiple departments operate.
Five questions in, "low adoption" turns out to be Root Cause A wearing a different name. Training won't fix it, because training addresses a knowledge gap, and the actual gap is that the people being asked to adopt the tool were never asked what it needed to do. That's a five-months-earlier problem showing up as a today problem.
Root Cause 1: IGA Gets Owned as a Tool Purchase, Not a Program
This is the decision, usually made implicitly rather than on purpose, to treat IGA as something IT or security acquires and configures, rather than as a cross-functional change to how the organization handles access. It shows up in small ways early: budget gets requested as a single department's line item, the RFP gets written by one team, and the kickoff meeting has one department in the room.
Security or compliance usually has the most urgent, most fundable reason to move first, an audit finding, a near-miss, a customer questionnaire, so they become the natural owner by default. Nobody makes a deliberate decision to exclude HR, finance, or app owners. It just doesn't occur to the team driving the purchase that those groups have requirements of their own, because the project doesn't feel cross-functional from where they're sitting.
That's how one early, mostly unnoticed choice about ownership ends up producing three distinct symptoms downstream:
Symptoms it produces:
- Misaligned stakeholders. Requirements reflect IT's priorities alone, so compliance's evidence needs, HR's onboarding experience, and reviewers' usability needs never make it into the requirements document. (Here's how to run visibility-first stakeholder alignment so this gap never forms.)
- Resource underestimation. A tool purchase gets staffed like a tool purchase, part-time attention from whoever already owns identity infrastructure, because nobody scoped it as a program that needs dedicated ownership.
- Weak change management. The departments never consulted during scoping are the same departments that resist adopting the tool later, because resistance is often just delayed consultation.
All three trace back to the same missing step, so the fix is upstream of any one symptom. Assign a cross-functional owner, or at minimum a cross-functional steering group, before a single vendor conversation happens. Securing genuine IGA buy-in across departments is the work here, and it happens before the RFP, not after go-live. The test for whether this root cause is present: can you name who from HR, compliance, and app-owner ranks contributed to the requirements document? If the honest answer is nobody, the purchase is currently a tool acquisition, not a program, regardless of how the internal memo describes it.
Root Cause 2: No Bounded Scope or Exit Criteria Defined Per Stage
This is the absence of a written answer, before any given stage starts, to the question "what does done look like here." Planning has no defined boundary on application count. The pilot has no defined pass condition. Each rollout phase has no defined metric target. Work simply continues until it feels finished, which in practice means it rarely does.
Bounding scope feels like it's leaving something out, and leaving something out feels risky when the project is meant to solve governance comprehensively. It's psychologically easier to leave scope open-ended than to draw a line and defend it to stakeholders who want everything covered immediately. The absence of a boundary looks, from the outside, like thoroughness. It functions like the opposite.
An open-ended scope doesn't fail in one obvious place. It fails in four:
Symptoms it produces:
- Boiling the ocean. With no defined boundary, "cover everything" becomes the default scope by omission, not by decision.
- Choosing the wrong starting point. Without criteria for what a good first application looks like, selection defaults to whatever's easiest or whatever's loudest, rather than what actually proves measurable value.
- The pilot that never graduates. No exit criteria means no forcing function to declare the pilot complete, so it extends indefinitely instead of producing a decision.
- Metrics that don't match the phasing. Without phase boundaries, there's nothing to attach a phase-level metric to, so measurement collapses into one number checked at the very end.
Every one of those four resolves the same way: write the boundary down before the stage starts, not during it. A specific application count and list for the pilot. A specific pass condition and deadline for graduating it. A specific metric target for each rollout phase (here's how to measure IGA), reported on a schedule, not just measured once at the finish line. The boundary doesn't need to be permanent. It needs to exist and be visible enough that everyone can see when it's been met or missed. A phased implementation plan with stage boundaries written in from the start is the format that makes this stick.
Root Cause 3: Environment Assumptions Never Get Validated Before Commitments Are Made
This is treating a vendor's description of their platform's coverage as equivalent to that platform's actual coverage of your specific environment, without testing the gap between the two before policies, timelines, or budgets get built on top of it.
Validating assumptions takes time and access that feels like it's slowing down a purchase or a project everyone wants moving. A connector count or a demo against a clean sample environment is available immediately. Testing against your actual, messy environment requires coordination, real data, and a willingness to find out the number is worse than advertised before you've committed to a timeline built on the better number.
Skip that validation and the gap surfaces later, in two places at once:
Symptoms it produces:
- Ignoring integration reality. Custom instances, unfederated tools, and internally built applications don't behave like the demo environment, and the gap only becomes visible once integration work is already underway. This dynamic hits hardest in SaaS-first environments, where the share of apps a vendor's connectors actually cover is smallest.
- Governance built before discovery. Policies and review workflows get designed against an assumed complete inventory, and the assumption doesn't get tested until an auditor, or a security incident, exposes what was actually missing. This is the inverse of the visibility-first sequence that working IGA programs follow.
Both symptoms trace back to the same untested assumption, which is why the fix has to happen before either can occur. Test coverage against your real environment before it's load-bearing for anything else, meaning before policies get written, before timelines get committed, and ideally before the contract gets signed. A discovery test that runs against twenty to thirty of your actual applications, including a few with no pre-built connector, tells you more than any number in a sales deck. Our guide on evaluating IGA software covers how to structure exactly this validation step before you buy.
A Diagnostic for Catching These Before They Surface
Each root cause has a question that can be answered honestly right now, before any symptom has appeared, rather than after.
For Root Cause A: Who outside IT and security contributed to the requirements document? If the list is empty, the project is currently owned as a tool purchase.
For Root Cause B: What, specifically, marks the pilot as complete, and is it written down anywhere? If the answer is a feeling rather than a criterion, no boundary actually exists.
For Root Cause C: Has discovery been tested against real, messy applications, including ones without pre-built connectors, or only against a vendor's demo environment? If it's only the demo, coverage is unverified.
A yes on all three doesn't guarantee a smooth implementation. It does mean the three most common sources of stalled and abandoned IGA projects have been addressed at the source, rather than left to surface later as nine different-looking problems.
Why Patching Symptoms Doesn't Hold
Every one of the nine surface-level failures has an obvious, direct-seeming fix: more training for adoption, a longer pilot for graduation problems, more connectors for integration gaps. These fixes aren't wrong exactly. They're just aimed at the wrong altitude.
A root cause, left in place, produces its next symptom on a delay. Fix the change management symptom with a communication campaign, and if Root Cause A is still active, the next department to feel excluded produces the same resistance under a different name, at a different stage, six months later. The fix that holds is always one level down from the symptom, at the decision that made the symptom possible in the first place.
Frequently Asked Questions
If we can only address one root cause before starting, which matters most?
Root Cause A, misaligned ownership, tends to have the widest blast radius, since it touches staffing, requirements, and adoption simultaneously. But the honest answer is that all three tend to compound each other, so the better question is usually which one is currently weakest in your specific organization, not which one matters most in the abstract.
Can a root cause be fixed mid-implementation, or does it have to be caught before starting?
It can be fixed mid-implementation, but it requires deliberately going backward: bringing in the excluded stakeholders, writing down the scope boundary that was never set, or running the discovery test that was skipped. It's slower and more visible than catching it early, but it's still faster than continuing to patch the symptoms it keeps producing.
How is this different from just listing the nine failure modes?
The failure-mode list answers "what commonly goes wrong." This is a different question: "why does one organization produce three or four of these failures while another produces none." The answer isn't nine independent bad decisions. It's one or two root decisions that happen to manifest in multiple places.
Is it possible to have all three root causes present at once?
Yes, and it's more common than having just one. They're not mutually exclusive, and an organization that scoped IGA as a pure tool purchase (Root Cause A) is also somewhat more likely to skip defining stage boundaries (Root Cause B), since both stem from treating the project as smaller and more contained than it actually is.
.svg)
