Identity governance and administration fails for six avoidable reasons

At a glance

What this is: This is an analysis of six common IGA implementation mistakes and the governance conditions that cause projects to stall or underdeliver.

Why it matters: It matters because IGA sits at the control point for access reviews, least privilege, and audit evidence across human, NHI, and PAM-governed identities.

By the numbers:

• 50% of implementations of this type are in critical condition, according to Gartner.

👉 Read Soffid’s article on six IGA mistakes that derail governance programmes

Context

Identity governance and administration fails when organisations treat access control as a tooling exercise instead of an operating model. The primary keyword here is identity governance and administration, and the article’s central claim is that project failure usually comes from strategy, sponsorship, process design, and data quality rather than the platform itself.

That pattern is familiar across IAM programmes because recertification, role design, approval flows, and maintenance all depend on clean identity data and business ownership. In practice, weak governance in one part of the stack quickly shows up as excess access, low adoption, or audit friction in another.

Key questions

Q: How should organisations avoid IGA projects failing after implementation?

A: Start with governance ownership, not tooling. Define business approvers, process owners, and success measures before automating anything, then validate that identity data and role structures are accurate enough to support recertification and access reviews. Without those foundations, the platform will produce activity but not control.

Q: Why do IGA programmes often break when access workflows are automated?

A: Automation amplifies the quality of the underlying process. If approvals, role assignments, or exceptions are unclear, automation simply makes those decisions faster and harder to unwind. Organisations should simplify and standardise the workflow first, then automate the parts that are stable and repeatable.

Q: What do security teams get wrong about identity data in IGA?

A: They often treat identity data as a reporting issue instead of a control dependency. In reality, stale attributes, fragmented records, and incorrect entitlement mappings distort recertification, audit evidence, and access enforcement. If the data is unreliable, the governance layer cannot make trustworthy decisions.

Q: Who is accountable when an IGA programme cannot prove least privilege?

A: Accountability sits with the programme owners who defined the operating model, not just the platform team. If no one owns access decisions, review cadence, exception cleanup, and role maintenance, least privilege becomes a slogan rather than an enforceable control. Governance must be assigned, monitored, and maintained.

Technical breakdown

Why IGA programmes fail when business ownership is missing

IGA is not just an IT workflow layer. It depends on business owners, HR, compliance, and process owners agreeing on who approves access, who reviews exceptions, and what risk the programme is meant to reduce. When those stakeholders are absent, the project can still produce forms and approvals, but it cannot produce durable governance because the decision logic has no accountable owner. That is why adoption often collapses after the initial rollout. The issue is not simply lack of participation. It is a governance design flaw that leaves IAM controls detached from the actual organisation that must operate them.

Practical implication: define accountable owners for approvals, reviews, and exceptions before automating any IGA workflow.

Identity data quality and workflow automation in IGA

Automating a broken approval process only makes broken decisions happen faster. IGA depends on reliable identity data, accurate role mappings, and current entitlements. If records are fragmented or stale, the recertification engine will surface the wrong access, the approval chain will route to the wrong people, and audit evidence will be incomplete. In other words, the control layer is only as strong as the identity data underneath it. This is especially true when the programme spans cloud applications, legacy systems, and delegated admin models, where a single bad source record can distort multiple access paths.

Practical implication: cleanse identity data and redesign workflows before scaling automation across connected applications.

User experience, recertification, and maintenance as control factors

IGA succeeds or fails on whether people can use it without creating shortcuts. When recertifications are cumbersome, managers approve in bulk. When request flows are too long, users look for side channels. Maintenance matters for the same reason: roles, policies, and exceptions drift unless they are actively managed after go-live. That makes IGA a lifecycle discipline, not a one-time deployment. The best programme design treats review cadence, role hygiene, and exception cleanup as part of the control surface, not administrative overhead.

Practical implication: measure review completion, exception ageing, and role drift as operational control indicators, not just project metrics.

NHI Mgmt Group analysis

IGA fails first as a governance design problem, not a tooling problem. The article’s six mistakes cluster around ownership, process design, data quality, and maintenance, which means implementation breakdown is usually systemic rather than technical. That is the right lens for IGA, because access governance only works when business accountability, lifecycle controls, and identity data move together. The practitioner conclusion is simple: do not confuse deployment with governance.

Automating broken approval logic creates faster failure, not better control. If a workflow was unclear before automation, the system will simply accelerate bad routing, weak approvals, and inconsistent exceptions. This is the same control trap that appears in every identity programme that digitises process without first simplifying it. The practitioner conclusion is to redesign the process before it is encoded into the platform.

