Notifications
Clear all
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.
NHIMG editorial — based on content published by Twine Security: 6 Common Causes of Failure in IGA Projects
By the numbers:
- A McKinsey study found IT projects run 45% over budget, 7% over time, and deliver 56% less value than predicted.
Questions worth separating out
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.
Q: Why do identity governance projects struggle when lifecycle ownership is unclear?
A: Lifecycle ownership matters because joiner-mover-leaver decisions depend on coordinated input from HR, IT, security, and business owners.
Q: How do data quality problems undermine IGA automation?
A: Automation only works when the system can trust the identity source of record, the account mapping, and the entitlement data.
Practitioner guidance
- Define the business outcome before configuring workflows Map each IGA use case to a specific control objective, such as faster offboarding, cleaner certification, or reduced orphaned access.
- Normalise identity and entitlement data first Consolidate authoritative sources, standardise account naming, and remove obsolete or duplicate entitlements before expanding automation.
- Phase automation by system criticality Start with high-value applications and the most reliable lifecycle processes, then expand only after integration patterns are stable.
What's in the full article
Twine Security's full blog covers the operational detail this post intentionally leaves for the source:
- The article’s full six-point failure breakdown with concrete examples from live IGA implementations
- Detailed discussion of access certification friction, including manager overload and low-quality review outcomes
- The maintenance burden of role changes, rule updates, and application onboarding in ongoing IGA operations
- Twine Security's perspective on its digital employee framing and how it positions automation inside IAM work
👉 Read Twine Security's analysis of why IGA projects fail →
IGA implementation failures: what governance gaps are teams missing?
Explore further
08/06/2026 5:54 pm
IGA failures are usually governance failures, not technology failures. The article’s six causes all point to the same pattern: organisations start with a tool purchase before they have defined the operating model that tool must support. Clear objectives, stakeholder ownership, data quality, and maintenance discipline are governance prerequisites, not optional extras. When they are missing, the programme produces process friction instead of control value.
A few things that frame the scale:
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means lifecycle controls often operate with partial inventory at best.
A question worth separating out:
Q: How should organisations plan for IGA maintenance after go-live?
A: Teams should plan for continuous role updates, policy changes, integration support, and exception handling as permanent workstreams. IGA is not a deployment that ends at go-live. It is an operational control that degrades unless the programme keeps funding data hygiene, review support, and change management.
👉 Read our full editorial: IGA project failures reveal the governance gaps teams keep missing
