IGA Is Going Continuous. Connectivity Decides Whether It Delivers.

Continuous governance only reaches the apps your IGA can read and write. Everywhere else, an event becomes a ticket.

SailPoint and Okta are now pitching the same future: governance that runs continuously instead of in periodic campaigns. SailPoint positions its Human Fabric as a move “from a static, reactive compliance exercise into a continuous, real-time layer of protection”. Okta has announced drift detection it frames as “shifting from intermittent compliance audits to continuous containment,” with early access planned by Q4. The plumbing is ready: Shared Signals, CAEP and RISC went final in September 2025; SCIM’s event standard, RFC 9967, followed in May 2026.

The direction is right. The plan has the same hole IGA programs have always had: the applications that never got connected.

Event-driven isn’t new. Continuous-as-default is.

Start with what the launch posts leave out. Oracle Identity Manager — part of an Oracle identity stack I built — documented certifications triggered by events such as a manager change by 2015, and SailPoint IdentityIQ ships certification events for manager transfers and attribute changes today.

What’s shifting is the default: from batch-as-default to continuous-as-default, with final signal standards behind it and vendors announcing automated remediation on top. That’s IGA’s natural progression, and the promised payoff is worth chasing — shorter review cycles, faster remediation, and less of the certification fatigue that turns reviewers into rubber stamps.

A decade of event-capable IGA hasn’t closed the coverage gap. The trigger was never the bottleneck. The connector was.

Events only fire on what the IGA can see

The product documentation makes the dependency explicit. SailPoint’s native-change events are “detected on aggregation by comparing stored information with newly read information.” No aggregation, no native-change event. The emerging standards assume the same: the OpenID Foundation’s draft IPSIE profiles put lifecycle obligations on the application, not only on the identity service. SailPoint’s connectivity blog says it outright: “If an application can’t be connected, it can’t be governed”.

A note on terms: “Continuous Identity” is mostly a runtime-access label, used by CrowdStrike for the SGNL capability it agreed to acquire. Continuous governance shares the same prerequisite: the application has to participate.

The gap is not marginal. According to ESG/Omdia research (2025), 54% of enterprise applications are adequately integrated with IGA. Nearly half are not adequately integrated. Ownership and culture matter too, but connectivity is the precondition: you can’t fix ownership of an app your IGA can’t see.

54% of enterprise applications are adequately integrated with IGA; nearly half are not. Source: ESG/Omdia research (2025), via Dark Reading, 14 Nov 2025.

The event-to-ticket conversion

Here’s the part no one is planning for. When an event fires against an app the IGA can’t write to, it doesn’t disappear. It converts. Microsoft documents a custom-extensibility pattern that turns an approved access assignment into a ServiceNow ticket for manual provisioning. One Identity’s integration creates a ServiceNow ticket for requests “that require manual fulfillment”. Both are sensible fallbacks. Where the only path is a flat file, the event can’t travel at all: Okta’s CSV entitlement import (Early Access) for apps that aren’t fully lifecycle-integrated supports full imports only. A flat file is batch by construction.

I call this the event-to-ticket conversion, and continuous governance speeds it up.

Diagram titled The event-to-ticket conversion. IGA events (mover, leaver, event-triggered review decision) feed three lanes. Lane A, connected app: provision out, aggregation back, loop closes. Lane B, disconnected app: a ServiceNow ticket or a full-only CSV import (Okta, Early Access), leading to a manual queue. Lane C, StackBob.ai (vendor approach): SCIM from the IGA, Agent Bob / NCAP executes joiner-mover-leaver changes in the app, reconciliation back to the IGA.

Take an illustrative mover (hypothetical numbers, not survey data). The move touches twelve applications; five are disconnected. In the periodic model, those five surfaced as one cleanup sprint. In the continuous model, every mover, every leaver and every revoke decision from an event-triggered review on those five apps becomes its own ticket. Raise the event rate, keep the fallback, and the ticket rate rises with it. That’s architecture logic, not a measured statistic.

This doesn’t mean every app needs the same depth; IPSIE itself tiers lifecycle obligations from deprovisioning up to roles. It does mean every app in scope for review and lifecycle needs both directions connected — changes out, data back. Connected isn’t automatically continuous; Entra’s Lifecycle Workflows, once scheduled, evaluate every three hours by default (the interval is configurable). Disconnected, though, is guaranteed not to be.

Don’t make the IGA faster. Make more apps eligible.

The market agrees integration has to speed up. Okta has announced AI-delivered integrations in “as little as 48 hours,” down from two to three months, for new SaaS apps with an OpenAPI specification; customer requests open in November 2026. SailPoint has rolled out a Connectivity Agent to US tenants for SaaS apps with well-documented REST APIs. Speed is converging. The open question is what an app needs before it can connect at all: a documented REST API, an OpenAPI specification, or neither.

That’s the lane we built StackBob.ai for. StackBob.ai extends your Identity Governance to applications that lack SCIM, APIs, or connectors, reducing manual provisioning and compliance risks. It operates alongside existing IGA and IdP platforms without replacement, migration, or re-architecture. Your IGA sends SCIM operations as it does today. Agent Bob, running on No-Code Autonomous Provisioning (NCAP™), carries out joiner–mover–leaver changes (users, groups, entitlements) inside the target application, then reconciles the result back to the IGA. The app that used to get a ticket becomes one your platform can provision and aggregate, which is the precondition its event machinery runs on. Separately, we surface shadow applications through discovery against the primary IdP and a browser extension. Our target is 90% application integration with full lifecycle management — a StackBob target, not an industry benchmark.

One boundary worth stating plainly: StackBob doesn’t make your IGA faster than it is. It acts on the events your platform already dispatches, so it runs no faster than your platform does. What changes is how many apps those events can reach.

The stake

Continuous governance is the right destination and the natural next step for IGA. Continuous isn’t a review cadence, though. It’s a coverage number. Before you fund the next wave of event-driven reviews, count how many in-scope apps can actually receive the event, and fix that number first. Over the next 18 months, the programs that deliver on continuous will be the ones that made more apps eligible, not the ones that fired events faster.