Why IGA projects fail and what changes for identity governance

At a glance

What this is: CyberArk’s article argues that IGA projects fail most often when teams start with provisioning, underestimate integration work, and make access reviews too hard to complete.

Why it matters: Identity and access teams need to sequence governance work around value delivery, because difficult early phases can stall audits, delay compliance outcomes, and leave manual review gaps in place.

By the numbers:

• More than 50% of IGA deployments are distressed and fail to achieve functional, budgetary, or timing commitments.

Context

IGA projects often fail for governance reasons before they fail for technical ones. In this case, the primary problem is not whether identity governance is necessary, but how implementation choices create avoidable friction across provisioning, integration, and certification workflows.

For IAM and IGA teams, that matters because the business value of governance is usually supposed to show up in audit readiness, access clarity, and lower manual effort. When the first phase is too complex, those outcomes arrive too late to sustain sponsorship or operational momentum.

Key questions

Q: What breaks when an IGA programme starts with provisioning?

A: Provisioning-first programmes often stall because they require immediate integration, entitlement cataloguing, and workflow design before users see value. That makes the first phase expensive and slow, which weakens sponsorship. The practical failure is not provisioning itself but starting with the hardest control surface before the organisation has proven the governance model on a smaller, visible scope.

Q: Why do integration gaps make identity governance unreliable?

A: Because governance depends on complete and accurate connections to the systems that actually hold access rights. When key applications are excluded or custom-built connections take too long, audit reporting, entitlement oversight, and access decisions become incomplete. The result is a partial control plane, not a complete programme.

Q: What are the signs that an access review process is failing in practice?

A: A failing access review process usually shows up as long approval cycles, overloaded reviewers, repeated manual preparation, and heavy engineering effort just to launch each campaign. If reviewers need multiple sources to understand a user’s access, or facilitators spend weeks coordinating certifications, the process is not scaling. Those are clear signs the workflow needs better automation and better access context.

Q: How should organisations sequence an IGA programme to reduce failure risk?

A: Start with a narrow control that delivers visible value, such as access reviews for critical applications, then add provisioning and broader workflows once the core process is working. This reduces integration pressure, shortens time to value, and builds sponsor confidence before the programme expands into more complex entitlement management.

Technical breakdown

Why provisioning-first IGA programmes stall

Provisioning is the point where identity governance starts touching application entitlements, approval logic, and business rules at once. That makes it the most complex part of many programmes, especially when teams try to catalogue roles, groups, approvers, and birthright access before any visible value is delivered. In practice, the programme becomes a build exercise instead of a governance control. When implementation leads with breadth instead of containment, the organisation absorbs months of work before users, auditors, or executives see a meaningful outcome.

Practical implication: sequence the first phase around the smallest governance scope that can deliver measurable control value.

How integration gaps create audit and access blind spots

IGA platforms depend on reliable connections to HR systems, directories, business applications, and databases. If those integrations are partial or require custom development for too many systems, the programme inherits reporting gaps, over-permissioned accounts, and islands of unmanaged applications. That turns governance into a split model where some systems are controlled and others remain manual. The real problem is not just technical integration cost, but the way every excluded application weakens the completeness of the governance layer.

Practical implication: validate integration coverage against your critical application set before committing to a platform and process design.

Why user access reviews fail when reviewers cannot act quickly

User access review campaigns depend on application owners and supervisors understanding what they are approving or rejecting. If permissions are cryptic, the review flow is cumbersome, or escalation paths are unclear, reviewers either rubber-stamp or stop participating. That creates false assurance, because the campaign completes on paper while actual decision quality collapses. The issue is especially acute when non-technical reviewers are asked to make judgments without context, language clarity, or delegated support.

Practical implication: simplify permission descriptions, add escalation, and support reassignment so review quality survives at scale.

Breaches seen in the wild

• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IGA failure is usually a sequencing problem before it is a tooling problem. Starting with provisioning forces teams to build the most complex part of governance before they have established trust, scope, or visible wins. That ordering turns identity governance into a long integration project, and long integration projects lose sponsorship when the control value is deferred. The implication is that programme design, not just platform choice, determines whether IGA becomes operational or ornamental.

Integration debt is the hidden governance failure mode in legacy IGA. When critical applications are left outside the integration boundary, the organisation creates a split control plane in which audit evidence, access oversight, and entitlement accuracy vary by system. That is not a minor coverage issue, it is a structural gap in governance completeness. Identity governance coverage debt: once an application is deemed too complex to integrate, the programme normalises partial control and permanent manual exceptions. Practitioners should treat excluded systems as evidence of programme design limits, not edge cases.

Reviewer resistance is a control design signal, not a user behaviour problem. If supervisors and application owners cannot understand permissions quickly enough to decide, the review model is too complex for the people it depends on. This is why plain-language entitlements and reassignment options matter: they preserve decision quality and reduce rubber-stamping. The broader lesson is that access certification succeeds only when the governance workflow matches the cognitive load of the reviewer population.

Compliance-first sequencing makes IGA survivable at enterprise scale. Starting with critical applications and user access reviews gives the programme an immediate governance outcome, while still building the HR, directory, and application foundation needed for later phases. That does not solve everything at once, but it prevents the common failure where a broad ambition creates no usable control for months. For identity teams, the practical standard is simple: deliver a visible control outcome before expanding the control surface.

Legacy IGA often fails because it promises universal coverage before it proves governable scope. The market lesson is that identity governance is not simply about automating reviews or provisioning, it is about deciding which workflows deserve automation first and which systems must be brought into scope early. Teams that ignore this sequence tend to accumulate manual exceptions, frustrated reviewers, and delayed compliance outcomes. Practitioners should judge IGA programmes by how fast they reduce manual control risk, not by how much process they automate on day one.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.

What this signals

Sequencing is the real control variable in IGA delivery. When teams begin with the smallest governable slice, they can prove value before integration debt and workflow complexity consume the programme. That is why the first successful phase matters more than the most ambitious target state.

Access review usability is a governance requirement, not a UX preference. If reviewers cannot understand the entitlement they are being asked to certify, the control collapses into administrative noise. Organisations should design for decision quality first, then scale the process once the workflow is understandable to non-technical owners.

For practitioners

• Prioritise critical-app access reviews first Start the programme with user access reviews for the applications that carry the highest audit and operational risk, then expand after the review model is stable.
• Map integration scope before selecting a platform Inventory HR systems, directories, business applications, databases, and critical third-party apps so you can test whether they can be governed without custom development.
• Simplify permission language for reviewers Rewrite entitlement descriptions in plain language so non-technical reviewers can decide whether access should stay, move, or be removed.
• Add escalation and reassignment paths Build automated escalation for overdue reviews and allow permissions to be reassigned to a more qualified owner when the original reviewer cannot decide.
• Measure manual exception growth Track how many applications remain outside automated governance so the programme can identify where integration debt is turning into a permanent manual process.

Key takeaways

• IGA programmes fail when implementation order is backwards, especially when teams start with provisioning before proving control value.
• Integration gaps create partial governance coverage, leaving some applications outside audit-ready oversight and forcing manual workarounds.
• Review processes must be understandable to non-technical owners, or access certification turns into rubber-stamped compliance theatre.

Key terms

• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
• Provisioning Support: Provisioning support is the capability to create, update, or remove access in connected systems through a governed workflow. It turns identity data into action by pushing changes such as group creation, role assignment, or permission updates, even when a target application does not support standard provisioning interfaces.
• Entitlement: An entitlement is the permission set that defines what a non-human identity can do after it authenticates. It is usually expressed through roles, policies or access assignments, and unmanaged entitlements are a common reason machine identities become over-privileged over time.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.