---
title: "The Governance Ceiling: Why API Coverage Was Never the Finish Line | Opnova"
description: Custom connectors don't fix coverage gaps; they make them more expensive. Here's the architecture flaw every IGA vendor is racing against.
image: https://opnova.ai/hubfs/The%20Governance%20Ceiling%20Opnova.png
---
[Skip to content](https://opnova.ai/blog/the-governance-ceiling-why-api-coverage-was-never-the-finish-line#main-content)
[Platform](https://opnova.ai/platform) [Resources](https://opnova.ai/blog) [About](https://opnova.ai/about-us)
[Contact us](https://opnova.ai/contact)
[Platform](https://opnova.ai/platform) [Resources](https://opnova.ai/blog) [About](https://opnova.ai/about-us)
[Contact us](https://opnova.ai/contact)
Blog
# The Governance Ceiling: Why API Coverage Was Never the Finish Line
Custom connectors don't fix coverage gaps; they make them more expensive. Here's the architecture flaw every IGA vendor is racing against.
Author Tiago Melo
Date 05 October, 2026
Ready to Govern Every Application?
See how Opnova can automate identity governance for your disconnected applications in weeks, not months.
[Request a Demo](https://opnova.ai/contact)
Every roadmap conversation I have about identity governance turns into a conversation about speed, onboarding time, and engineering hours per connector. How fast a team can recover when a schema change breaks something that worked last quarter.
I believe that’s the wrong conversation, because speed is just one constraint, and it’s arguably not the largest. [Omdia's research](https://darkreading.com/identity-access-management-security/identity-governance-administration-app-proliferation-app-integration-chasm) on enterprises averaging roughly 1,100 applications found that only 54% are adequately integrated with IGA. Industry data lands in the same place: enterprise IGA teams [typically govern about 20%](https://bg.linkedin.com/in/temuchin) of their application estate out of the box, on platforms they already bought and already pay to maintain.
That number does not move because a team works faster. It is a ceiling built into the architecture, and every vendor selling connectors is running into it at the same time.
## The ceiling is rising faster than anyone can chase it
The application estate is not holding still while the industry tries to catch up. The average SaaS stack per organization is back on the rise, up [11% year over year](https://www.bettercloud.com/monitor/the-2026-state-of-saas-report/), from an average of 116 apps to 164 in a single year. The estate is growing again, and every net-new application is another API surface someone has to build against, map, and eventually rebuild when that API changes.
That growth is about to pick up from a second direction. AI coding assistants are making it cheap enough to build software in-house that teams are doing it by default instead of buying another SaaS seat. None of it ships with a maintained API or anyone assigned to keep it current. It gets built because a team needed something this quarter and AI made that fast enough to justify.
A connector only works for as long as the API underneath it holds still, and no IGA platform controls that API. It belongs to whoever built the target system, and they change it, retire it, or restructure it on their own schedule. [A study of 2,224 API specifications](https://arxiv.org/pdf/2008.12808) found that of the versions introducing breaking changes, 87.3% gave no prior deprecation warning. The break just happens, and somebody finds out in production.
I see this pattern show up across every connector-based IGA platform. [SailPoint's own connectivity support policy](https://community.sailpoint.com/t5/Connector-Directory/SailPoint-Support-Policy-for-Connectivity/ta-p/79422) documents it well: the [Oracle Solaris connector](https://documentation.sailpoint.com/connectors/oracle/solaris/help/integrating_oracle_solaris/integrating_sailpoint_with_oracle_solaris.html) and the [SAP ASE connector](https://developer.sailpoint.com/discuss/t/deprecation-of-support-for-sap-ase-versions/192195) both went away because Oracle and SAP made changes, not because SailPoint chose to. Swap in any platform on the market and the story repeats, because the constraint is architectural.
## Custom connectors don't escape the ceiling, they just move the cost
The standard answer when a target has no pre-built connector is to build one. This work is usually routed to Professional Services or an implementation partner because it takes real expertise in both the identity model and the target system.
But none of that work touches the underlying dependency. A custom connector still depends on an API someone else controls, and it still breaks when that API changes without warning. The only thing that changes is who absorbs the maintenance from here on. Instead of a vendor's engineering team keeping a connector current across an entire customer base, it's one internal team keeping it current for a single instance, usually with less scale, less institutional urgency, and a longer wait the next time it breaks.
That makes custom connectors the most expensive version of the chase, not an exit from it. Every hour spent building one is spent chasing the same moving API at a higher cost per application, and it does nothing for the applications that never had an API to build against in the first place. Teams that treat " we'll just build our own connector" as the fix for a coverage gap haven't found an exception to the ceiling. They've just found a more expensive way to run into it.
## The industry already knows this, and its fix doesn't fix it
Nobody serious is defending the connector model anymore. They're just trying to make it faster.
A [Rabobank team ran a live experiment](https://www.kuppingercole.com/watch/ai-acceleration-of-connectors-eic26) on this exact problem. They managed to cut a standard connector build, historically around six months of work, down to roughly six hours using AI to accelerate development. Their own conclusion was blunt: AI accelerates a skilled practitioner, but it doesn't replace the dependency, and you still need a strict connector standard to trust the output.
Even the most optimistic version of the connector-acceleration story is still a connector story. It still needs an API. It still breaks when that API changes. It just breaks faster and gets rebuilt faster. You've compressed the cycle time on a ceiling, not removed it.
## Two camps, only one of which escapes the ceiling
The industry is splitting into two responses to the same diagnosis, and it's worth being precise about which camp actually solves the problem.
Camp one is acceleration: faster connector development, AI-assisted schema mapping, more professional services hours compressed into less time. This is where most of the market is spending its R&D budget right now, and it helps. It does not change the fact that every connector still depends on an API that someone else controls and can change without warning.
Camp two skips the dependency: governance that operates the application the way a person would, through the interface, with no API required at all. If it has a screen, it can be governed. That isn't a faster version of the connector model. It's a different model that never hits the same ceiling, because the ceiling was never about engineering speed to begin with. It was about depending on something you don't control.
## Measure the surface, not the checklist
Most IGA maturity conversations still score capability. Does the platform have the feature? Is the connector built? Is the workflow configured? But the right scoreboard is governed surface: what percentage of the actual estate is under control right now, not what percentage of purchased capability is technically switched on.
Until that measurement changes, the 46% gap Omdia found will keep showing up in every audit, no matter how many connectors get built this year, and no matter how fast anyone gets at building them.
[Home](https://opnova.ai/)
- [Problem](https://opnova.ai/#problem)
- [Transformation](https://opnova.ai/#mission)
- [Solution](https://opnova.ai/#solution)
[Platform](https://opnova.ai/platform)
- [Technology](https://opnova.ai/platform#core-technology)
- [Use Cases](https://opnova.ai/platform#use-cases)
- [Deployment](https://opnova.ai/platform#deployment)
- [AI Safety](https://opnova.ai/platform#security)
[Resources](https://opnova.ai/blog)
- [All](https://opnova.ai/blog)
- [Blog](https://opnova.ai/blog#blog)
- [Documents](https://opnova.ai/blog#documents)
- [Videos](https://opnova.ai/blog#videos)
[About](https://opnova.ai/about-us)
- [Mission](https://opnova.ai/about-us#mission)
- [Team](https://opnova.ai/about-us#team)
- [Advisors & Investors](https://opnova.ai/about-us#advisors)
© OPNOVA All Rights Reserved | [Privacy Policy](https://opnova.ai/privacy-policy) | [Terms of Service](https://opnova.ai/terms-of-service) | [Status](https://status.opnova.io/)
AI startup program Google Cloud
NVIDIA DGX Cloud Innovation Lab
```json
{
"@context" : "https://schema.org",
"@type" : "BlogPosting",
"author" : {
"@type" : "Person",
"name" : "Tiago Melo",
"url" : "https://opnova.ai/blog/author/tiago-melo"
},
"dateModified" : "2026-10-05T07:00:00.150Z",
"datePublished" : "2026-10-05T07:00:00.000Z",
"headline" : "The Governance Ceiling: Why API Coverage Was Never the Finish Line",
"image" : [ "https://opnova.ai/hubfs/The%20Governance%20Ceiling%20Opnova.png" ],
"mainEntityOfPage" : {
"@id" : "https://opnova.ai/blog/the-governance-ceiling-why-api-coverage-was-never-the-finish-line",
"@type" : "WebPage"
},
"publisher" : {
"@type" : "Organization",
"logo" : {
"@type" : "ImageObject",
"url" : "https://opnova.ai/hubfs/logo%203.png"
},
"name" : "Opnova"
}
}
```