Notifications
Clear all
Topic starter
06/07/2026 9:35 am
TL;DR: IGA programmes often go live with core connectors and JML flows in place, yet the long tail of custom, legacy, and SaaS applications still gets provisioned manually, according to StackBob. That gap keeps growing because native connector development and custom builds do not scale with real enterprise application sprawl, and coverage stops being visible after go-live.
NHIMG editorial — based on content published by StackBob: IGA coverage gaps and agentic provisioning
By the numbers:
- Typical application connects in under 48 hours without custom development or additional engineering scope.
Questions worth separating out
Q: How should IGA teams close application coverage gaps in large estates?
A: Start by identifying every application that still depends on manual provisioning or bespoke handling, then rank them by business criticality and access risk.
Q: Why do custom connectors become a long-term governance problem?
A: Custom connectors solve immediate coverage issues, but they create maintenance obligations that grow with every application change.
Q: What breaks when a large part of the application estate stays manual?
A: Access governance breaks at the edges of the estate.
Practitioner guidance
- Quantify the unmanaged application tail Inventory every application still relying on manual provisioning, app-owner queues, or helpdesk intervention.
- Map coverage to access risk and audit exposure Tie each unsupported application to the identities and access paths it controls, then score the impact of delayed provisioning and delayed deprovisioning.
- Use application coverage as a board-level metric Report governed application coverage alongside joiner-mover-leaver completion, recertification outcomes, and manual exception volume.
What's in the full article
StackBob's full article covers the operational detail this post intentionally leaves for the source:
- The vendor's client-facing five-year TCO framework for quantifying coverage gaps across internal overhead, audit findings, and access delay.
- The deployment model for extending IGA coverage without re-architecture of programs already in flight.
- The partner scoping approach for converting application coverage into a sales and retention conversation.
- The practical support model for technical questions, client negotiations, and implementation planning.
👉 Read StackBob's analysis of IGA coverage gaps and agentic provisioning →
IGA coverage gaps and manual provisioning: what teams should do now?
Explore further
06/07/2026 9:50 am
Application coverage is the real IGA control boundary. If provisioning still depends on helpdesks or app owners for a meaningful part of the estate, then the governance programme is not complete. The connector stack may be live, but the control boundary ends wherever manual handling begins. Practitioners should treat coverage as the test of whether IGA is actually governing the environment.
A few things that frame the scale:
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
A question worth separating out:
Q: How can teams tell whether IGA coverage is actually improving?
A: Track the percentage of applications under automated provisioning and reconciliation, the volume of manual exceptions, and the time it takes to onboard unsupported systems. If coverage expands while exception volume falls, the programme is becoming more governable rather than merely busier.
👉 Read our full editorial: AIga coverage gaps persist where connectors and custom builds fail
