What breaks in IGA when connector strategy becomes runtime-driven?

Why runtime-driven connectors change the governance problem

Once connector choice moves from a fixed design decision to a runtime decision, IGA is no longer validating a single path, it is validating a decision space. The governance model has to assume that the same request can be completed through different channels with different trust boundaries, data shapes, and failure modes, so controls must be defined around the outcome, not the transport.

That matters because approval, provisioning, and deprovisioning logic can no longer be judged by whether one connector works. The real question becomes whether the governance intent survives when the system falls back from API to SCIM, from SCIM to agent execution, or from automation to a manual override.

This is why connector strategy becomes an identity governance design issue, not just an integration issue. If the mechanism changes at runtime, then entitlement state, reviewer accountability, and evidence quality all need to remain consistent across the alternate execution paths.

What stops being trustworthy when execution is dynamic?

The first thing that breaks is the assumption that approvals map cleanly to one fulfillment event. In a runtime-driven model, the request may be approved once but enacted many ways, so teams must prove that the approval still binds the exact action taken. The same challenge applies to logging, where one connector may create a clean audit event while another produces partial or delayed records.

Reconciliation is the other fragile point. If the chosen mechanism changes at runtime, the system must still reconcile requested access, granted access, and current entitlement state without gaps, duplicates, or stale records. Otherwise the governance layer will believe a control succeeded when the target system has a different reality.

Operationally, this also changes the meaning of fallback. A fallback path is safe only if it is governed with the same policy, evidence, and post-action verification as the primary path. If it is treated as a convenience path, it can become the place where exceptions, drift, and orphaned access accumulate.

How IGA design has to adapt to multiple fulfillment paths

Runtime-driven connector strategy works best when governance is expressed as policy and evidence, not as a hard dependency on one connector implementation. That means each supported path should inherit the same approval checks, the same entitlements model, and the same reconciliation expectations, even if the technical execution differs.

It also means teams should design for equivalence testing, not just connector availability. If a request can be completed through API, SCIM, agent, or manual fallback, the governance team should be able to show that each path produces comparable control evidence and comparable revocation behaviour. IGA platforms and connector strategy should be evaluated on that basis, not on whether they support the longest list of integrations.

For lifecycle-heavy environments, the same logic applies to joiner, mover, and leaver handling. A runtime-aware design has to ensure that provisioning and revocation still complete correctly even when the system chooses a different connector than the one originally planned. The practical test is whether the governance outcome is stable when execution is not.

Risk and Threat Considerations

Runtime-driven connector selection increases the chance of governance drift, because the control owner may assume one execution pattern while the system uses another. That can weaken auditability, produce inconsistent logging, and leave access in place longer than intended if one path fails silently or only partially reconciles state.

Failure mechanism: The governance policy is validated against the approved request, but the actual fulfillment path changes at runtime and no longer produces equivalent approval, logging, or revocation evidence.

Impact: Teams can end up with orphaned access, incomplete audit trails, or false confidence that an entitlement change was fully enforced, which is especially dangerous in high-volume or exception-heavy environments.

Practitioner Guidance

What to verify: Treat every runtime path as a control path. Verify that approval, logging, and reconciliation are equivalently enforced across API, SCIM, agent, and manual fallback, and that exception handling does not bypass the same review and evidence rules.

Decision rule: If the connector can change after approval, require post-execution validation that checks both the target-state change and the audit record before the workflow is considered closed.

Practitioner takeaway: The governance question is not which connector is used, it is whether every connector choice preserves the same authority, evidence, and state convergence.

Related resources from NHI Mgmt Group

• What breaks when Windows Hello for Business becomes the only authentication strategy?
• What breaks when access assignment is driven by runtime context?
• What breaks when digital identity wallets are added without a connector strategy?
• What breaks when a runtime security rule language becomes too permissive or poorly validated?