Why do IGA projects fail when organisations rush into automation?

Why automation fails when the operating model is still undefined

IGA automation works only after the organisation has decided what “good” looks like: who owns each access decision, which lifecycle events trigger change, what evidence is required, and which exceptions are acceptable. When teams automate first, they often hard-code the wrong workflow, then spend months tuning a process that should have been designed around business accountability and identity governance basics.

The failure is usually structural, not technical. Automation amplifies whatever policy and process already exist, so if ownership is unclear or approval paths are inconsistent, the platform simply executes that confusion at speed and scale.

Where rushed automation creates review fatigue and exception debt

Another common failure mode is over-automating access review before the organisation has rationalised roles, entitlements, and review criteria. That produces noisy campaigns, repetitive attestations, and low-quality decisions, which is why access certification often collapses into rubber-stamping when reviewers cannot see context. A well-designed review model should cut volume and target decisions that matter, not force every reviewer to inspect every entitlement in every cycle.

Exceptions become a second form of debt. If there is no clear rule for compensating controls, time-bound approvals, or escalation, teams accumulate one-off cases that bypass the normal lifecycle. The result is an automated front end with manual backdoors, which undermines the point of the programme and leaves access risk unresolved.

Operating model clarity also matters for joiner-mover-leaver flow. If the system does not distinguish birthright access, role-based access, contractor handling, and offboarding triggers, automation can revoke the wrong access, miss stale accounts, or leave former access active long after the business event that should have removed it. That is why lifecycle design should precede orchestration, not follow it.

What successful IGA automation is actually automating

Good IGA automation does not start with tooling decisions, it starts with decisions the business can sustain: ownership, approval authority, entitlement standards, review scope, and remediation paths. Once those are stable, automation can safely handle provisioning, deprovisioning, recurring review, and evidence collection without forcing humans to re-decide the same policy question each time. The Joiner-Mover-Leaver (JML) Guide is useful here because it treats lifecycle as the control plane, not an afterthought.

Role and entitlement design are part of the same problem. If role models are bloated, unstable, or detached from business functions, automation will faithfully distribute bad access at scale. The better pattern is to simplify the role model first, then automate the repeatable decisions that remain. That is also why the Role Mining and Role Design Guide matters: role automation only works when the underlying structure is manageable.

Risk and Threat Considerations

Rushed automation increases the chance that excess privilege, stale access, and unmanaged exceptions persist inside a system that appears controlled on paper. In practice, that creates a broader attack surface because bad access can be granted, retained, or recertified with little human scrutiny, especially when teams trust workflow completion as proof of governance.

Failure mechanism: The organisation encodes incomplete policy, weak ownership, or poor lifecycle triggers into the IGA platform, then scales those defects across many identities and applications.

Impact: Access review quality drops, revocation and recertification become unreliable, and attackers or insiders gain more opportunities to abuse stale or excessive permissions.

Practitioner Guidance

What to prioritise: Define the decision model before configuring the platform. You need named owners, clear approval criteria, entitlement boundaries, and explicit exception handling before automation can be trusted to execute at scale.

What to verify: Test whether the workflow matches the real business event, not just the ticket path. If a mover, leaver, contractor change, or access recertification cannot be explained in business terms by the owner, the automation is probably too early or too broad.

Common mistake: Treating reduced manual effort as success. In IGA, the real measure is whether the control reliably removes bad access, reduces reviewer noise, and produces defensible decisions, not whether the queue moves faster.

Practitioner takeaway: Automate the repeatable decision only after the organisation has made the decision itself repeatable; otherwise the project will scale inconsistency instead of control.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• When does NHI automation become necessary?