An identity governance model that uses built-in settings, workflows, and policy templates instead of custom code to deliver control outcomes. The operational advantage is that governance logic stays closer to the product surface, which makes upgrades, evidence generation, and long-term ownership easier to sustain.
How Configuration-Led IGA Works
Configuration-led IGA uses the governance capabilities the product already exposes, such as policy templates, workflows, role models, and approval paths, rather than custom scripts or brittle point integrations. That keeps governance outcomes anchored in supported product behaviour instead of maintaining a parallel code base.
The practical distinction is that the governance logic lives in configuration objects, not in bespoke extensions. For teams, that usually means the control design is easier to understand, easier to change safely, and less likely to break when the underlying platform is upgraded.
Why It Matters for Identity Governance
In IGA, the value of configuration-led design is not just convenience. It directly affects whether governance can scale as joiner-mover-leaver processes, access requests, certifications, and policy enforcement expand across more applications and more identity types. A governance model that depends heavily on custom code tends to accumulate hidden dependencies and ownership risk.
Configuration-led approaches also fit naturally with standard IGA operating patterns such as IAM and IGA Basics, where the control objective is to manage access decisions consistently rather than rewrite the product to achieve them. For many programmes, that is what makes the difference between a maintainable control plane and an implementation that becomes fragile over time.
Common Implementation Patterns
Most configuration-led IGA programmes concentrate on a few repeatable building blocks: role and entitlement models, request and approval workflows, certification campaigns, segregation-of-duties rules, and lifecycle automation. Those are the places where built-in policy surfaces can usually deliver most of the governance value without custom development.
The best implementations also keep the model close to business ownership. Policy templates, workflow steps, and review logic should be understandable enough for identity teams and control owners to explain and sustain them, rather than requiring specialist developers to interpret every change. That is one reason many organisations pair this approach with disciplined role design and lifecycle controls such as Role Mining and Role Design Guide and Joiner-Mover-Leaver (JML) Guide.
Operational Trade-Offs and Limits
Configuration-led IGA is strongest when the product can express the required control outcome directly. It becomes less effective when teams try to force highly unusual approval chains, bespoke entitlement logic, or deeply application-specific exceptions into generic configuration. At that point, the platform can still work, but the governance model starts to drift back toward shadow code, exceptions, or manual compensating steps.
That is why a configuration-led model should be assessed against the actual control requirement, not just the desire to avoid engineering effort. If the platform can support the rule natively, configuration is usually the cleaner path. If it cannot, the safer answer may be to simplify the control design rather than build a fragile custom layer on top.
Risk and Threat Considerations
Configuration-led IGA reduces some forms of implementation risk, but it can still fail if teams over-trust defaults, misconfigure policy templates, or leave stale governance logic in place after organisational changes. The main exposure is not usually code exploitability, but control drift, inconsistent enforcement, and review processes that no longer match the real access model.
Failure mechanism: Governance rules embedded in configuration can become obsolete, overly permissive, or fragmented across environments when ownership is unclear or when changes are made without a disciplined review cycle. That creates gaps in certification, SoD enforcement, and lifecycle decisions.
Impact: The result can be privilege creep, inaccurate access evidence, weak auditability, and control outcomes that look standardised on paper but behave inconsistently in practice.
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 and Access Management | Covers cloud identity governance and access control design for governed configuration. |
| Recommendation — Use IAM to standardise identity governance workflows and control ownership in the platform. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Defines lifecycle governance for accounts and access changes central to IGA workflows. |
| AC-6 — Least Privilege | Supports policy-driven entitlement design and minimising excess access in IGA. | |
| AU-2 — Event Logging | Configuration-led IGA needs auditable governance events for reviews and approvals. | |
| Recommendation — Apply AC-2 to govern account lifecycle changes through controlled workflows and approvals. Use AC-6 to keep entitlement models and role assignments aligned to least privilege. Log governance events so access decisions and review outcomes remain evidenceable. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Annex A access control governance maps to policy-led identity governance outcomes. |
| Recommendation — Map access control policy to native workflow and role configuration. | ||
Practitioner Guidance
Governance implication: Treat configuration as the primary control surface and assign explicit ownership for policy templates, role models, workflow changes, and exceptions. If those objects are not governed like controls, the platform will quietly drift away from the intended model.
What to watch for: Repeated one-off exceptions, workflow duplication, or frequent post-go-live scripting usually signals that the configuration model no longer matches the operating reality. At that point, the issue is often control design, not just implementation detail.
Practitioner takeaway: Configuration-led IGA works best when the product’s native governance features are designed to carry the control, not merely support it.
Related resources from NHI Mgmt Group
- What is the difference between a persona-driven IGA design and a product-led IGA design?
- How should security teams distinguish configuration from customization when modernising IGA platforms?
- What do security teams get wrong about IGA automation and no-code configuration?
- How do you decide between code-based and configuration-led connectors?