Why do IGA programmes still struggle even when core tooling is already in place?

Why This Matters for Security Teams

IGA programmes usually fail for operational reasons, not because the software is missing. Core tooling can provision, certify, and deprovision access, but it cannot resolve unclear ownership, poor identity data, or inconsistent approval logic on its own. NHI Mgmt Group notes that only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs, which is a useful warning sign for any identity programme that assumes inventory and governance are already aligned. Standards such as NIST SP 800-53 Rev 5 Security and Privacy Controls emphasise control design, but successful IGA still depends on accurate source data and decision ownership. When those inputs are weak, review campaigns become box-ticking exercises and deprovisioning queues fill with exceptions. In practice, many security teams encounter identity risk only after access recertification has already missed stale accounts, orphaned entitlements, or broken joiner-mover-leaver workflows.

How It Works in Practice

IGA works best when tooling is treated as an execution layer for governance, not as governance itself. The practical sequence is straightforward: define who owns each application and entitlement, establish the authoritative source for identity attributes, and then map business roles or access policies to those data sources. Once that is in place, the platform can drive access requests, approvals, periodic reviews, and removals with much less manual interpretation.

The operational bottlenecks usually appear in four places:

• Owner ambiguity, where no one can approve or revoke access with confidence.
• Identity data drift, where HR, directory, and application records disagree.
• Exception overload, where one-off access paths bypass the normal workflow.
• Lifecycle gaps, where deprovisioning is delayed by downstream dependencies.

This is why the governance model has to be explicit. The Ultimate Guide to NHIs — The NHI Market highlights how quickly non-human access can outgrow manual oversight, and the same lesson applies to IGA when environments span SaaS, cloud, and legacy systems. The NIST control family also reinforces that access decisions must be repeatable and evidence-based, not improvised during audit season.

When the programme is mature, the tool can answer basic questions quickly: who requested access, who approved it, what policy justified it, and whether it was removed on time. These controls tend to break down when application owners are outsourced or when entitlement data is embedded in custom code and shadow workflows, because the platform cannot govern what the business has never formally defined.

Common Variations and Edge Cases

Tighter governance often increases administrative overhead, requiring organisations to balance stronger control against the time and coordination needed to maintain it. That tradeoff becomes more visible in hybrid estates, where some applications support clean role models and others only expose coarse permissions or brittle service accounts. Current guidance suggests prioritising the highest-risk applications first, rather than forcing every system into the same review cadence.

There is no universal standard for exactly how many approval layers or review frequencies an IGA programme should use. For low-risk entitlements, overly complex workflows can create so much friction that teams bypass the process entirely. For high-risk access, especially privileged or customer-facing systems, the opposite is true: shorter review cycles, stricter ownership rules, and stronger evidence requirements are usually justified.

Edge cases also emerge when identity data is incomplete. Contractor records, shared mailboxes, inherited admin roles, and machine accounts often sit outside the cleanest parts of the workflow. That is where manual governance must be paired with a stronger identity architecture, not treated as a permanent fix. NHI Mgmt Group’s research on NHI visibility and lifecycle management shows why hidden identities become persistent risk when ownership and revocation are not operationalised.

Related resources from NHI Mgmt Group

• Why do IAM and IGA programmes still struggle to deliver usable experiences for practitioners?
• Why do organisations struggle to operationalise IAM and IGA even when they already have identity tools in place?
• Why do customer identity programmes still need advisory services even when the platform is strong?
• Why do weak identity controls still lead to breaches even in mature security programmes?