Why IGA projects fail and what changes for identity governance

At a glance

What this is: This analysis explains why Identity Governance and Administration projects commonly fail and identifies sequencing, integration, and reviewer experience as the recurring fault lines.

Why it matters: It matters to IAM and NHI practitioners because governance programs that cannot integrate, explain, and operationalise access reviews will not scale across human and non-human identities.

By the numbers:

• Gartner says over 50% of IGA deployments are distressed and fail to achieve functional, budgetary, or timing commitments.

👉 Read CyberArk's analysis of why IGA projects fail and how to improve success

Context

Identity Governance and Administration fails when the programme is treated as a tooling rollout instead of a control redesign. For IAM teams, the first question is not whether access reviews exist, but whether the organisation can actually complete them across applications, reviewers, and approvals without creating manual bottlenecks.

That same pattern matters for Non-Human Identity governance because the operational burden grows faster than the inventory. As service accounts, API keys, tokens, and workload identities multiply, the control plane has to be simple enough for humans to run and precise enough to cover machine access without resorting to exceptions.

The article's failure modes are familiar to most enterprises: too much scope too early, integration work that drags for months, and reviewer workflows that people do not understand. That starting position is typical, which is why many IGA projects struggle before they deliver visible security value.

Key questions

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.

Q: Why do identity governance projects stall even after the platform is selected?

A: Projects stall when the organisation discovers that connectors, application-specific logic, and reviewer workflows require more effort than the initial plan assumed. The platform may exist, but the control still fails if integrations are incomplete or reviewers cannot complete campaigns quickly and accurately.

Q: What is the difference between provisioning and access review in IGA?

A: Provisioning grants or changes access, while access review verifies whether existing access should stay in place. Provisioning is usually the heavier engineering problem because it depends on application integration and entitlement logic, whereas review quality depends more on clarity, workflow design, and human decision-making.

Q: How do I make access reviews usable for non-technical managers?

A: Translate technical entitlements into plain language, allow reviewers to reassign permissions they cannot judge, and add escalation for overdue tasks. That combination reduces rubber-stamping and makes the review a real control instead of an administrative burden.

Technical breakdown

Why starting with provisioning slows identity governance

Provisioning is the most mechanically complex part of many IGA programmes because it has to encode entitlement catalogues, birthright logic, requestability, and approval workflows at the same time. If teams start here, they inherit every upstream dependency at once, including HR data quality, directory synchronisation, and application-specific role models. The result is often a long build period before users see value, which weakens sponsorship and makes the programme look like a cost centre rather than a control. In practice, the problem is not that provisioning is unimportant. It is that provisioning is a poor first win when the organisation still lacks consistent identity data and clear access models.

Practical implication: Start with narrow, high-value workflows before expanding into full provisioning scope.

How integration gaps create governance blind spots

IGA depends on reliable integrations with HR systems, directories, business applications, databases, and cloud services. When a platform cannot integrate cleanly, teams end up with islands of unmanaged applications, manual review processes, and incomplete audit evidence. Custom development can fill gaps, but every bespoke connector extends delivery time and increases maintenance overhead. For NHI governance, this is especially risky because non-human access often lives in the systems that are hardest to inventory, such as CI/CD pipelines, scripts, and third-party SaaS connections. If those sources are left outside the governance boundary, the programme may look complete while still missing the highest-risk identities.

Practical implication: Validate connector coverage against your hardest-to-integrate systems before committing to rollout.

Why reviewer resistance breaks access review campaigns

Access review success depends on application owners and supervisors being able to understand what they are approving. If permissions are cryptic, the workflow is cumbersome, or the reviewer population is too broad, people delay, rubber-stamp, or ignore the campaign. That creates labour waste for campaign owners and weakens the control itself because the review becomes a compliance exercise instead of a risk decision. The lesson for NHI and IAM teams is that review quality is a usability problem as much as a policy problem. Plain-language entitlements, reassignment options, and escalation paths are not administrative extras. They are what make the control executable at scale.

