TL;DR: IGA programmes often fail because teams rush into implementation without clear business objectives, stakeholder ownership, clean identity data, or realistic maintenance plans, according to Twine Security. The deeper issue is that IGA is treated like a one-time deployment, when it is really a continuous governance programme that breaks down as soon as lifecycle complexity and process friction are ignored.
At a glance
What this is: This is a Twine Security analysis of why IGA implementations fail, centred on unclear objectives, weak stakeholder engagement, poor data quality, and maintenance overhead.
Why it matters: It matters because IGA failures do not just delay tooling rollouts, they leave joiner-mover-leaver, certification, and provisioning controls unreliable across human and non-human identity governance.
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.
Context
Identity governance and administration fails when organisations confuse software deployment with governance design. IGA only works when joiner-mover-leaver process ownership, access certification criteria, and data quality are defined before automation begins, not after.
Twine Security frames these failures as operational rather than purely technical. The recurring pattern is the same: projects inherit messy identity data, unclear accountability, and business processes that were never made fit for consistent lifecycle control.
Key questions
Q: Why do IGA projects fail when organisations rush into automation?
A: IGA projects fail when automation is built before business objectives, ownership, and lifecycle processes are defined. The result is working technology that governs the wrong workflow, creates review fatigue, and leaves exceptions unmanaged. Start with operating model clarity, then automate the decisions that the business can actually support.
Q: What breaks when identity data quality is poor in IGA programmes?
A: Poor identity data breaks the joiner, mover and leaver process because access decisions depend on accurate records of who exists, what systems they use, and which accounts belong to them. When data is incomplete or wrong, access requests slow down, reviews miss risk, and terminated or moved identities can keep access they should lose.
Q: What breaks when managers are asked to certify access without context?
A: Certification breaks down when reviewers see long entitlement lists with no business meaning or risk context. Managers then rubber-stamp reviews, which preserves the appearance of governance while reducing actual risk reduction. The control only works when reviewers can understand the access they are approving or rejecting.
Q: How should teams prepare for the maintenance burden of IGA?
A: Teams should plan IGA as an ongoing programme with continuing role maintenance, access rule updates, application onboarding, and exception handling. If maintenance is treated as aftercare, the model drifts, reviews lose relevance, and the platform becomes harder to operate. Budget and staffing must reflect steady-state governance.
Technical breakdown
Why IGA projects fail at business alignment
IGA implementation fails early when the programme has no explicit business objective. Without agreed outcomes, teams automate the wrong workflows, certificate the wrong access, and create friction that business units resist. Clear joiner-mover-leaver design is not a documentation exercise, it is the control logic that determines whether provisioning, certification, and offboarding support the business or merely add process overhead. When ownership between HR, IT, and business managers is unclear, every downstream control becomes slower and less reliable.
Practical implication: define lifecycle ownership and success criteria before configuring workflows or certification campaigns.
How stakeholder resistance breaks access certification and provisioning
IGA systems often fail because they ask managers and application owners to review or approve entitlements without giving them context. If managers see thousands of items with no business meaning, they rubber-stamp. If application owners are excluded from onboarding decisions, integrations fail later. In practice, adoption is not about user training alone. It depends on whether the review interface, request catalog, and approval design match how the business actually assigns and understands access.
Practical implication: design review and approval flows around business context, not around the tool's internal entitlement structure.
Why identity data quality is the hidden control plane
IGA depends on trustworthy identity data. Poor HR records, inconsistent account naming, missing attributes, and conflicting authoritative sources all break automated decisions. Role-based access control also becomes unreliable when entitlement data is obsolete, redundant, or unclassified. The technical issue is not just integration effort. It is that the IGA engine can only govern what it can correlate, and weak source data produces weak access decisions even when automation is functioning exactly as configured.
Practical implication: cleanse authoritative identity and entitlement data before scaling automated provisioning or access reviews.
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 a governance design failure, not a tooling failure. Twine Security’s core point is that organisations under-estimate the amount of human coordination required before automation can work. Clear objectives, named owners, and realistic operating assumptions are the prerequisites; without them, the programme becomes expensive process theatre. The practitioner conclusion is simple: treat IGA as a governance operating model, not a software project.
Access certification breaks when the business cannot interpret what it is being asked to approve. Thousands of entitlements, weak context, and poorly designed review screens push managers toward rubber-stamping. That failure mode matters because certification quality is only as good as the reviewer’s ability to make a defensible decision. The implication is that entitlement presentation, not just workflow automation, determines whether certification reduces risk or merely records activity.
Identity data quality is the control plane for IGA. If HR data, account naming, and authoritative sources do not line up, provisioning and review logic cannot reliably separate current, obsolete, or duplicate access. This is where many programmes quietly fail: the policy may be correct, but the data foundation is not. Practitioners should treat identity data remediation as part of governance design, not a later cleanup task.
Costly maintenance exposes the myth of one-time implementation. Twine Security shows that role definitions, approval rules, application onboarding, and certification support all require ongoing effort. That makes IGA a living programme with recurring operating cost, not a one-off control deployment. The practical conclusion is that budget, staffing, and change management must be planned for steady-state governance, not just go-live.
Legacy IGA assumptions do not scale cleanly into modern lifecycle complexity. The article’s recurring theme is that organisations start with a narrow deployment mindset and then discover M&A, exception handling, and application onboarding make the programme harder than expected. That does not mean IGA is broken; it means the implementation model was too small for the lifecycle problem being governed. The practitioner takeaway is to align programme scope with the full identity lifecycle from the outset.
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
Identity governance succeeds only when the operating model is explicit. Teams that start with tooling tend to discover missing lifecycle ownership, poorly defined approval paths, and certification processes that do not match how access is really granted. The practical signal is that IGA readiness should be measured by decision clarity, not by deployment progress.
Access reviews are a quality problem as much as a control problem. When reviewers cannot understand the context behind entitlements, they approve by default and the governance loop weakens. That means programme leaders should focus on entitlement clarity, application ownership, and review usability as part of the control itself.
Maintenance is not an afterthought in IGA, it is the programme. Role changes, onboarding effort, policy updates, and exception handling all accumulate after go-live, and that operating cost is what separates durable governance from shelfware. Teams should expect sustained administrative effort and plan for it from day one.
For practitioners
- Define governance objectives first Set explicit outcomes for joiner-mover-leaver, access certification, and provisioning before selecting workflows or configuring the platform.
- Assign named ownership across functions Document which parts of identity lifecycle management belong to HR, IT, application owners, and business managers so approvals and exceptions do not fall into gaps.
- Cleanse authoritative identity data Resolve duplicate accounts, missing attributes, inconsistent naming, and conflicting source systems before automating entitlements or certification campaigns.
- Redesign certification for business context Present reviewers with meaningful access context, risk cues, and application ownership so reviews become decisions rather than bulk confirmations.
- Budget for steady-state maintenance Plan for recurring role maintenance, onboarding effort, policy updates, and support capacity as permanent operating costs rather than post-project overhead.
Key takeaways
- IGA failures usually begin with unclear objectives, missing ownership, and a deployment mindset that is too small for the governance problem.
- The article ties these weaknesses to practical breakdowns such as bad certifications, broken provisioning, and maintenance overhead that keeps rising after go-live.
- The control that matters most is lifecycle governance designed up front, because IGA only works when data, business context, and accountability are already aligned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | IGA failures stem from missing governance objectives and ownership. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on entitlement review, provisioning, and lifecycle control. | |
| Recommendation — Define an identity governance risk strategy before automating access decisions. Review and govern entitlements as a lifecycle control, not a one-time setup task. | ||
| CIS Controls v8 | CIS-5 — Account Management | IGA failure modes include onboarding, offboarding, and account maintenance gaps. |
| Recommendation — Use account management governance to keep lifecycle processes current and enforceable. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The article repeatedly points to account lifecycle ownership and provisioning failures. |
| AC-6 — Least Privilege | Certification and role design failures often leave users over-entitled. | |
| Recommendation — Apply account management controls to assign ownership and maintain current access state. Use least privilege reviews to remove excess access that survives weak IGA governance. | ||
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org