API coverage is not enough for IGA governance at scale

Editorial analysis by NHI Mgmt Group, based on content published by Opnova: “The Governance Ceiling: Why API Coverage Was Never the Finish Line”.

At a glance

What this is: This is an analysis of why connector-based IGA leaves persistent coverage gaps, with Opnova arguing that API coverage is an architectural ceiling rather than a delivery problem.

Why it matters: IAM and IGA teams need to measure how much of the application estate is actually governed, because connector velocity alone cannot close gaps across SaaS, custom apps, and changing APIs.

By the numbers:

• Omdia's research on enterprises averaging roughly 1,100 applications found that only 54% are adequately integrated with IGA.
• Enterprise IGA teams typically govern about 20% of their application estate out of the box, on platforms they already bought and already pay to maintain.
• The average SaaS stack per organization is up 11% year over year, from an average of 116 apps to 164 in a single year.
• A study of 2,224 API specifications found that of the versions introducing breaking changes, 87.3% gave no prior deprecation warning.

Context

IGA programmes often assume that coverage expands as teams add connectors, but this article argues that the deeper issue is architectural dependence on APIs controlled by application owners. In practice, connector models inherit the change cadence of systems the IGA team does not own, which makes coverage a moving target rather than a finite implementation.

The article centres on governed surface, meaning the portion of the application estate that is actually under identity governance at any point in time. That framing matters because it shifts the question from how fast connectors can be built to how much of the estate can be governed when APIs break, disappear, or never existed in the first place.

Key questions

Q: What breaks when IGA relies on connectors for application coverage?

A: Connector-based IGA breaks when the target application changes its API, retires the interface, or never exposes a stable integration contract. The governance team then inherits a moving dependency it does not control, so coverage becomes partial and fragile rather than durable. The practical test is whether governance can survive application-owner change without a rebuild.

Q: Why do custom IGA connectors still leave coverage gaps?

A: Custom connectors do not remove the architectural dependency on an external API. They simply move the maintenance burden to one team for one environment, which often increases cost and slows recovery when the target system changes. That means the coverage gap is not solved, only financed differently, and often less efficiently.

Q: How do security teams know if business-driven IGA is working?

A: Look for falling revocation latency, fewer orphaned accounts, fewer unused entitlements, and faster completion of access changes after joins, moves, and exits. If review outcomes improve but stale access still persists between cycles, the programme is only documenting risk instead of reducing it.

Q: How should teams govern disconnected applications that do not expose APIs?

A: Treat them as governed exceptions with a defined workflow, not as informal manual tasks. The control design should preserve approval, execution, and evidence capture in one path so the identity record stays complete enough for audit and access review.

Technical breakdown

Why connector-based IGA hits an architectural ceiling

Connector-based IGA depends on a stable API, a maintained schema, and a target system that preserves the integration contract. When the application owner changes, retires, or restructures that API, the connector breaks regardless of how mature the IGA platform is. This is not a tooling defect so much as a control dependency: the governance layer sits downstream of a system it does not control. The result is a ceiling on coverage, because every new application adds both governance scope and integration fragility.

Practical implication: treat connector coverage as a dependency risk, not a finish line.

Why custom connectors do not solve coverage gaps

Custom connectors shift the maintenance burden from the platform vendor to the internal team or implementation partner, but they do not remove the underlying API dependency. They often create a one-off integration that is harder to scale, harder to support, and slower to repair when the target system changes. In identity governance terms, that means the organisation has bought a temporary control path, not a durable one. The article’s core point is that cost moves, but the ceiling remains.

Practical implication: model custom connectors as recurring operational debt rather than permanent coverage.

What governs applications when no connector exists

The article points to a different operating model: governing the application through the interface rather than through an API. That is a materially different control approach because it removes reliance on third-party API stability and extends governance to systems that were never designed for clean integration. For IGA teams, this changes the control question from inventorying available connectors to determining whether the application can be governed through human or automated interaction paths when integration is absent or brittle.

