What signals show an IGA programme is becoming unsustainable?

Why This Matters for Security Teams

An IGA programme becomes unsustainable when it stops absorbing the rate of business change. The warning signs are usually visible in the queue: more applications waiting for integration, more exceptions being granted manually, and more time spent reconciling entitlements than improving governance. At that point, the programme is no longer operating as a control layer but as a bottleneck.

Security teams often miss the shift because the environment still looks governed on paper. Reviews may still be running, access requests may still be processed, and dashboards may still show activity. But if the process depends on constant human escalation, the model is already fragile. NIST SP 800-53 Rev 5 Security and Privacy Controls frames access control and accountability as ongoing operational duties, not one-time setup work, which is the right lens for judging programme health.

The risk is not only administrative drag. Slow or incomplete integration leaves orphaned access paths, inconsistent role models, and shadow approvals that weaken least privilege. In practice, many security teams encounter the failure only after backlog growth has already turned routine governance into exception handling.

How It Works in Practice

Practitioners should look for a pattern of compounding latency. A sustainable IGA model can onboard new systems, map entitlements, and maintain reviews without each new application requiring a separate project. An unsustainable model instead shows escalating handoffs between identity, application, and business owners. The work shifts from governance to case management.

One useful signal is backlog age, not just backlog volume. A small queue can be manageable if items move steadily. A large queue with items older than one quarter usually indicates that intake, entitlement modelling, and connector work are outpacing delivery capacity. Another signal is a widening gap between the number of connected applications and the number of applications the business actually uses for critical workflows.

In mature environments, teams should be able to automate common tasks such as joiner-mover-leaver workflows, access reviews, and entitlement attestation. Where automation is weak, access recertification becomes a labour-heavy exercise and policy exceptions proliferate. The result is rising maintenance spend, repeated rework, and a growing reliance on system owners who are not aligned to identity operations.

Current guidance suggests evaluating IGA against both control coverage and throughput. A programme that covers fewer systems but keeps pace with change may be healthier than one that nominally covers many systems but cannot sustain updates. NIST CSF 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls both support this view by emphasising governance effectiveness, asset visibility, and controlled access outcomes.

NHIMG research on secrets operations shows how control gaps deepen when teams maintain too many fragmented systems, with The State of Secrets in AppSec reporting an average of 6 distinct secrets manager instances across organisations. That kind of fragmentation often mirrors IGA sprawl: more platforms, more exceptions, and more manual reconciliation.

These controls tend to break down when every application has a unique approval path, because identity teams cannot standardise onboarding fast enough to keep pace with delivery demand.

Common Variations and Edge Cases

Tighter governance often increases short-term overhead, requiring organisations to balance stronger control against delivery speed and integration capacity. That tradeoff matters because some industries genuinely need deeper attestations, more segmentation, and more audit evidence than others.

There is no universal standard for when an IGA programme is “too big” to sustain, so teams should judge by operational symptoms. A highly regulated enterprise may tolerate more process friction, but it still needs predictable cycle times and a stable integration roadmap. By contrast, fast-moving product organisations often fail when identity governance is designed as a central project instead of an embedded operating capability.

Edge cases also matter. Mergers, legacy ERP estates, and heavily outsourced environments can temporarily inflate queues without proving the programme is broken. The key difference is whether the backlog is shrinking after a change window closes. If it is not, the programme has likely hit a structural limit. Teams comparing control maturity against real-world blast radius may also find the TruffleNet BEC Attack — Stolen AWS Credentials case useful as a reminder that unmanaged access sprawl creates incident pathways long before audit findings appear.

In short, sustainability is less about tool count and more about whether the programme can continuously absorb new access demand without turning every change into a bespoke exception.

Related resources from NHI Mgmt Group

• What signals show that a security programme is becoming more adaptive?
• Where does cross-environment agent discovery fit in an IAM programme?
• What signals show that AI spend is becoming a governance problem?
• What signals show that access review processes are becoming too manual?