Customisation turns identity governance into a maintenance problem because each bespoke change adds testing, support, and upgrade risk. A configuration-first model keeps the programme closer to standard control logic, which is easier to sustain across hybrid environments. The practical advantage is lower operational drag and fewer fragile dependencies that slow governance work.
Why custom IGA creates a support treadmill instead of a control platform
IGA becomes fragile when customisation shifts the programme away from repeatable product behaviour and into a local codebase of exceptions. Every bespoke rule, connector tweak, workflow branch, or reporting workaround has to be tested, retested, and carried through each platform upgrade. The result is a system that can still function, but only while a small set of people preserve the hidden assumptions behind it.
That fragility is not just technical debt. It changes the operating model: governance teams stop relying on standard control logic and start relying on memory, manual fixes, and one-off knowledge to keep access processes alive. IGA platform evaluation matters here because buyers need to test whether the product can meet the use case with configuration, not whether the implementation team can absorb unlimited custom work.
Hybrid environments make this worse because the custom layer usually has to span different apps, identity sources, entitlement models, and review cycles. The more special cases you build in, the harder it becomes to prove that the same governance rule is being enforced consistently everywhere. That is why programmes often feel stable in a single release window, then brittle as soon as the next integration, patch, or audit cycle arrives.
Why bespoke logic drives cost higher over time
Customisation increases cost in three ways: development effort, regression testing, and long-term support. A small deviation from the standard model may look cheap at design time, but it creates recurring spend whenever roles change, access models evolve, or the vendor changes product behaviour. IAM and IGA basics are useful as a reference point because the more your programme departs from the core lifecycle and governance pattern, the more you pay to preserve that departure.
Cost also rises because custom work tends to multiply across the programme. A workflow tweak leads to a new exception path, which leads to a new test pack, which leads to a new support note, which leads to a new dependency during upgrades. What looked like a single enhancement becomes a maintenance surface area. Role mining and role design helps reduce that pressure by making the role model itself easier to govern, so fewer bespoke exceptions are needed to make access decisions work.
There is also a hidden cost in operational confidence. When teams know the platform is heavily customised, they are more likely to delay upgrades, avoid standard features, or keep manual workarounds alive because they fear breaking a fragile dependency. That slows the programme further and makes each release more expensive than the last.
What a configuration-first IGA model changes in practice
A configuration-first model keeps the governance programme closer to the product’s native control logic, which makes the system easier to understand, change, and audit. Instead of encoding every business nuance in bespoke logic, teams use standard lifecycle, review, role, and segregation patterns wherever possible. Joiner-Mover-Leaver processes are a good example of where standardisation pays off, because onboarding, change, and offboarding should be repeatable rather than hand-built for every exception.
This approach also improves resilience. Standardised control logic is easier to test against new applications, easier to explain to auditors, and easier to recover when a connector or workflow fails. It reduces the number of places where governance depends on a single person’s knowledge of an old custom script or a brittle approval branch. Access reviews and certification benefit from that discipline because the review process stays focused on evidence and decision quality, not on whether the underlying workflow is still behaving the way a prior team intended.
The practical test is simple: if a new business need can be met by configuration, use configuration; if it requires customisation, treat it as an exception that carries lifecycle cost, upgrade risk, and support ownership. That decision rule keeps the programme closer to a sustainable control platform and farther from a fragile software project.
Risk and Threat Considerations
Customised IGA environments create operational exposure because they are harder to patch, harder to verify, and easier to misalign with the current access model. The more bespoke the implementation, the more likely a control gap appears during upgrades, connector changes, or role redesign. Over time, that can leave outdated permissions, broken recertification paths, or incomplete revocation behaviour in place.
Failure mechanism: bespoke workflows, scripts, and connectors drift from the vendor-supported control path, so upgrades or schema changes can silently break provisioning, reviews, or reporting logic.
Impact: governance exceptions become harder to detect, access decisions become less reliable, and the programme accumulates operational and audit risk that is expensive to unwind.
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, CIS Controls v8 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Custom IGA must manage lifecycle and change risk around credentials and access flows. |
| AC-6 — Least Privilege | Excess customisation often obscures entitlement boundaries and makes privilege governance harder to sustain. | |
| Recommendation — Standardize credential and lifecycle handling so custom governance logic does not weaken access control. Use least-privilege principles to keep role and entitlement decisions aligned with standard control logic. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | IGA customisation directly affects how access rules are governed and enforced across systems. |
| Recommendation — Keep access-control design as standard as possible and document exceptions for periodic review. | ||
| CIS Controls v8 | CIS-5 — Account Management | IGA programmes operationalize account lifecycle controls that become brittle when over-customised. |
| Recommendation — Automate account lifecycle controls with the least custom logic needed to sustain them. | ||
| OWASP ASVS | V8 — Authorization | Custom governance logic frequently distorts authorization behavior and increases regression risk. |
| Recommendation — Verify authorization paths against a stable, testable model instead of embedding ad hoc exceptions. | ||
Practitioner Guidance
What to prioritise: separate true business exceptions from implementation habits. If a requirement exists only because the current custom build created it, challenge whether it should survive the next release.
What to verify: every custom rule, connector, and approval path should have an owner, a test case, and a clear reason it cannot be handled by standard configuration. If any of those are missing, treat the item as a fragility point rather than a feature.
Common mistake: teams often measure success by whether the customisation made the first deployment work, not by whether the control will still be maintainable after the second or third upgrade. That is where cost and fragility usually surface.
Practitioner takeaway: the strongest IGA programmes minimise bespoke logic because sustainment, not implementation, determines whether governance stays effective at scale.