Practical implication: Design review workflows for non-technical reviewers, not just for audit evidence.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

IGA programmes fail most often when they are designed around system completeness instead of control adoption. A project can enumerate permissions perfectly and still fail if people cannot use the process or if delivery takes too long to show value. The practical standard is not coverage for its own sake but whether governance changes day-to-day access decisions.

Integration is the hidden tax that determines whether identity governance becomes an operating capability or a shelfware platform. Every custom connector, manual exception, and unsupported application expands the cost of maintaining the control plane. For practitioners, the right question is whether the platform can absorb complex systems without turning the programme into a services dependency.

Reviewer friction is an access risk, not just a workflow nuisance. When non-technical reviewers cannot complete campaigns confidently, organisations get either incomplete reviews or rubber-stamped approvals. That means identity governance must be designed around comprehension, escalation, and accountability, not just policy intent.

Identity governance for NHIs should be sequenced from the same principle as human IGA, but with tighter blast-radius control. Non-human identities often move faster, persist longer, and touch more systems than human accounts. That makes early wins in reviewability, inventory, and offboarding more important than trying to solve every entitlement edge case at once.

Operational simplicity is the named concept this article surfaces: control value appears only when governance can be executed by ordinary reviewers. If a process needs constant chasing, exception handling, or custom interpretation, it is not scaled governance. Practitioners should treat simplicity as a control requirement, not a user-experience preference.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For lifecycle control detail, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Operational simplicity will become the deciding factor in whether identity governance extends cleanly into NHI programmes. If access review and revocation workflows are already hard for human identities, they will fail faster once service accounts, tokens, and automated workloads are added. Teams should expect governance to shift toward smaller control surfaces, clearer entitlements, and more automation around exception handling.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, per the Ultimate Guide to NHIs, governance gaps are no longer confined to access review tools. The programme signal is clear: inventory, reviewability, and offboarding must extend into engineering workflows, not sit beside them.

For practitioners

• Sequence governance around the highest-risk reviews first Begin with user access reviews for critical applications, then expand into provisioning and broader entitlement workflows once the control is repeatable.
• Test integration coverage before platform commitment Map HR, directory, core business applications, databases, SaaS tools, and any custom systems to confirm the platform can connect without long custom-build cycles.
• Simplify access review decisions for non-technical owners Use plain-language permission descriptions, reassignment options, and automatic escalation for overdue campaigns so reviewers can make accurate decisions quickly.
• Treat NHI reviewability as part of the IGA scope Include service accounts, API keys, tokens, and workload identities in the same governance design so machine access does not become the hidden exception class.

Key takeaways

• IGA fails when delivery starts with the hardest control path instead of the most adoptable one.
• Integration gaps and reviewer friction turn governance into manual labour, which is why many programmes miss their time and budget targets.
• Teams that want durable identity governance should sequence for value, simplify decisions, and include NHI workflows from the start.

Key terms

• Identity Governance and Administration: Identity Governance and Administration is the set of controls used to define, approve, review, and revoke access across an enterprise. It combines policy, workflow, and audit evidence so organisations can show that access is appropriate, current, and traceable across both human and non-human identities.
• Access Review Campaign: An access review campaign is a scheduled process where application owners, managers, or delegates confirm whether existing permissions should remain in place. It is a control for removing excess access, but it only works when reviewers can understand the permissions and complete decisions reliably.
• Birthright Access: Birthright access is the baseline set of permissions granted automatically when a user or workload is created, onboarded, or assigned to a role. It reduces manual provisioning work, but it becomes risky when the inherited access is too broad, poorly documented, or never reviewed.
• Non-Human Identity: A non-human identity is any machine or software identity used to authenticate and access systems, including service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. These identities often outnumber human accounts and require separate lifecycle, review, and rotation controls.

Deepen your knowledge

IGA sequencing, lifecycle control, and access review design are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending governance into service accounts and other machine identities, it is worth exploring.

This post draws on content published by CyberArk: Top 3 Reasons IGA Projects Fail. Read the original.