Security teams should treat configuration as the preferred path when the platform supports it through built-in workflows, connectors, and policy controls. Customization should be reserved for true gaps, because code-heavy changes increase maintenance, slow upgrades, and make controls harder to govern. The practical test is whether the requirement can be met through native capabilities, templates, or APIs without creating long-term technical debt.
Why configuration should be the default in IGA modernisation
Modern IGA platforms are designed to absorb common identity governance patterns through declarative settings, policy objects, workflow builders, connectors, and templates. When a requirement can be expressed that way, teams get a cleaner upgrade path, clearer auditability, and less operational drift. The practical distinction is not whether something is “technical”, but whether it changes the product into something the vendor never intended to maintain.
Configuration is usually the right first move because it preserves the platform’s support model. That matters in IGA, where lifecycle events, approvals, recertification, and entitlement rules tend to evolve, and teams need changes to remain understandable to auditors and support teams. Using a platform’s native controls also helps avoid brittle logic that only one engineer understands.
For teams assessing whether a change belongs in configuration, the useful questions are: can the outcome be achieved through built-in policy controls, can it survive an upgrade without rework, and can a control owner explain it without reading custom code? If the answer is yes, the change belongs in the configuration lane.
When customization is justified and what it usually costs
Customization becomes justified when the business requirement is genuinely outside the platform’s supported model, such as a unique approval pattern, an unusual downstream system constraint, or a regulatory exception that the native workflow cannot represent. Even then, the decision should be deliberate, because custom code, bespoke connectors, and patched extensions create a maintenance burden that follows every release cycle.
The hidden cost is not only implementation time. Customization can weaken governance by scattering logic across scripts, middleware, and developer-owned components that are harder to review, test, and recertify. That makes change control slower and increases the chance that a future platform upgrade, connector update, or policy revision breaks an assumption that was never documented well enough.
A useful rule is to prefer customization only when the requirement is stable, materially important, and impossible to satisfy through documented native options. If the need is temporary, edge-case, or driven by local preference rather than enterprise necessity, it is usually a candidate for process change instead of product change.
How to draw the line in practice
Teams should separate requirements into three buckets: native configuration, supported extension, and true custom build. Native configuration should cover standard governance controls, supported extension should cover narrowly bounded gaps, and custom build should be the exception that requires explicit ownership, testing, and lifecycle planning. That separation helps prevent “one small customization” from becoming the default delivery model.
What to verify: Before approving customization, confirm whether the platform already offers the capability through policy, workflow, connector, or template options, and whether the vendor supports the proposed method across upgrades. If the control can be expressed without code, keep it in configuration and document the rule clearly.
What practitioners underestimate: The real risk is not just technical debt, but governance debt. Once a team depends on custom logic to decide who gets access, who is reviewed, or how exceptions are handled, the organisation inherits extra testing, weaker traceability, and a larger failure surface when the identity programme changes.
Practitioner takeaway: Treat configuration as the control-preserving path and customization as the exception path. If a requirement can be delivered natively, keep it there; if it cannot, make the customisation small, well-owned, and easy to retire.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | IGA modernisation hinges on keeping controls in supported configuration. |
| Recommendation — Use secure configuration to keep IGA changes declarative, reviewable, and upgrade-friendly. | ||
| NIST CSF 2.0 | PR.IP — Protective Technology and Processes | The question is about preserving maintainable security processes in platform change. |
| GV.OC — Organisational Context | Config vs custom should follow enterprise control ownership and supportability expectations. | |
| GV.RM — Risk Management Strategy | Customization increases lifecycle and upgrade risk, so the decision needs explicit risk treatment. | |
| Recommendation — Standardise IGA changes through documented protective processes rather than bespoke logic. Define which IGA requirements must remain within vendor-supported configuration. Require a risk review before approving custom IGA extensions. | ||
Related resources from NHI Mgmt Group
- How should security teams evaluate a certificate authority when root ubiquity is needed across browsers, devices, and platforms?
- How should SMBs implement modern IGA without overloading small security teams?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?
