What breaks when an app has no IGA connector?

Why a Missing IGA Connector Breaks Governance

When an application has no IGA connector, it cannot be managed as part of the normal identity governance workflow. That means access certifications, role or entitlement updates, and remediation actions stop being system-driven and become exception handling. The practical effect is not just inconvenience, it is a control gap that grows as the application footprint grows.

The strongest signal is that the app is now outside the governed control plane. Without a connector, teams cannot reliably enumerate entitlements, push revocations, or prove that reviews actually covered the full population. That is why disconnected applications often drift into partial visibility and manual follow-up.

A connector also matters because governance is only useful when it can operate at scale. Manual tickets and engineering requests can patch a one-off request, but they do not create a repeatable review-and-remediate loop. Over time, that usually means stale access remains in place longer than intended, and ownership becomes harder to prove.

What Stops Working in Practice

The first thing that breaks is coverage. Access review campaigns can only certify what the governance system can see, so disconnected applications become review exceptions or remain outside the campaign entirely. That creates a split between the governed estate and the unmanaged estate, which is exactly where excess access tends to persist.

The next failure is remediation. Even if reviewers identify a risky entitlement, the removal action may still depend on an email chain, a ticket, or a manual change by application owners. That slows response, increases the chance of inconsistency, and makes it harder to demonstrate that the decision was actually enforced. For a practical reference on this control loop, see Access Reviews and Certification Guide.

Connector gaps also weaken lifecycle control. Joiner, mover, and leaver events cannot be applied cleanly when an app does not support automated provisioning or deprovisioning. The result is that access may be created by request, adjusted by hand, and removed late or not at all, which increases drift across the account population. A useful way to think about that lifecycle problem is covered in Joiner-Mover-Leaver (JML) Guide.

At the platform level, this is also an integration design problem. If your IGA program treats connectors as optional, you end up with a core governed tier and a shadow tier of apps that rely on local process discipline. The difference becomes visible when you compare a mature platform approach with ad hoc exceptions, which is why IGA Buyer's Guide places connectors at the center of platform evaluation.

How to Judge the Operational and Governance Impact

Not every missing connector has the same consequence. The real question is whether the app carries privileged access, sensitive data, or broad employee usage. If it does, the lack of connector support changes the risk profile materially because review quality, remediation speed, and auditability all degrade at once.

Disconnected apps are most dangerous when they are high-volume or business-critical. In those cases, even a small manual backlog can leave many accounts uncertified, and the backlog can outgrow the team’s ability to keep up. If the app is low-risk and low-use, the gap may be manageable temporarily, but it still needs a documented exception path and an owner who can answer for the control weakness.

The governance issue is broader than a single integration. Once an application sits outside the identity control loop, you also lose easy correlation with role design, segregation checks, and lifecycle hygiene. That is why mature programs often treat connector coverage as a governance metric, not just an implementation detail. For the underlying identity governance model, IAM and IGA Basics is the right baseline.

When an app cannot be connected, the next best question is whether the business can tolerate manual control at the required frequency. If the answer is no, the application should be escalated as a governance exception, not quietly absorbed into normal operations. That distinction matters because exceptions often linger long after the original integration project is forgotten.

Risk and Threat Considerations

A missing IGA connector creates a persistent blind spot, which can leave excessive or orphaned access in place long after it should have been removed. The risk is highest when the application holds sensitive data or administrative privileges, because unmanaged access can become an easy path for misuse, insider abuse, or lateral movement.

Failure mechanism: Entitlements cannot be inventoried, certified, or revoked through the standard control loop, so access remains dependent on manual follow-up, delayed tickets, and partial visibility.

Impact: The organisation loses reliable governance evidence, remediation slows down, and stale or excessive access can persist undetected across review cycles.

Practitioner Guidance

What to prioritise: Start with applications that have privileged access, shared accounts, production reach, or regulated data. Those are the places where a missing connector most quickly turns into a control failure rather than a mere process inconvenience.

What to verify: Check whether the app can support authoritative entitlement export, automated deprovisioning, and a repeatable ownership model. If you cannot show who approved access, who removed it, and when the removal was enforced, the control is not complete.

Common mistake: Treating manual tickets as an equivalent substitute for connector-based governance. They can support exception handling, but they rarely provide the same coverage, speed, or audit trail at scale.

Practitioner takeaway: A missing connector is not just an integration gap, it is a signal that the application may be outside the governance system that makes access review and remediation trustworthy.

Related resources from NHI Mgmt Group

• What breaks when identity platforms rely on one connector per app?
• What breaks when access sits outside the IGA connector path?
• What breaks in IGA when connector strategy becomes runtime-driven?
• What breaks when organisations use human IGA for non-human identities?