Skip to main content

Why IGA Projects Stall: An Honest Assessment - Atricore

A technical breakdown of the four infrastructure problems that cause identity governance implementations to stall.

Sebastian Gonzalez Oyuela February 16, 2026 3 min read
IGA IAM
Why IGA Projects Stall: An Honest Assessment - Atricore

Most IGA projects run into the same four technical problems. Here is what they are and how to address them.

1. Source Data Quality

IGA projects assume HR data is clean. It usually is not.

Common issues include circular or null manager relationships, inconsistent employee ID formats, empty required fields, termination dates on active employees, and future start dates for current staff.

The IGA platform processes whatever data it receives. Problems in source data will appear in your governance processes.

What works: Run data quality analysis before implementation. Build reconciliation reports that identify anomalies. Fix data issues in source systems, not in the IGA platform.

2. Connector Integration Complexity

Target system integration is more complex than RFPs suggest. Mainframe applications often have no API. Legacy systems have outdated schema documentation. SaaS vendors change APIs without versioning. Some systems require proprietary SDKs.

Vendor connector libraries look complete in documentation. In practice, most connectors need customization for attribute mapping, error handling, and retry logic.

What works: Budget engineering time for connector work. Prototype integrations early with production data. Plan for custom development on at least 30% of connectors.

3. Schema Heterogeneity

Identity attributes differ across systems. Active Directory uses sAMAccountName, ERPs use employee numbers, legacy systems use email addresses, Unix systems use UIDs.

Role definitions also vary. “Admin” means different things in different systems. Some systems use nested groups, others use flat structures, others use direct permission assignments.

A clean unified identity model rarely maps to reality. You end up maintaining translation layers per system.

What works: Accept schema differences instead of forcing normalization. Build explicit mapping tables per target system. Document edge cases. Use flexible schema capabilities from platforms like midPoint.

4. Reconciliation Performance at Scale

Initial testing works fine. Then you connect 50,000 identities across 30 target systems and nightly sync takes 14 hours. Add certification campaigns evaluating millions of entitlements and performance becomes a problem.

Each new target system multiplies reconciliation time. Historical data retention grows storage requirements.

What works: Design for production scale from day one. Test with realistic data volumes. Use incremental reconciliation instead of full syncs. Partition certification campaigns. Archive historical data.

Summary

These are engineering problems with engineering solutions. They require technical investment that project plans often underestimate.

midPoint from Evolveum addresses these challenges with its flexible schema model, extensible connector framework, and scalable reconciliation engine.

If your project is stuck on any of these issues, contact us. We do IGA implementations.