It becomes the better fit when your identity programme needs repeatable governance across multiple systems and business units, and when change velocity makes bespoke engineering unsustainable. If each workflow change requires development, testing, and rollback planning, the platform is no longer serving governance. Configuration should absorb change, not create it.
Why This Matters for Security Teams
A configurable IGA model becomes the stronger fit when identity governance needs to scale faster than engineering can safely custom-build. The real decision is not “configuration versus code” in the abstract. It is whether access rules, approvals, and certification logic can keep pace with business change without turning every workflow adjustment into a software release. That matters because identity control failures rarely stay theoretical. NHI Mgmt Group notes that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys in the Ultimate Guide to NHIs, which is a reminder that governance gaps are usually exposed under operational pressure, not during design reviews.
For security teams, the practical threshold is reached when business units, applications, and entitlement models diverge enough that custom code becomes a maintenance burden. At that point, the platform should absorb policy variation, approval routing, and periodic review logic. If it cannot, teams end up hard-coding exceptions and inheriting brittle access paths that are difficult to audit. Current guidance from the NIST Cybersecurity Framework 2.0 aligns with this shift toward repeatable governance and measurable control outcomes. In practice, many security teams discover the break point only after a workflow change has already triggered delay, backlog, or an emergency code patch.
How It Works in Practice
Configurable IGA works best when the organisation can model identity processes as reusable policy components rather than one-off application logic. Instead of writing custom development for each joiner, mover, leaver flow, the team defines approval paths, entitlement bundles, certification cycles, and segregation-of-duties checks in the platform. This makes governance easier to maintain across multiple systems and business units, especially where roles are broadly similar but not identical.
The implementation question is usually whether the platform can express the organisation’s real complexity without forcing code. Good candidates for configuration include:
- Access request workflows with conditional approvals based on role, geography, or risk level
- Recertification campaigns that vary by application criticality or data sensitivity
- Lifecycle events such as onboarding, transfer, and termination across multiple directories
- Entitlement grouping that reduces repeated manual assignment logic
This is especially relevant for non-human identities, where the underlying issue is often not just provisioning speed but control consistency. NHIs outnumber human identities by 25x to 50x in modern enterprises, according to NHI Mgmt Group’s Ultimate Guide to NHIs, so a configuration-first model can help standardise how service accounts, API keys, and automated workflows are governed. For control design, the least risky pattern is to keep business logic in policy and use code only where the platform cannot express a genuine edge case. That keeps auditability intact and avoids turning identity governance into a bespoke application.
Where this guidance breaks down is in highly specialised environments with proprietary entitlement structures, deeply embedded legacy systems, or exception-heavy M&A integrations, because the platform may not be able to model the workflow cleanly enough without significant custom extensions.
Common Variations and Edge Cases
Tighter configuration often increases upfront process discipline, requiring organisations to balance speed of delivery against the need for standardisation. That tradeoff is real: configuration reduces long-term maintenance, but it can also expose gaps in governance maturity when teams are used to solving everything through code.
The most common edge case is the “almost configurable” platform, where core workflows are supported but critical exceptions still require custom scripts, APIs, or external orchestration. Current guidance suggests treating that as a warning sign rather than a minor inconvenience. If every meaningful business change still needs development support, the organisation has not actually escaped custom build risk.
Another edge case appears in decentralised enterprises. Business units may demand unique approval chains, but if those differences are mostly local preference rather than risk requirement, the model should standardise anyway. That is where configurable IGA earns its value: it enforces shared governance while still allowing bounded variation. For identity programs under heavy audit scrutiny, a platform that supports repeatable policy evidence is usually more sustainable than one that depends on tribal knowledge in scripts. In environments with frequent restructuring, high application churn, or many third-party integrations, configurable IGA is usually the safer operational choice because it preserves traceability when the identity estate keeps changing.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Identity governance must scale consistent access control across systems and units. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Custom code often masks weak NHI lifecycle governance and inconsistent entitlement handling. |
| NIST AI RMF | GOVERN | Governance discipline is needed when identity workflows must change without engineering debt. |
| NIST Zero Trust (SP 800-207) | PA | Zero Trust depends on policy-based access decisions rather than hard-coded exceptions. |
| CSA MAESTRO | IAM-01 | Configurable identity controls support repeatable governance for complex, distributed environments. |
Use configurable IGA to centralise NHI lifecycle controls instead of embedding identity logic in bespoke code.
