TL;DR: IGA implementations often fail because teams start without clear business objectives, underestimate integration complexity, and leave ownership, data quality, and ongoing maintenance unresolved, according to Twine Security. The deeper issue is not tooling alone but governance design: identity programs fail when lifecycle control, stakeholder accountability, and operational realism are treated as afterthoughts.
At a glance
What this is: This is a blog analysis of why IGA implementations fail, centring on governance, operating-model, and data issues rather than tooling alone.
Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all fail for the same reason when lifecycle ownership, data quality, and integration reality are not designed up front.
By the numbers:
- IT projects tend to run 45% over budget, 7% over time, and deliver 56% less value than predicted, according to a McKinsey study cited by Twine Security.
- IT projects deliver 56% less value than predicted, according to a McKinsey study cited by Twine Security.
Context
IGA projects fail when organisations treat them as a technology rollout instead of a cross-functional governance programme. The article points to missing business objectives, weak ownership, poor data quality, and unrealistic integration planning as the recurring causes.
That failure pattern is familiar across identity programmes. The same conditions that break access review, role design, and provisioning projects also destabilise NHI lifecycle management, because the underlying problem is operating model discipline, not just product capability.
Key questions
Q: What breaks when IGA is implemented without clear business objectives?
A: Without clear objectives, IGA becomes a collection of disconnected workflows that satisfy audit activity but do not reduce risk. Teams struggle to define success, business units resist the process, and access reviews or provisioning rules drift away from real operational needs. The programme consumes effort without creating measurable control value.
Q: Why does poor data quality undermine AI-driven identity governance?
A: AI systems are only as reliable as the data they consume. In identity governance, inconsistent formats, incomplete access records, and weak authoritative sources can produce misleading recommendations about who should have access, why it was granted, and how long it should remain in place. When the underlying data is bad, automation amplifies error instead of improving control.
Q: Where do IGA projects usually fail in practice?
A: They fail at the handoff points between governance and operations. If HR does not own workforce data, IT does not own integration quality, and business managers do not own access decisions, the process fragments. That is when certifications are rubber-stamped, onboarding breaks, and offboarding trails behind.
Q: How do organisations know whether their IGA programme is actually working?
A: Look for fewer orphaned accounts, fewer unresolved SoD conflicts, and a lower rate of redundant approvals in certification campaigns. If the programme is healthy, access reviews should produce cleaner entitlement data and fewer exceptions over time, not just higher completion percentages.
Technical breakdown
Why unclear objectives break IGA programmes
IGA projects need a defined business outcome because the control model, approval logic, and certification scope all depend on what the programme is trying to fix. If teams cannot explain whether the goal is compliance, access reduction, or lifecycle control, the implementation drifts into generic entitlement management. That usually creates large review campaigns with little risk reduction and weak adoption from business stakeholders. In practice, a vague objective is not just a planning issue. It becomes a design flaw that produces mis-scoped workflows, unclear ownership, and a governance model nobody trusts.
Practical implication: define measurable business outcomes before configuring certifications, provisioning, or role models.
How data quality and integrations shape automation outcomes
IGA automation is only as reliable as the identity data and application integrations behind it. Poor HR records, inconsistent account naming, incomplete attributes, and conflicting authoritative sources all break the mapping between people, roles, and entitlements. That means automated provisioning can create bad access as efficiently as manual processes once did. The technical issue is correlation, not orchestration. If the system cannot confidently match identities and entitlements across sources, access decisions, deprovisioning, and review evidence all degrade at the same time.
Practical implication: clean identity data and confirm source-of-truth relationships before expanding automated access decisions.
Why IGA maintenance is an ongoing governance function
IGA is not a one-time deployment because roles, approval paths, and application integrations change continuously. Each business change can force updates to role definitions, provisioning rules, review scopes, and exception handling. When the platform depends on heavy customisation, every upstream business change increases support cost and operational risk. That is why maintenance is part of the control surface, not an afterthought. Without steady governance ownership, the programme accumulates stale roles, broken workflows, and patchwork exceptions that reduce both compliance value and operational credibility.
Practical implication: assign ongoing ownership for role upkeep, workflow changes, and application onboarding after go-live.
Breaches seen in the wild
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
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 failure is usually an operating-model failure before it is a tool failure. The article shows that organisations underestimate how much identity governance depends on business ownership, lifecycle clarity, and process discipline. When joiner-mover-leaver ownership is unclear, the tooling simply exposes the absence of decision rights. Practitioner conclusion: treat IGA as a governance programme with systems support, not the other way around.
Identity lifecycle control cannot scale without clean source data and stable authority boundaries. Poor HR data, conflicting identity sources, and inconsistent account naming are not integration annoyances. They are the conditions that prevent accurate entitlement mapping, reliable provisioning, and defensible certification. Practitioner conclusion: the quality of authoritative data is a first-order control requirement, not a back-end housekeeping task.
Certification at scale breaks when entitlement inventory outgrows human review capacity. The article’s examples of thousand-item review campaigns and context-poor approval screens show why large access reviews devolve into rubber-stamping. That is a governance design problem, because review volume, decision context, and role clarity were not designed together. Practitioner conclusion: if reviewers cannot make informed decisions, the certification process is not working as intended.
Scalable identity governance requires a lifecycle model that extends beyond human accounts. The same design weaknesses that break IGA programmes also appear in service-account and AI-agent governance, where ownership, offboarding, and review cadence are often weaker than for employees. The named concept here is lifecycle governance debt: control assumptions are allowed to accumulate faster than the organisation can maintain them. Practitioner conclusion: identity programmes should be judged by their ability to sustain lifecycle control across all identity types, not just by initial deployment success.
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.
- Read next: IGA Buyer's Guide
What this signals
Lifecycle governance debt: Identity programmes fail when business change outpaces the organisation’s ability to maintain roles, approvals, and authoritative sources. That debt shows up later as stale access, review fatigue, and broken offboarding paths rather than as a single obvious incident.
The programme lesson is broader than IGA tooling. Any identity control that depends on accurate inventories, stable ownership, and repeatable exception handling will degrade unless governance is treated as a continuous operating model, not a project milestone.
For practitioners
- Define business outcomes before configuring controls Tie the programme to a small set of measurable outcomes such as audit reduction, access-risk reduction, or joiner-mover-leaver accuracy before selecting workflows or certification scopes.
- Assign explicit ownership across HR, IT, and business teams Document who owns identity lifecycle decisions, who approves access exceptions, and who maintains the authoritative sources that drive provisioning and recertification.
- Clean identity and entitlement data before expanding automation Resolve duplicate identities, conflicting source records, and unclassified entitlements before relying on automated provisioning or review logic.
- Phase application onboarding by criticality Start with the systems that carry the highest access and audit risk, then expand once mappings, approvals, and exception handling are stable.
- Budget for continuous maintenance, not one-time deployment Treat role updates, workflow changes, and review redesign as an ongoing operating cost rather than a project closeout task.
Key takeaways
- IGA projects most often fail because governance design, ownership, and lifecycle clarity are missing before the tool is even configured.
- The article’s examples show that weak data quality, broad certification scope, and integration complexity turn automation into another source of operational work.
- Teams that want durable IGA outcomes need measurable objectives, explicit ownership, and a maintenance model that assumes continual change.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack surface, NIST CSF 2.0 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | The article centres on aligning IGA to business objectives and ownership. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The failure modes are about access governance, certification, and entitlement control. | |
| Recommendation — Define IGA outcomes in business terms before selecting controls or workflows. Review entitlement models against PR.AA-05 and eliminate unclear or excessive access paths. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article repeatedly points to account lifecycle, provisioning, and offboarding breakdowns. |
| Recommendation — Strengthen account lifecycle ownership and automate only where source data is reliable. | ||
| ISO/IEC 27001:2022 | A.5.18 — Access rights | IGA project failures directly affect how access rights are assigned, reviewed, and removed. |
| Recommendation — Map IGA workflows to access-rights governance and maintain ownership for approvals and review. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The article highlights failed deprovisioning, orphaned accounts, and stale access as recurring outcomes. |
| Recommendation — Track offboarding gaps and revoke identities that remain active after role or business changes. | ||
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.
- Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
- Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
- Authoritative Data Source: A trusted source used to confirm identity attributes, such as a government database or regulated banking record. These sources reduce reliance on self-reported information and improve confidence in onboarding decisions. The quality of the verification outcome depends heavily on source coverage, freshness, and whether the data can be matched reliably.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org