IGA project failures show why identity governance breaks at scale

At a glance

What this is: This is an analysis of six common causes of IGA failure, with the key finding that governance projects break down when objectives, ownership, data quality, and maintenance are not designed up front.

Why it matters: For IAM and NHI practitioners, the article reinforces that access governance is an operating model problem, not just a deployment problem, especially once machine identities and complex approvals enter the mix.

By the numbers:

• A McKinsey study shows IT projects run 45% over budget, 7% over time, and deliver 56% less value than predicted.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Twine Security's analysis of six common IGA implementation failure modes

Context

Identity governance and administration fails when organisations treat it as a software rollout instead of a long-lived control program. The article points to a familiar pattern in IAM: unclear business goals, weak lifecycle ownership, inconsistent data, and heavy maintenance create the conditions for stalled adoption and audit pain, especially once non-human identities are part of the environment.

In NHI-heavy environments, those same weaknesses become more dangerous because service accounts, API keys, tokens, and workload identities multiply faster than human accounts. The governance lesson is straightforward: joiner-mover-leaver discipline, access review quality, and deprovisioning coverage must be designed as operating controls, not improvised during implementation.

Key questions

Q: How should organisations reduce IGA project failure rates?

A: They should start with business objectives, ownership, and lifecycle processes before automation. The highest-value controls are clear joiner-mover-leaver rules, reliable source data, and a phased rollout that matches operational capacity. Without those foundations, the platform will automate confusion rather than governance.

Q: What is the difference between access automation and identity governance?

A: Access automation executes workflows, while identity governance defines who approves, reviews, and owns access over time. Automation can speed up provisioning and certification, but governance is the control structure that makes those actions defensible, auditable, and aligned with business risk.

Q: Why do access reviews often fail in large organisations?

A: They fail when managers are asked to review too many entitlements without enough context to make informed decisions. The result is rubber-stamping, delayed remediation, and weak risk reduction. Effective reviews need fewer items, better context, and clear ownership for follow-up actions.

Q: How should security teams apply IGA lessons to non-human identities?

A: They should extend the same lifecycle discipline to service accounts, API keys, tokens, and certificates. NHI access often persists longer than human access, so provisioning, review, rotation, and offboarding need explicit governance instead of informal ownership.

Technical breakdown

Why IGA projects fail when lifecycle ownership is unclear

Identity Governance and Administration works only when every stage of the identity lifecycle has a named owner. Joiner-mover-leaver processes, access certification, and deprovisioning depend on clear decision rights across HR, IT, application owners, and security. When those responsibilities are vague, teams end up with orphaned access, duplicate approvals, and review fatigue. In practice, IGA platforms expose organisational process maturity as much as they automate it. That is why failed deployments often look like governance failures rather than product failures.

Practical implication: Define lifecycle ownership before automating approvals or certifications.

How data quality and integration failures break access governance

IGA systems depend on accurate identity attributes, authoritative source alignment, and predictable application metadata. Poor HR data, inconsistent account naming, and conflicting directories prevent reliable role-based access control and automated provisioning. This is especially damaging in hybrid environments where humans, service accounts, and API-driven access paths all need different treatment. If the data model cannot distinguish identity types or access sources, the governance layer cannot make safe decisions. The result is manual exception handling that erodes the value of the programme.

Practical implication: Treat source-of-truth cleanup as a prerequisite for governance automation.

Why maintenance cost is a core architectural risk in IGA

IGA is not a one-time implementation. Roles change, access policies evolve, applications are added, and certifications recur. If the platform requires heavy custom development or constant specialist support, the operating cost grows faster than the control value. Cloud-native design, reusable integrations, and simpler policy models reduce this burden, but the underlying issue remains the same: governance must be sustainable after go-live. A system that cannot be maintained at the speed of business change becomes a compliance liability.

Practical implication: Budget for steady-state operations, not just initial deployment.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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. The article is right to centre objectives, stakeholder engagement, and lifecycle ownership because those are the conditions that determine whether access governance works at scale. Tools can automate steps, but they cannot invent decision rights, business context, or accountability. Practitioners should evaluate IGA programmes as operating models first and software projects second.

