Fix connectivity first unless the platform is truly end-of-life or incompatible with the architecture. Replacing the tool does not remove application constraints such as missing APIs, SCIM, or connector support, so the same coverage ceiling often returns in a new product wrapper.
Why connectivity is usually the first constraint in IGA decisions
Identity governance platforms rarely fail because the workflow engine itself is absent. They fail when the platform cannot reliably reach authoritative sources, target applications, directories, and downstream systems. If those connections are weak, incomplete, or brittle, the business still ends up with partial visibility, manual overrides, and access decisions that cannot be executed consistently.
The practical question is not whether the tool is modern enough, but whether it can actually move data and entitlement actions across the application estate. In a mixed environment, missing APIs, SCIM support, connector gaps, and inconsistent target-system behaviour cap what any replacement can deliver. An IGA Buyer’s Guide is useful here because it treats connector coverage, lifecycle workflows, and proof-of-concept validation as first-order selection criteria.
When connectivity is the limiting factor, replacing the platform first often just re-creates the same ceiling in a different interface. The better sequence is to stabilise the integration paths that drive joiner, mover, leaver actions, access reviews, and entitlement reconciliation, then judge whether the platform still cannot meet the operating model.
What changes when the problem is the platform itself
There are cases where replacement should outrank repair. If the system is truly end-of-life, unsupported, architecturally incompatible, or unable to integrate with the identity sources and business applications that matter, patching connectivity may only buy time. In that case, the issue is not just one connector, but the underlying product limits, data model, or deployment pattern.
A sound decision also depends on whether the current platform can support the governance tasks the organisation now expects. That includes access certifications, role and entitlement management, SoD analysis, and visibility into machine or non-human accounts where they are in scope. The IAM and IGA Basics guide is a good reference for separating core identity governance functions from the plumbing needed to execute them.
In other words, fix connectivity first when the platform is fundamentally sound but under-connected. Replace it first when the architecture no longer supports the governance outcomes you need, even after reasonable integration work. That distinction matters because tool change is expensive and disruptive, while integration repair is usually the faster path to measurable coverage gains.
How to decide without turning the debate into a platform refresh project
The most useful decision test is operational, not vendor-led. Ask whether the current platform can still complete the control loop: discover, request, approve, provision, certify, recertify, and revoke across the systems that matter most. If the answer is mostly yes, the immediate work is connectivity, not replacement.
- If the platform can support the process but not reach the target systems, prioritise connector work, API enablement, and reconciliation fixes.
- If the platform cannot represent the entitlement model, lifecycle states, or governance process you need, treat replacement as a structural programme.
- If both are true, reduce scope first, prove the highest-value integrations, then reassess the platform gap against the real operating model.
The most common mistake is to treat a product swap as a substitute for application readiness. Joiner-Mover-Leaver (JML) Guide is a useful reminder that lifecycle automation only works when the upstream authoritative sources and downstream application hooks are both dependable. Replacing the IGA suite does not create those hooks by itself.
Risk and Threat Considerations
Delaying connectivity fixes can leave organisations with a false sense of control, because the platform may look operational while approvals and revocations still fail in practice. That creates standing access, stale entitlements, and incomplete certification coverage, especially in estates with many disconnected applications or bespoke integrations.
Failure mechanism: weak or missing connectors prevent the governance system from seeing, provisioning, or removing access consistently, so access decisions diverge from actual system state.
Impact: the organisation accumulates orphaned access, slower deprovisioning, audit gaps, and higher exposure from privileges that were approved on paper but never enforced in the target system.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | IGA platform and connector coverage are identity governance controls in cloud environments. |
| Recommendation — Validate identity lifecycle, provisioning, and access review connectivity across cloud applications. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | IGA connectivity determines whether accounts and entitlements can be provisioned and removed correctly. |
| AC-6 — Least Privilege | Poor connectivity can leave excessive access in place, defeating privilege minimisation. | |
| IA-5 — Authenticator Management | IGA workflows depend on managing credentials and tokens that enable system connectivity. | |
| Recommendation — Ensure account lifecycle actions are executed consistently across connected systems. Reduce standing access by enforcing least privilege through timely entitlement removal. Control credential and token lifecycle for the integrations that power governance actions. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Access control governance depends on reliable enforcement across identity and application connections. |
| Recommendation — Map and enforce access control requirements across all governed applications. | ||
Practitioner Guidance
What to prioritise: Start with the applications that carry the highest privilege, the highest user volume, or the most regulatory exposure. Those systems usually give the fastest proof that connectivity repair is improving real governance outcomes, not just dashboard completeness.
Decision rule: If the platform can still execute the identity governance process but fails at integration points, repair connectivity first. If the platform cannot support the governance model even with reasonable integration work, escalate to replacement planning.
What to verify: Validate whether the platform can synchronise authoritative identity data, provision and deprovision entitlements, and complete certification actions without manual exceptions becoming the normal path.
Practitioner takeaway: A platform change is only justified when the product itself is the constraint; if connectivity is the blocker, fix the integration layer first and measure whether coverage, timeliness, and revocation accuracy improve.