Identity data is the hidden control plane of IGA. Outdated or fragmented identity records undermine recertification, entitlement accuracy, and auditability long before the interface or workflow layer becomes visible. In broader IAM terms, the programme cannot govern what it cannot accurately describe. The practitioner conclusion is to treat data cleansing as a control requirement, not a project task.

Role drift debt: an IGA programme accumulates unresolved exceptions, stale roles, and unmaintained policies when success is measured only at go-live. That assumption fails because governance is continuous, while many implementations are managed as if the rollout is the endpoint. The implication is that lifecycle ownership must survive implementation handoff, or the control model decays.

IGA becomes the enforcement layer for Zero Trust only when it reaches beyond IT administration. Least privilege, audit evidence, and access visibility are all weakened when governance is siloed away from business operations. That is why IGA should be read as an enterprise control discipline, not an admin tool. The practitioner conclusion is to align IGA with operating governance, not just technical provisioning.

From our research:

• 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% partial visibility.
• The same governance discipline should extend into Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs when identity sprawl includes service accounts and workload credentials.

What this signals

Role drift debt: IGA programmes rarely fail only at deployment. They fail when review cadence, policy ownership, and exception cleanup are treated as temporary project tasks instead of permanent operating controls, which means the real signal is maintenance discipline, not go-live status.

For teams that govern both human and non-human access, the next step is to align recertification, least privilege, and lifecycle handling under one control model, then anchor the operating view with the Ultimate Guide to NHIs and the NIST Cybersecurity Framework 2.0.

For practitioners

• Assign named business owners to access decisions Document who approves, who reviews, and who remediates exceptions for each critical access path. Keep compliance and HR involved where joiner, mover, and leaver flows depend on their data, and do not start automation until those owners are visible in the operating model.
• Redesign workflows before automating them Map the current approval path, remove redundant steps, and eliminate bulk-approval pressure points before turning on automation. If the process is broken on paper, digitising it will only preserve the failure at scale.
• Clean identity data at the source Consolidate fragmented identity records, fix attribute quality, and validate entitlement mappings before recertification campaigns begin. The goal is to make access reviews and audit reports reflect actual control states instead of historical noise.
• Track maintenance as part of control effectiveness Measure stale roles, expired exceptions, unresolved tickets, and review completion after go-live. If those indicators deteriorate, the programme has drifted from governance into administration.
• Connect IGA to Zero Trust and PAM governance Use the IGA layer to enforce least privilege across privileged and non-privileged access, including service accounts where lifecycle handling is often weaker. This makes governance consistent across human, NHI, and elevated access paths.

Key takeaways

• IGA fails when ownership, process design, and identity data are weak, not simply when the platform is imperfect.
• The scale of the problem is visible in the statistic that 50% of these implementations are in critical condition, which points to a governance issue rather than a tooling issue.
• Treat workflow redesign, data cleansing, and maintenance as control work, because go-live is only the start of IGA effectiveness.

Key terms

• Identity Governance And Administration: IGA is the set of policies, workflows, and review processes used to control who gets access, who approves it, and how that access is verified over time. In mature programmes, it connects joiner-mover-leaver handling, access certification, and role management into one operating model.
• Recertification: Recertification is the periodic review of existing access to confirm it is still needed and correctly assigned. It is only effective when managers, role owners, and identity data are reliable enough to make accurate decisions, otherwise the process becomes a formality rather than a control.
• Role Drift: Role drift is the slow accumulation of exceptions, stale permissions, and poorly maintained roles that cause access models to diverge from business reality. It usually appears after implementation when governance stops being actively maintained and the original design no longer matches actual operating needs.
• Identity Data Quality: Identity data quality is the accuracy, completeness, and consistency of the records that drive access decisions. In IGA, bad data produces bad approvals, weak recertification outcomes, and unreliable audit evidence, which means the data layer functions as a control dependency, not just a reporting source.

What's in the full article

Soffid's full article covers the operational detail this post intentionally leaves for the source:

• A six-point implementation checklist for assessing whether your current IGA model is ready for rollout.
• Planning questions for business sponsorship, objective setting, phased deployment, and maintenance budgeting.
• Guidance on when to simplify workflows before automation and how to think about integration scope.
• The article's Zero Trust and compliance discussion for teams that need a broader IAM operating model.

👉 Soffid’s full post expands the checklist, rollout questions, and Zero Trust implications for IGA teams.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.