KuppingerCole 2026 Revealed the IGA Connector Gap No Vendor Has Closed

Eyebrow: Industry Analysis

KuppingerCole published its 2026 IGA Leadership Compass in May. It evaluated 31 vendors.
It named Overall Leaders. It ranked platforms on product depth, innovation, and market
presence. It is the most-referenced independent evaluation in the identity governance
market, and every serious IGA vendor spends months preparing for it.
What it also did – quietly, in the challenges section of vendor after vendor – was document
the same structural gap. Not a gap belonging to one platform or one architecture. A gap
that belongs to the category.

The Analyst Named the IGA Connector Gap. Every Platform Has It.

The 2026 report is direct about what matters in IGA. “Connector depth and reconciliation
capabilities,” the analyst writes, are critical for managing complex entitlement models in
line-of-business applications. That criterion appears in the required capabilities section. It is
one of the things every platform is measured against.

Then the individual vendor profiles arrive, and a pattern forms.

One Overall Leader is noted to rely on RPA-based connectors to extend coverage to
systems outside its native library. Another has legacy connector gaps listed as a formal
challenge. A third – a platform recognized for its broad SaaS connectivity – acknowledges
that disconnected applications can only be included in access reviews through ticketed and
workflow-based approaches. In analyst language, that phrase means someone is handling it
by hand.

This is not a coincidence of evaluation methodology or a sign that any single platform is
falling short. It reflects something structural about how IGA was built. The connector
ecosystems that exist today were designed around the applications that were willing to
cooperate: modern SaaS platforms with documented APIs, directories with standard
protocols, HR systems built to integrate. Those applications are well-governed. The problem
is they are not where the risk lives

Risk Concentrates in Disconnected Applications Your IGA Platform Cannot Reach

Ask any identity team which applications they worry about most, and the answers are
consistent. The mainframe environment that handles financial settlements and predates the
current compliance regime by two decades. The clinical platform that runs on a terminal
interface and has never had an API, not because no one wanted one but because the vendor
stopped shipping new versions before SCIM existed. The line-of-business tool a single team
built internally and now controls access to a sensitive data environment that auditors have
been circling for years.

These are not marginal applications. They are the ones that concentrate privileged access,
accumulate orphaned accounts, and resist the governance motions that work cleanly
everywhere else. And the same characteristics that make them hard to connect – age,
custom architecture, no modern interface – are the characteristics that let access drift and
stay drifted.

The standard responses to a disconnected application each run out of road in the same
place. Waiting for an API assumes a vendor who is still actively developing a product that, in
many cases, shipped before the current SCIM specification existed. Building a custom
connector works until the application changes, which it will, and until the IAM team that built
it has moved on, which they will. Managing the application by hand – spreadsheets, email
approvals, quarterly certification campaigns where managers are approving access to
systems they do not fully understand – is not governance. It is the appearance of
governance, maintained at significant operational cost, and it is the first thing a
sophisticated auditor finds.

The 2026 KuppingerCole report documents this reality without framing it as failure. It
frames it accurately: as a gap that has persisted across the category, and that RPA has not
closed.

Why RPA-Based IGA Connectors Keep Appearing  – and Why Identity Governance Connectivity Breaks Down

The 2026 Leadership Compass mentions RPA in the context of connectivity for at least
three vendors, including one Overall Leader whose entire connector architecture is built on
it. KuppingerCole notes in a separate profile that “bot or RPA certifications remain limited.”
This is not a condemnation of the intent. It is an accurate description of what happens when
a task automation technology gets applied to an identity governance problem.

RPA is built to automate repetitive tasks through a scripted sequence of interface
interactions. For a specific application, on a stable interface, with a team available to
maintain the script, it works. The governance problem arrives when the interface changes –
after an application update, a UI refresh, a vendor patch – and the script breaks.
Provisioning queues silently. The Leaver event that should have triggered deprovisioning
across a set of legacy applications does not. The audit trail shows a gap that may not be
discovered until the next certification cycle, or later.

Scaled across twenty or forty disconnected applications, each with its own update cadence
and interface quirks, the operational cost of keeping RPA connectors current becomes the
work itself. The IAM team that was supposed to be expanding governance coverage is
instead doing connector maintenance. The gap that was supposed to be closing is staying
roughly the same size.

That is the context in which the 2026 report’s language should be read. When the analyst
describes ticketed workarounds and RPA-based coverage extensions as challenges, it is
describing a category that has not yet found a durable answer to its hardest connectivity
problem.

How READI Extends IGA Provisioning Automation to Legacy and Disconnected Applications

READI is not an IGA platform. It is the connectivity layer that allows IGA platforms to govern
the applications they were not designed to reach.

The Smart Connector uses a combination of a language model and a computer vision
engine to operate applications through the interface they already have – the screen. PlainEnglish instructions describe what a provisioning action should do. The language model
translates those instructions into structured intent. The computer vision engine reads the
actual interface at runtime to identify the elements it needs to interact with. The result is a
connector that works across web applications, Win32 desktop applications, and terminal
systems without requiring an API, without requiring scripting, and without breaking when the
application interface changes. When a UI update shifts a button or relabels a field, the
connector self-heals.

The bidirectional architecture matters as much as the coverage. READI aggregates identity
data back from disconnected applications into the IGA platform, not just provisioning out to
them. That means the governance platform has visibility into what access exists, not just the
ability to act on it. The Leaver event that previously generated a ServiceNow ticket and a
manual workflow becomes an automated, auditable, policy-enforced deprovisioning action –
including across the mainframe terminal system, the legacy clinical platform, and every
other application that was previously outside the program’s reach.

The IGA platform remains the system of record and the policy authority. READI extends its
execution reach to the applications that were always in scope from a risk perspective, but
never in scope from a connectivity one.

What the KuppingerCole Challenges Sections Tell Every Identity Governance Team

If your organization is evaluating IGA platforms using the 2026 KuppingerCole Leadership
Compass – which is a reasonable place to start – read the challenges sections as carefully
as the strengths. The leaders are well-documented and genuinely capable. The gaps are
also well-documented and genuinely structural.

The question to ask your platform vendor at any stage of evaluation or renewal is not
whether their connector library covers your SaaS estate. It almost certainly does. The
question is what governance looks like for the thirty or forty applications that are not on that
list – the terminal systems, the legacy line-of-business platforms, the applications that have
been deferred from the IGA program for long enough that they have stopped being
discussed. Those applications do not get smaller as a governance problem the longer they
wait. They get larger.

READI exists to close that gap, alongside the IGA platform you have already invested in or
are in the process of selecting. The 2026 report documented the problem clearly. The
answer is already available.

READI is an identity automation platform that extends IGA connectivity to every
application in your enterprise – including the ones your IGA platform cannot reach
natively. To see how READI works alongside your existing IGA investment, request a
demo at readibots.com.