Almost everything that derails an IGA implementation traces back to one of three decisions made early, and every fix aimed only at the symptom leaves the root free to produce the next one.
Cataloging failure modes is useful, but it invites a specific mistake: treating each one as its own problem with its own fix. Add training because adoption is low. Add a project manager because the timeline slipped. Add a review deadline because certifications are late. Each fix addresses the symptom directly in front of you, and each one quietly leaves the actual cause untouched, free to produce the next symptom a few months later.
Root cause analysis asks a different question. Not "what went wrong here," but "what decision, made once, is capable of producing this many different failures." Run that question against nine common IGA implementation failure modes 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 holds for long.
The Three Root Causes, at a Glance
Ignoring integration reality, governance built before discovery
Three root causes, nine symptoms. The rest of this piece walks through each root cause in depth, then shows the method for tracing a symptom back to its source.
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
What it actually 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.
Why it forms: 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.
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.
- 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.
What actually fixes it: Assign a cross-functional owner, or at minimum a cross-functional steering group, before a single vendor conversation happens. 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
What it actually 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.
Why it forms: 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.
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 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.
What actually fixes it: 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, 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.
Root Cause 3: Environment Assumptions Never Get Validated Before Commitments Are Made
What it actually 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.
Why it forms: 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.
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.
- 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.
What actually fixes it: 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.
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)
