Topic starter
05/10/2026 6:49 pm
TL;DR: Enterprises averaging roughly 1,100 applications still leave 46% of their estate inadequately integrated with IGA, according to Opnova, and custom connectors only raise maintenance costs as APIs change, disappear, or break without warning. The real metric is governed surface, not connector count, because speed does not remove the architectural ceiling.
Editorial analysis by NHI Mgmt Group, based on content published by Opnova: “The Governance Ceiling: Why API Coverage Was Never the Finish Line”.
By the numbers:
- Omdia's research on enterprises averaging roughly 1,100 applications found that only 54% are adequately integrated with IGA.
- 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.
Questions worth separating out
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.
Q: Why do custom IGA connectors still leave coverage gaps?
A: Custom connectors do not remove the architectural dependency on an external API.
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.
Practitioner guidance
- 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.
Governed surface vs connector count: what IGA teams miss?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
05/10/2026 6:49 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: API coverage is not enough for IGA governance at scale