Identity governance collapses fastest where human processes and machine access intersect. The same weaknesses that undermine access certification for employees also affect service accounts, API keys, and workload identities, but the blast radius is larger because non-human access is often persistent and poorly reviewed. That is why NHI governance has to sit inside the IGA conversation, not beside it. Teams should extend lifecycle control to every identity class before sprawl hardens into risk.

Data quality is the hidden dependency that determines whether automation is trustworthy. Role mining, approval workflows, and provisioning rules all depend on clean identity data and stable attributes. When the source data is inconsistent, the platform compensates with exceptions, manual reviews, and custom logic that make the programme harder to sustain. Practitioners should treat identity data hygiene as a control objective, not a technical cleanup task.

Maintenance cost is where many IGA programmes quietly lose their business case. The article highlights the real problem: every new application, policy change, or exception workflow adds operational drag. In mature environments, the issue is not whether the platform can do more, but whether the organisation can keep governing it without increasing risk and cost. Security leaders should test the steady-state operating model before scaling the programme.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, which explains why remediation remains slow.
• The lifecycle gap is governance, not just tooling, so readers should also review Ultimate Guide to NHIs - Lifecycle Processes for Managing NHIs for a broader control model.

What this signals

Identity programmes should be judged on operational endurance, not deployment completion. The pattern in this article is that many teams can stand up an IGA tool but cannot keep the operating model healthy once integrations, approvals, and certifications start multiplying. For practitioners, the signal is to measure recurring effort, exception volume, and deprovisioning reliability as programme health indicators, not just implementation milestones.

With 97% of NHIs carrying excessive privileges, access governance gaps will increasingly show up in machine identities first. That makes IGA scope expansion unavoidable, because manual processes built for human access cannot keep pace with service accounts and automated workloads. Teams should prepare for identity governance to become a cross-domain control plane, not a human-only compliance exercise.

The next governance bottleneck is not policy design but sustained execution. If identity data remains fragmented and maintenance stays labour-heavy, the programme will drift back toward manual exceptions. Practitioners should align their roadmap with NIST Cybersecurity Framework 2.0 governance and Ultimate Guide to NHIs lifecycle controls so the operating model can absorb change.

For practitioners

• Define lifecycle ownership before deployment Assign clear accountability for joiner-mover-leaver processes, access certifications, and deprovisioning across HR, IT, business owners, and security before configuring the platform.
• Clean up identity data before automating access Validate authoritative sources, standardise account naming, and resolve conflicting attributes so provisioning and certification decisions are based on reliable data.
• Phase integrations by criticality Bring core systems online first, then add lower-risk applications in stages so teams can stabilise workflows and reduce exception volume.
• Track maintenance cost as a security metric Measure the ongoing effort for role updates, policy changes, application onboarding, and certification support so the programme reflects true operating cost.

Key takeaways

• IGA projects fail most often when governance is under-designed and automation is over-trusted.
• Data quality, stakeholder ownership, and lifecycle controls are the real determinants of whether access governance scales.
• Non-human identities make the IGA problem sharper, because unmanaged machine access amplifies every weakness in the operating model.

Key terms

• Identity Governance And Administration: Identity Governance and Administration is the control layer that defines who gets access, who approves it, and how that access is reviewed and removed over time. In practice, it combines lifecycle workflows, certifications, policy enforcement, and auditability across human and non-human identities.
• Joiner-Mover-Leaver Process: A joiner-mover-leaver process governs access from the moment an identity is created through role changes to final removal. It matters because weak lifecycle handling is a common source of excessive access, orphaned accounts, and failed audits in both human and machine identity estates.
• Access Certification: Access certification is the recurring review of existing permissions to confirm they are still appropriate. Effective certification needs context, ownership, and a manageable review load, otherwise it turns into administrative compliance with little real risk reduction.
• Identity Data Hygiene: Identity data hygiene is the practice of keeping authoritative identity attributes accurate, consistent, and usable for access decisions. It is essential for automation because provisioning, role assignment, and review logic all depend on trustworthy source data and clear identity relationships.

Deepen your knowledge

IGA lifecycle governance and access review discipline are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is expanding from human access into service accounts and AI-driven workflows, it is worth exploring.

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