Practical implication: include non-API governance paths in your coverage strategy.

NHI Mgmt Group analysis

Governed surface is the right control metric, not connector count: identity governance programmes fail when they measure deployed capability instead of actually controlled application surface. Connector availability is a proxy, not an outcome, because the real question is how much of the estate is under enforceable governance at this moment. Practitioners should reset reporting around governed surface so programme value reflects control, not architecture theatre.

API dependency creates a structural coverage ceiling: connector-based IGA assumes the target application will preserve the integration contract long enough for governance to remain effective. That assumption fails in modern application estates where APIs change, disappear, or never existed in a stable form. The implication is that governance architecture must be evaluated against third-party control of the interface, not just internal delivery speed.

Custom connectors are maintenance debt, not a coverage strategy: moving connector development to professional services or internal teams changes the cost centre, not the risk model. The article correctly shows that bespoke build effort still depends on someone else’s API lifecycle, which means every custom connector inherits future breakage and rework. Practitioners should treat each bespoke connector as an operational liability that must be justified by governed surface gained.

Screen-based governance deserves more attention in disconnected estates: if an application can only be governed through the interface, identity teams need a distinct operating model for those systems instead of forcing every use case into the connector paradigm. That does not mean manual work is ideal; it means the control design must match the application reality. The practical conclusion is that disconnected applications should be first-class citizens in coverage planning, not exceptions hidden in service queues.

Measuring application estate coverage by purchase state masks the real gap: platforms can be fully licensed, fully deployed, and still leave a large share of the estate outside governance. The article’s 20% out-of-the-box observation captures a common failure mode: capability exists on paper, but governed reach remains narrow. The right posture is to measure what is actually certified, reviewed, or controlled across the live estate, then design for expansion from there.

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.
• Read next: IGA Buyer's Guide

What this signals

Governed surface is the control boundary that matters: connector counts and product features do not describe how much of the estate is actually under identity governance. Practitioners should watch for a widening gap between purchased capability and live coverage, especially as application estates keep growing and breaking changes arrive without warning.

API stability should be treated as an identity governance dependency: if the target system controls the interface lifecycle, the IGA programme does not fully own its own coverage model. That means service owners need to track application churn, integration fragility, and exceptions as governance metrics, not just implementation details.

For practitioners

• Measure governed surface instead of feature completion Track the percentage of live applications under active identity governance, not how many connectors are available or configured.
• Classify applications by integration fragility Segment systems by stable API, unstable API, and no-API access paths so teams can forecast maintenance burden before committing to connector builds.
• Reassess custom connectors as recurring debt Assign support ownership, update cadence, and break-fix expectations to every bespoke connector so hidden maintenance work is visible in operating plans.
• Create a non-API governance path Define a controlled process for applications that must be governed through the interface when no reliable connector exists.
• Use coverage reviews to expose estate gaps Compare the application inventory against the set of systems actually reachable for certification, provisioning, and deprovisioning.

Key takeaways

• IGA coverage gaps persist because connector models depend on APIs controlled by application owners, not the identity team.
• Custom connectors change the cost profile of governance, but they do not eliminate the dependency that causes breakage and rework.
• The stronger operational metric is governed surface, the share of the live application estate that is actually under identity control.

Key terms

• Governed Surface: The share of an application estate that is actually under active identity governance, not just theoretically supported by a product. In IGA programmes, it is the more honest measure of control because it reflects what can be certified, provisioned, deprovisioned, and reviewed in practice.
• Connector Dependency: The reliance of an identity governance workflow on an external application interface staying stable enough to support automation. When the target owner changes the API or removes it, the governance control inherits the breakage and the organisation absorbs the maintenance burden.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
• Integration Contract: The implicit or explicit set of fields, calls, and behaviours that a connector expects from a target system. When that contract shifts without warning, the identity programme loses stability even if its own process and tooling remain unchanged.

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.