Topic starter
08/06/2026 4:19 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Twine Security: “6 Common Causes of Failure in IGA Projects”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: IGA failures usually begin with unclear objectives, missing ownership, and a deployment mindset that is too small for the governance problem.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
08/06/2026 5:54 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: IGA project failures reveal the governance gaps teams keep missing
This post was modified 5 days ago by NHI Mgmt Group