AIga coverage gaps persist where connectors and custom builds fail

At a glance

What this is: This is a practitioner analysis of why IGA programmes still leave too much of the application estate outside automated governance, even after core implementation milestones are met.

Why it matters: It matters because manual provisioning and disconnected app coverage create ongoing access risk across NHI, autonomous, and human identity programmes, while also weakening auditability and lifecycle control.

By the numbers:

• The target is 90% application coverage as a baseline, not a ceiling.
• Typical application connects in under 48 hours without custom development or additional engineering scope.

👉 Read StackBob's analysis of IGA coverage gaps and agentic provisioning

Context

Identity governance fails when the programme only covers the applications that were easy to connect during the initial rollout. The real problem is the unmanaged tail: legacy systems, bespoke tools, and SaaS platforms without SCIM support still depend on manual provisioning, which leaves access decisions outside the governance model.

For IAM and IGA teams, the issue is not connector availability alone. It is programme coverage, operational drift, and the cost of keeping lifecycle controls aligned with a growing application estate that never stands still.

Key questions

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. The goal is not to automate everything at once. It is to widen governed coverage steadily while reducing the number of identities that sit outside JML and access review processes.

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. Over time, the programme shifts from governing access to continuously supporting exception paths. That makes connector sprawl a lifecycle and operating-model issue, not just an engineering expense.

Q: What breaks when a large part of the application estate stays manual?

A: Access governance breaks at the edges of the estate. JML actions, deprovisioning, and recertification lose consistency when app-owner queues or helpdesks still handle key systems. The result is uneven control, slower remediation, and weaker audit evidence across the unmanaged tail.

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.

Technical breakdown

Why connector scope becomes a governance ceiling

IGA implementations usually begin with the applications that have native connectors or clean API support. Everything else gets deferred to manual workflows, custom development, or app-owner queues. That creates a structural ceiling because governance only works where provisioning, reconciliation, and deprovisioning are automated. Once the estate includes legacy platforms, niche SaaS tools, and shadow IT, the programme no longer governs the full access surface.

Practical implication: Measure application coverage as a control outcome, not an implementation milestone.

Why custom connectors do not scale

Custom connector development can close gaps, but each build becomes a bespoke asset with ongoing maintenance cost. Every API change, authentication update, or application change turns into another support obligation. Over time, the connector portfolio itself becomes a governance burden, because the organisation is funding exception handling instead of reducing it. That makes scale dependent on engineering capacity, not identity policy.

Practical implication: Treat bespoke connector work as a temporary bridge, not the operating model.

How agentic IGA changes the application coverage model

Agentic IGA extends the existing IGA platform into applications that lack SCIM, native APIs, or prebuilt connectors by handling the provisioning interaction and reconciliation on behalf of the upstream system. The technical shift is not just automation. It is the ability to preserve the governance workflow while changing the execution layer that reaches the target application. That matters most where the estate keeps growing faster than vendor connector roadmaps.

Practical implication: Assess whether the platform can extend governance reach without re-architecture or new engineering scope.

NHI Mgmt Group analysis

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.

Custom connector debt is a governance risk, not just a delivery cost. Every bespoke build adds maintenance overhead, update risk, and future exception handling. The longer a team relies on custom work to close coverage gaps, the more the programme shifts from policy enforcement to technical upkeep. That is a sign the operating model has become brittle.

Lifecycle governance only matters when the application tail is inside scope. JML flows and access reviews lose force if a large share of the estate still sits outside automation. The practical failure mode is not missing intent but missing execution, because the identities most likely to drift are the ones no platform reaches. Teams should reframe the issue as access governance coverage, not tool adoption.

Coverage gaps expose the difference between governance and orchestration. A platform can orchestrate requests across the systems it knows, but governance fails when unknown or unsupported applications remain outside that path. The named concept here is application coverage gap: the portion of the estate that sits beyond automated identity controls. Practitioners need to quantify it as part of programme health, not leave it as an implementation footnote.

Agentic extension models are now competing with connector roadmaps. The market signal is that enterprises need governance reach faster than traditional vendor development cycles can deliver it. That does not make every extension architecture equal, but it does show where practitioner demand is headed. IAM and IGA teams should expect more pressure to prove coverage across the long tail, not just the core applications.

From our research:

• 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.
• That gap points to the next step for identity teams: Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs turns coverage and lifecycle control into an operating model, not a one-off project.

What this signals

Application coverage will become a core programme health metric. Teams that still treat connector scope as a delivery issue will miss the governance impact of the unmanaged tail. The next planning cycle should measure how much of the estate is actually under automated identity control, not how many implementation tickets are closed.

Coverage gaps are widening faster than manual teams can absorb them. With 70% of organisations granting AI systems more access than they would give a human employee performing the exact same job, per the 2026 Infrastructure Identity Survey, the pressure on IGA programmes is moving from human app sprawl to mixed estates that include AI and machine access. That shifts the governance problem from connectors alone to lifecycle reach across all identity types.

Application coverage gap: the part of the estate that remains outside automated identity controls is becoming the operational definition of IGA maturity. If a team cannot govern the long tail, then go-live success is only partial success, and audit confidence will keep lagging behind platform deployment.

For practitioners

• Quantify the unmanaged application tail Inventory every application still relying on manual provisioning, app-owner queues, or helpdesk intervention. Separate connectors, custom builds, and fully manual paths so you can show where governance stops and where access work is still outside automation.
• 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 that mapping to prioritise the systems that create the largest governance gap first.
• Use application coverage as a board-level metric Report governed application coverage alongside joiner-mover-leaver completion, recertification outcomes, and manual exception volume. That makes the hidden tail visible and prevents go-live from being mistaken for programme maturity.
• Separate temporary connectors from durable operating models Treat custom connector work as exception handling with a lifecycle plan, not as the default path for new integrations. If the estate depends on repeat bespoke work, the programme is funding technical debt instead of reducing it.
• Evaluate whether extension preserves governance state Confirm that any extension layer receives provisioning requests from the upstream IGA platform and maintains reconciliation rather than creating a parallel workflow. If it cannot preserve governance state, it is only moving the manual problem elsewhere.

Key takeaways

• The core IGA problem is not whether the platform is live, but whether the full application estate is actually under governance.
• Manual provisioning, custom connectors, and unsupported apps create an unmanaged tail that weakens lifecycle control and auditability.
• Teams should measure coverage, exception volume, and onboarding speed together, because those indicators show whether the programme is scaling or just accumulating debt.

Key terms

• Application Coverage Gap: The portion of an application estate that is not governed by automated identity controls. In practice, this is where manual provisioning, delayed deprovisioning, and inconsistent access review tend to accumulate, creating a blind spot between policy intent and operational enforcement.
• Custom Connector Debt: The ongoing maintenance burden created when access automation depends on bespoke integrations instead of scalable platform coverage. It is not just a build cost. It is a recurring governance liability because every application change can turn into support work and exception handling.
• Manual Provisioning Tail: The group of applications and access paths that remain outside automated IGA flows after the core platform is live. This tail is often the hardest part of the estate to govern, because it relies on people, queues, and memory rather than policy-driven execution.

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.

👉 The full StackBob article covers the coverage-gap model, partner economics, and deployment approach.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.