Where do IGA projects usually fail in practice?

Where IGA Projects Break Between Policy and Execution

IGA rarely fails because the concept is wrong. It fails when the operating model is unclear: who owns workforce data, who keeps integrations accurate, and who is accountable for access decisions once the workflow leaves the governance team. That gap turns a control programme into a queue of exceptions, manual fixes, and delayed remediation.

The most reliable sign of trouble is that the project is still described as an “IGA team” effort instead of a business process. If the business only approves requests, but IAM and IGA Basics is not reflected in day-to-day ownership, then the programme has not moved from design into control. In practice, the handoff breaks at joiner-mover-leaver events, access reviews, and entitlement changes.

That is why projects often succeed in workshops and fail in production. The control path depends on authoritative source data, clean identity relationships, and a decision owner who can act when access is wrong. When those inputs are partial or delayed, the IGA tool can still generate tickets, but it cannot reliably produce correct outcomes.

Why Onboarding, Offboarding, and Certifications Fail First

Onboarding fails when provisioning depends on manual interpretation of forms instead of a governed source of truth. Offboarding fails when leaver events arrive late or the process stops at account disablement rather than closing every access path tied to the identity. Certifications fail when reviewers are asked to approve lists they do not understand, so the process becomes a signature exercise rather than a control.

Joiner-Mover-Leaver (JML) Guide is the clearest example of where practice and tooling diverge: the workflow only works when HR events, provisioning logic, and revocation steps are aligned. If any one of those is owned elsewhere, the control becomes brittle and access drift accumulates.

Access review programmes fail for a similar reason. If reviewers receive too many entitlements, too little context, or stale business ownership metadata, they approve by habit. The result is rubber-stamping, which preserves excessive access instead of removing it.

What Sustainable IGA Depends On Under the Hood

Good IGA is not mainly a platform question. It is a design question about ownership, role structure, lifecycle timing, and whether the organisation can keep identity data accurate enough for decisions to be trusted. Without stable role models and clear approval paths, every exception becomes a bespoke process.

Role Mining and Role Design Guide matters here because bad role design is a common reason programmes stall. If roles explode, or if business and technical roles are mixed together, the IGA team inherits complexity that no workflow can fully hide.

Many projects also underestimate how much lifecycle control depends on downstream systems behaving consistently. A deprovisioning event is only effective if the connected applications, entitlement owners, and reconciliation logic all respond in the same way. Otherwise, orphaned access survives the control and the programme creates a false sense of closure.

Risk and Threat Considerations

When IGA fails at handoff points, the main risk is not just inefficiency, it is control decay. Missed offboarding, stale roles, and unowned access decisions create standing privilege, audit gaps, and a larger attack surface for misuse or compromise.

Failure mechanism: Ownership gaps let the workflow stop at the boundary between governance and operations, so identity data ages, access reviews lose context, and revocation never fully propagates.

Impact: Organisations end up with excessive access, delayed termination, recurring exceptions, and a higher likelihood that privileged or dormant access will be abused or simply go unnoticed.

Practitioner Guidance

What to prioritise: Treat ownership as a control requirement, not a programme detail. The first question is not which platform to buy, but which team owns authoritative identity data, integration quality, and final access decisions when the workflow needs escalation.

What to verify: Test the end-to-end path for a joiner, mover, and leaver event using real data and real systems. Verify that the event reaches every connected application, that review decisions are actionable, and that revocation is measurable rather than assumed.

Common mistake: Do not let the programme define success as “reviews completed” or “tickets closed.” A control is only working if access changes are actually implemented, exceptions are tracked to closure, and stale entitlements are removed on schedule.

Practitioner takeaway: IGA succeeds when governance ownership and operational ownership are explicitly connected; if the handoff is ambiguous, the control degrades into administration.

Related resources from NHI Mgmt Group

• When does AI model governance usually fail in practice?
• Where do smart card programmes usually fail in practice?
• Where do RDP and VPN controls usually fail in practice?
• Where do functional API tests usually fail in practice?