IGA project failures reveal the governance gaps teams keep missing

At a glance

What this is: This is a critique of why IGA projects fail, with the core finding that weak objectives, poor adoption, integration issues, and maintenance burden turn governance into operational drag.

Why it matters: It matters because IGA failure leaves joiner-mover-leaver controls, access reviews, and entitlement governance incomplete across human, NHI, and autonomous identity programmes.

By the numbers:

• A McKinsey study found IT projects run 45% over budget, 7% over time, and deliver 56% less value than predicted.

👉 Read Twine Security's analysis of why IGA projects fail

Context

IGA fails when organisations treat identity governance as a software deployment instead of a cross-functional operating model. Without clear ownership, clean data, and realistic workflows, access certification, provisioning, and lifecycle controls become bottlenecks rather than controls.

That failure pattern affects human users, service accounts, and increasingly machine identities because all three rely on the same governance disciplines. For the NHI side of the equation, the Ultimate Guide to NHIs is the clearest reference point for lifecycle, visibility, rotation, and offboarding expectations.

The article is really about governance maturity, not tooling selection. Twine Security uses IGA failure modes to show how programme design, adoption, and maintenance determine whether identity control reduces risk or simply adds another layer of manual work.

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 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. When no one owns the full process, access stays assigned too long, offboarding becomes inconsistent, and certification outcomes lose accountability. The result is a governance gap, not just a workflow delay.

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. If HR records are incomplete, account names are inconsistent, or authoritative sources conflict, automated provisioning and access decisions become unreliable. In that state, the tool amplifies bad inputs rather than correcting them.

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.

Technical breakdown

Why IGA programmes fail before access reviews begin

IGA breaks early when the operating assumptions are wrong. If teams do not define business objectives, ownership boundaries, and success criteria up front, the programme cannot map access controls to actual organisational processes. That is why joiner-mover-leaver design, approval routing, and certification scope need to be decided before rollout. The failure is structural: the governance model is incomplete, so the product inherits ambiguity and cannot resolve it.

Practical implication: define lifecycle ownership, review scope, and business outcomes before configuring certification or provisioning workflows.

Data quality, entitlement sprawl, and integration failure

IGA depends on reliable identity, account, and entitlement data. Poor HR records, inconsistent account naming, conflicting authoritative sources, and obsolete entitlements all break automated decisions because the system cannot confidently correlate who has what access. Integration complexity makes this worse, especially when application onboarding requires custom code or heavy manual mapping. In practice, automation amplifies bad data unless the underlying identity model is normalised first.

Practical implication: clean authoritative sources and entitlement inventories before expanding automation across additional systems.

Costly maintenance is a governance design problem

IGA maintenance costs rise when role models, approval logic, and provisioning rules are built as static artefacts in a changing business. Every organisational shift creates new exceptions, every policy change creates new rule updates, and every new application creates more integration work. The article’s point is that IGA is not a one-off implementation. It is an ongoing control plane that only stays useful when there is continuous operational ownership.

Practical implication: budget for lifecycle upkeep, rule maintenance, and integration support as permanent programme capacity.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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 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.

Identity governance collapses when joiner-mover-leaver design is treated as an IT detail. The article repeatedly shows that lifecycle ownership between HR, IT, and business units is where implementation quality is won or lost. That is consistent with NIST Cybersecurity Framework 2.0 and the Ultimate Guide to NHIs: identity control only works when governance is mapped to real business flows. Practitioners should treat lifecycle ownership as a control boundary, not a workflow convenience.

Entitlement review without context creates certification theatre. If managers are asked to approve thousands of access items with no business context, the process becomes rubber-stamping rather than risk reduction. This is the same failure mode seen across human IAM and NHI governance: review volume grows faster than review quality. The result is false assurance, not control.

Scalable IGA design is now a prerequisite for hybrid identity estates. The article’s point about M&A, complex approvals, and integration effort matters because identity programmes no longer govern only employee accounts. They must absorb service accounts, API credentials, and eventually autonomous agents without rebuilding the operating model each time. The practical conclusion is that identity governance must be architected for change, not for a single-state environment.

From our research:

• 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.
• The lifecycle section of Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the next step for teams that need an operating model, not just a tool.

What this signals

Lifecycle governance is becoming the real test of identity maturity. Once organisations move beyond employee access, the same programme must handle service accounts, API keys, and machine-driven workflows with consistent ownership and review cadence. That is why the gap between inventory and action matters more than the headline feature set of any IGA platform.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, identity programmes that cannot continuously maintain access scope will keep generating excess entitlement risk. The operational question is no longer whether IGA can track access, but whether the organisation can sustain the governance work required to keep it accurate.

Certification theatre is a named failure mode. When review volume outpaces reviewer context, the control becomes a ritual instead of a decision process. Teams should watch for this as they scale IGA across hybrid estates, because the same pattern will show up in NHI reviews and eventually in autonomous access governance as well.

For practitioners

• 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. If the objective cannot be stated plainly, pause implementation until ownership and success criteria are agreed across HR, IT, and business stakeholders.
• Normalise identity and entitlement data first Consolidate authoritative sources, standardise account naming, and remove obsolete or duplicate entitlements before expanding automation. Clean data is the precondition for reliable role modelling, provisioning decisions, and access reviews.
• Phase automation by system criticality Start with high-value applications and the most reliable lifecycle processes, then expand only after integration patterns are stable. This reduces rework and avoids forcing a universal rollout across systems with different approval rules.
• Budget for ongoing governance operations Treat role maintenance, exception handling, review support, and application onboarding as recurring operating costs. IGA programmes fail when teams fund implementation but not the people and processes needed to keep the control plane accurate.

Key takeaways

• IGA programmes fail most often because governance design, ownership, and data quality are unresolved before implementation begins.
• The article’s failure modes map to real operational risk, from rubber-stamped reviews to broken offboarding and expensive custom integrations.
• Teams need to fund IGA as a continuous control plane, not a one-time deployment, if they want durable identity governance.

Key terms

• Identity Governance and Administration: Identity Governance and Administration is the discipline that defines, reviews, and controls who or what should have access to systems and data. It combines lifecycle management, access certification, and policy enforcement so organisations can prove access is appropriate and remove it when it is no longer needed.
• Joiner-Mover-Leaver Process: A joiner-mover-leaver process is the lifecycle workflow used to grant, change, and remove access as people or systems enter, change role, or exit. In mature programmes, it ties identity changes to authoritative sources and ownership so access does not drift beyond business need.
• Access Certification: Access certification is the periodic review and approval of existing entitlements to confirm they are still necessary. It is only effective when reviewers have enough context to make informed decisions, otherwise the process becomes a compliance exercise rather than a control.
• Entitlement Sprawl: Entitlement sprawl is the accumulation of unnecessary, duplicate, or obsolete permissions across accounts and applications. It increases operational noise, weakens least privilege, and makes governance harder because teams cannot easily tell which access is still justified.

Deepen your knowledge

IGA lifecycle design, entitlement governance, and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a programme that must govern both human and non-human access, it is worth exploring.

This post draws on content published by Twine Security: 6 Common Causes of Failure in IGA Projects. Read the original.