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.
At a glance
What this is: This is an analysis of why IGA programmes still leave many applications provisioned manually even after core connectors and JML flows are implemented.
Why it matters: It matters because unresolved coverage gaps weaken governance visibility, keep access work in helpdesk queues, and limit the value of identity programmes across human and non-human access paths.
Context
Identity governance coverage is only real when the programme can reach the full application estate, not just the apps covered by the original connector plan. In many environments, the implementation succeeds technically but leaves a large manual tail behind, especially across legacy systems, custom builds, SaaS apps without SCIM support, and shadow IT.
That gap is a governance problem as much as an integration problem. If access decisions still depend on helpdesk queues or app owners after go-live, the organisation has partial oversight, not complete lifecycle control. The article argues that this is the point where many IGA programmes stop being visible in operational terms.
Key questions
Q: Why do IGA programmes still leave applications manually provisioned after go-live?
A: Because connector scope rarely keeps pace with the full application estate. Native integrations cover the common systems first, while legacy platforms, custom builds, and SaaS apps without SCIM support remain outside automated lifecycle control and fall back to helpdesk or app-owner queues.
Q: What happens when identity teams rely on custom connectors for every uncovered app?
A: The programme inherits a build-and-maintain burden that scales poorly. Each bespoke connector adds engineering effort, ongoing support, and change management overhead, so the long tail remains expensive to govern and the coverage gap never fully closes.
Q: How do teams know if IGA is actually working?
A: Look for evidence that entitlement changes are being governed before access expands beyond need. Useful signals include shorter exception queues, fewer unresolved access outliers, and review outcomes that lead to measurable entitlement reduction rather than paperwork completion.
Q: What should identity leaders do when the application tail is too broad for custom builds?
A: Prioritise a portfolio approach. Reserve bespoke integrations for high-value systems, then use a broader coverage strategy for the rest of the estate so governance does not depend on one-off connector projects.
Technical breakdown
Why IGA connector scope becomes a moving target
IGA programmes usually start with the highest-volume applications because those are the easiest to connect through native integrations. The problem is that enterprise estates do not stay still. New SaaS tools, niche systems, and legacy platforms appear faster than vendor connector roadmaps can absorb them. That means coverage is not a fixed implementation outcome but a continuously shifting boundary between governed and manual access. In practice, the gap is not caused by one failed project. It is created by the mismatch between static connector scope and dynamic application growth.
Practical implication: measure coverage as an ongoing control surface, not as a one-time implementation milestone.
Why custom connectors do not scale across real estates
Custom connector development can close individual gaps, but each connector becomes a bespoke asset with its own build, test, support, and maintenance burden. That makes it a poor fit for long application tails where the business case for a dedicated build is weak. The operational reality is that every custom connector consumes specialist time both upfront and after deployment, so the backlog never really disappears. This is why the article frames the problem as a moving target rather than a backlog that can be cleared.
Practical implication: reserve custom builds for high-value systems and use a broader coverage strategy for everything else.
How non-SCIM applications create governance blind spots
When an application lacks SCIM, a native API, or a connector, provisioning often reverts to manual workflows outside the normal IGA control plane. That breaks the chain of auditable lifecycle events because approvals, fulfilment, and reconciliation are no longer guaranteed to sit inside the same governed process. The result is not just slower onboarding. It is reduced certainty about who has access, whether access matches intent, and whether revocation has actually completed. For identity teams, the gap is operational first and audit second.
Practical implication: identify which applications cannot participate in automated lifecycle controls and treat them as priority coverage exceptions.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Coverage debt is the hidden failure mode in many IGA programmes: the implementation is not wrong, but the estate continues to grow beyond the connector set. Core applications look governed while the long tail stays manual, which makes the programme appear healthier than it is. The practical conclusion is that teams should treat incomplete connector reach as governance debt, not an edge case.
Custom connector dependence creates lifecycle drag: bespoke integrations move too slowly and cost too much to be the default answer for every uncovered application. Each one adds maintenance obligations that accumulate as the estate changes, so the control surface lags the business. The implication is that IGA architecture has to be designed around scale, not just completeness at launch.
Manual provisioning is where visibility disappears after go-live: once access moves to helpdesk queues or app-owner inboxes, lifecycle evidence fragments and recertification becomes weaker. That does not just increase operational friction, it undermines the claim that the programme governs the whole estate. Teams should measure how much of their application footprint still sits outside governed fulfilment.
Coverage gap assessment is a portfolio question, not a connector question: practitioners should stop treating every uncovered application as a standalone integration project. The real decision is which gaps warrant bespoke treatment and which demand a broader operating model for unmanaged application tails. That changes how identity teams justify investment, report risk, and prioritise remediation across the estate.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
What this signals
Coverage debt is now a programme-level governance issue: once manual provisioning becomes the default for a large application tail, the organisation no longer has a single access lifecycle model. That shifts identity work from implementation success to control consistency, which is where many IGA programmes lose credibility.
Application estate growth, not connector effort, determines the ceiling of governance: the pace of new SaaS, legacy, and custom systems will usually outrun bespoke integration work. Teams should therefore plan for repeatable coverage expansion rather than assuming the original rollout will eventually reach everything.
For practitioners
- Map the unmanaged application tail Inventory every application still handled outside automated IGA flows, including legacy systems, SaaS apps without SCIM support, and shadow IT. Quantify how many access requests still depend on helpdesk or app-owner queues so the coverage gap is visible in operational terms.
- Separate high-value builds from long-tail exceptions Use a triage model that reserves custom connector work for strategically important applications and assigns the rest of the tail to a broader coverage strategy. The goal is to stop bespoke development from becoming the default response to every uncovered app.
- Track governed coverage after go-live Measure the percentage of the estate that participates in automated provisioning, reconciliation, and recertification after implementation is complete. Treat declining coverage as a programme health signal, not an implementation footnote.
- Build a defensible business case for closing gaps Use a coverage gap assessment to quantify internal effort, access delay, and audit friction across the current estate. That lets identity teams prioritise remediation based on business impact rather than connector convenience.
Key takeaways
- IGA implementations can be technically successful and still leave a large portion of the application estate outside automated governance.
- The main constraint is not connector existence alone but the speed, cost, and maintenance burden of extending coverage across a changing estate.
- Identity teams need a portfolio model for coverage expansion if they want governance to stay visible after go-live.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | Manual access handling often leaves lifecycle events incomplete across uncovered applications. |
| Recommendation — Treat uncovered applications as lifecycle exceptions and close their offboarding path before access drifts. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on incomplete entitlement governance across the application estate. |
| Recommendation — Extend entitlement governance to the full application portfolio and measure gaps outside automated workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Manual provisioning reflects weak account lifecycle coverage across systems that lack connectors. |
| Recommendation — Apply account management controls to every uncovered application and track the exceptions separately. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Incomplete coverage weakens enforcement of least privilege across the long tail of apps. |
| Recommendation — Use least-privilege review to prioritise which manually managed applications need automated coverage first. | ||
Key terms
- Coverage Gap: A coverage gap is the space between what an access control programme claims to manage and what it actually governs in production. In PAM, this often appears when new resource types, teams, or protocols require exceptions, manual handling, or separate tooling, leaving important privileged pathways outside policy consistency.
- Connector scope: The exact permissions and environmental reach granted to an integration that links a workflow to another system. For chat-driven automation, connector scope defines what the workflow can read, change, publish, or deploy, and it should be treated like privileged access rather than a convenience setting.
- 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.
- Long Tail Of Applications: The long tail of applications is the set of systems that do not have ready-made connectors or easy onboarding paths. These apps are often small, specialised, or well documented, yet they still create governance risk because they linger outside central identity control and accumulate in backlog.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 6, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org