A common mistake is overcustomising IGA for every application and process. Heavy custom code slows deployment, raises the chance of coding errors, and makes future maintenance harder when business requirements change. Standards based connectivity using protocols such as REST, SCIM, and SOAP is usually easier to scale and maintain across a broad application estate.
Why custom IGA integrations usually become a maintenance problem
Customising identity governance and administration too deeply for each application usually looks efficient at first, but it creates a brittle integration layer. The more logic you embed in bespoke connectors, the harder it becomes to test, upgrade, and reuse the same control pattern across the estate. Standard interfaces such as REST, SCIM, and SOAP are usually the better default because they reduce variance and keep governance logic more portable.
That portability matters because IGA is not just about making one connector work, it is about sustaining provisioning, deprovisioning, and access review at scale. When each application needs its own exceptions, the integration stops being an enablement layer and starts becoming a software product that must be maintained, patched, and understood by future teams.
It also changes the operating model. If your team has to remember application-specific rules every time a joiner, mover, or leaver event occurs, the process becomes dependent on tribal knowledge instead of repeatable governance. That is where delays, inconsistent access removal, and hidden entitlement drift start to appear.
For broad estates, the question is not whether custom code can be made to work once, but whether it remains supportable when business rules, target systems, and control requirements change. The answer is usually no unless the custom layer is tightly bounded and treated as an exception, not as the design norm.
Where organisations overestimate what “integration” should do
A common mistake is trying to make the IGA platform understand every workflow nuance inside every application. In practice, IGA should orchestrate identity events, approvals, and entitlement changes, while the application exposes a stable interface for the actual account or access action. When teams push business process logic into the connector itself, they blur the boundary between governance and application behaviour.
That blur creates three recurring problems. First, the integration becomes harder to validate because each custom rule needs its own test path. Second, small application changes can break provisioning or certification logic unexpectedly. Third, the IGA team ends up owning code that really belongs to the application or platform team, which makes support and incident response slower.
A better approach is to standardise the control point where possible, then isolate true exceptions. If an application cannot support normal lifecycle operations, the organisation should document that gap explicitly and decide whether to wrap it, replace it, or accept the residual risk. Treating every exception as a permanent custom development task usually creates long-term technical debt.
Standards-based connectivity also improves control consistency. A connector pattern that works for many systems makes it easier to apply the same provisioning, review, and deprovisioning expectations across the estate, rather than re-litigating the workflow every time a new application is onboarded.
What a maintainable IGA workflow design looks like
Maintainable IGA is usually built around a small set of repeatable actions: create access, update access, remove access, attest access, and record evidence. The workflow should be simple enough that a practitioner can explain what happens when an identity changes without reading custom code. The more the process depends on opaque branching logic, the more likely it is to fail quietly.
That design choice also affects change management. When a new application arrives, the implementation should ask first whether the system can speak a standard protocol, whether the entitlement model is clear, and whether lifecycle events can be handled without special-case scripting. If the answer is no, the organisation should be deliberate about the exception, not optimistic about the code.
Well-designed workflows also make review and remediation easier. When access approval, provisioning, and revocation are separated into clear steps, it is much easier to see where delays occur, where approvals are bypassed, and where revoked access may still persist. Those failures are harder to spot when the connector bundles too much logic into one opaque transaction.
For teams managing a large application estate, the practical goal is not “no customisation at all.” The goal is to minimise unique logic, keep the integration contract stable, and reserve heavy custom work for cases where there is a genuine functional gap that cannot be covered by a standard interface.
Risk and Threat Considerations
Overcustomised IGA integrations increase exposure because failure is no longer limited to one application, it can propagate through provisioning, review, and deprovisioning flows. A brittle connector can leave access lingering after a role change or termination, or it can misapply entitlements in ways that are hard to detect quickly.
Failure mechanism: Custom workflow logic accumulates edge cases, then breaks when the target application changes, the schema shifts, or an exception path is triggered that was not covered in testing.
Impact: The organisation can end up with stale access, delayed offboarding, inconsistent certification results, and a larger support burden when governance actions do not complete as expected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service Organizations) | Covers service and system-to-system authentication behind connector-driven IGA workflows. |
| AC-2 — Account Management | Applies to provisioning, deprovisioning, and lifecycle control in IGA workflows. | |
| Recommendation — Use IA-9 to standardise service authentication for IGA connectors and reduce bespoke trust logic. Use AC-2 to govern account lifecycle changes through repeatable, auditable workflows. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Supports consistent access decisions and least-privilege governance across integrated applications. |
| A.8.9 — Configuration management | Relevant because custom integrations create configuration drift and maintenance burden. | |
| Recommendation — Apply A.5.15 to keep access decisions standardised across custom and standard integrations. Use A.8.9 to control connector changes and prevent workflow drift. | ||
| CIS Controls v8 | CIS-5 — Account Management | Directly supports lifecycle handling for identities and access in IGA implementations. |
| Recommendation — Apply CIS-5 to reduce manual exceptions in identity lifecycle workflows. | ||
Practitioner Guidance
What to prioritise: Start by identifying which integrations are truly unique and which are only custom because no one has standardised the target pattern yet. That distinction usually reveals where maintenance effort can be removed fastest without changing the business outcome.
What to verify: Confirm that each workflow has a clear owner, a bounded failure mode, and a straightforward rollback or remediation path. If the team cannot explain how to revoke access or re-run provisioning after a connector failure, the design is too fragile.
Common mistake: Treating every application exception as a permanent development requirement. In many environments, that simply hides weak application onboarding discipline and shifts long-term cost into the IGA layer.
Practitioner takeaway: The best IGA integration is usually the one that does the least custom work while still preserving accurate lifecycle control, because simplicity is what keeps governance durable when systems and business rules change.
