Governance by design in IGA: what flexibility and control really mean

At a glance

What this is: This is a vendor-authored argument for governance by design in IGA, claiming that configuration-driven control can preserve flexibility, auditability, and operational ownership.

Why it matters: It matters because IAM and IGA teams need to understand whether a platform’s operating model strengthens or weakens control over identity workflows, lifecycle governance, and audit readiness.

👉 Read Fischer Identity's governance-by-design blog on flexibility and control

Context

Governance by design in identity governance and administration is the idea that policy, control, auditability, and operational change should be embedded in the platform’s normal configuration model rather than bolted on through scripts or vendor-led exceptions. In practice, the debate is about who holds authority over workflows, integrations, and policy changes once the system is live.

For IAM and IGA teams, the real issue is not whether a platform is cloud-based or on-premises. It is whether the operating model preserves governance ownership as the environment changes, especially when lifecycle, audit, and access decisions must be adjusted without introducing hidden dependency or control loss.

Key questions

Q: How should IAM teams evaluate an IGA platform for lifecycle governance?

A: Start with lifecycle completeness, not feature count. A strong IGA platform should prove that it can provision, certify, and revoke access across the systems you actually run, including exceptions, third parties, and privileged access. If the tool cannot reliably close the loop on offboarding and recertification, it will create governance debt rather than reduce it.

Q: When does a cloud identity platform create more governance risk than it reduces?

A: Risk rises when the platform is cloud-hosted but the team cannot explain tenancy, data residency, release drift, or operational ownership. In that case, the tool may improve workflow efficiency while weakening auditability. Governance fails when cloud convenience hides control ambiguity.

Q: What do security teams get wrong about flexibility in IGA platforms?

A: They often treat flexibility as the ability to configure many options, when the deeper issue is whether those options remain governed and auditable after deployment. Flexibility without clear authority can create drift, exceptions, and hidden dependency. Mature IGA makes change easier without making ownership ambiguous.

Q: What is the difference between configurable governance and custom-code identity automation?

A: Configurable governance expresses rules, workflows, and integrations through the platform’s native controls, while custom-code automation ties those same functions to bespoke logic that is harder to audit and maintain. The former supports clearer ownership and upgrade resilience. The latter often creates long-term implementation debt that weakens governance.

Technical breakdown

Configuration-driven governance in IGA

A configuration-driven IGA model lets administrators define workflows, business rules, and connector behaviour through platform settings rather than custom code. That matters because custom code creates change debt, while configuration preserves a clearer control plane for audit, rollback, and review. In governance terms, the distinction is between changing identity behaviour through maintainable policy objects versus changing it through brittle implementation artefacts. The platform still has to enforce approvals, certifications, and exceptions, but the way those controls are expressed determines whether the organisation can own them operationally.

Practical implication: teams should assess whether policy changes are genuinely customer-controlled or still require vendor intervention.

Why administrative control matters for compliance

IGA only supports compliance if administrators can adjust access logic, integrate new systems, and update business rules in a timeframe that matches risk and regulatory change. If those changes depend on external development cycles, governance becomes reactive rather than enforceable. Full administrative control is therefore not a convenience feature, but a condition for maintaining evidence, traceability, and policy consistency. The practical question is whether the platform lets the organisation keep its own control decisions close to the operating model, or whether it converts governance into a support ticket.

Practical implication: verify who can make policy, workflow, and integration changes, and how quickly those changes can be audited.

Unified control across cloud, hybrid, and on-prem environments

Identity environments rarely stay in one deployment model, so governance has to remain consistent across cloud, hybrid, and on-prem instances. When the same capabilities and interfaces are available across environments, administrators can apply the same approval logic, reporting, and lifecycle controls without maintaining separate operational playbooks. That reduces drift, but only if the platform’s shared architecture really preserves function parity rather than hiding separate behaviour behind a common label. The governance challenge is consistency of control, not consistency of marketing language.

Practical implication: compare control behaviour across deployment modes before assuming the same governance standard applies everywhere.

NHI Mgmt Group analysis

Governance by design is an ownership model, not a UI preference. If administrators cannot control workflows, policies, and integrations directly, identity governance becomes dependent on a vendor-mediated change path. That weakens auditability because the organisation no longer fully owns the conditions under which access decisions are made. The implication is that IGA maturity should be judged by operational authority, not by surface-level configurability.

The false choice between flexibility and control hides the real control-plane question. Cloud delivery does not automatically reduce governance, but cloud dependency can move policy authority outside the organisation if the platform requires vendor action for routine changes. That is especially problematic when compliance, exception handling, and integration updates need to happen on the business timeline. Practitioners should read “flexibility” as a test of who can act, when, and under what constraints.

Continuous governance only works when change is auditable at the point of configuration. A system that preserves identical capability across deployment models can reduce operational drift, but only if every change remains traceable to a defined business rule or administrator action. This is where governance-by-design becomes meaningful: the control is built into the change path itself. Teams should treat shared architecture as useful only when it preserves evidence and accountability.

Fischer Identity’s argument reflects a broader IGA market shift toward configurable control planes. The market is moving away from identity platforms that depend on custom code or vendor-managed change for core governance functions. That shift matters because lifecycle management, access reviews, and integration governance are increasingly judged on speed of adaptation as much as on control. Practitioners should expect buyers to ask harder questions about control ownership during platform selection.

For NHI and agentic AI programmes, the same governance principle applies: control must remain local to the identity programme. Even when the subject is not a human user, the platform must allow the organisation to define lifecycle, policy, and review behaviour without external dependency. That is the only way to keep governance aligned with the pace of machine and autonomous identity change. Teams should use human IAM lessons to pressure-test machine identity control ownership.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
• For governance maturity and lifecycle control, Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is the most practical next reference.

What this signals

Governance-by-design will become a selection criterion, not a branding claim. As identity programmes absorb more machine and autonomous actors, teams will increasingly test whether policy changes, lifecycle actions, and audit evidence stay under customer control. A platform that cannot prove control ownership will struggle to support modern IAM operating models, especially where change velocity is high.

The management signal is simple: if your current IGA stack needs external intervention for routine governance changes, your programme has already inherited a control dependency. That dependency will show up first in audit exceptions, then in delayed access decisions, and finally in inconsistent lifecycle enforcement across environments.

Identity blast radius: The real measure of governance quality is how far a bad change can travel before the organisation can stop it. When workflows, connectors, and policies are locally controlled, the blast radius is smaller and easier to evidence. When they are vendor-mediated, every change carries more operational and compliance friction.

For practitioners

• Map control ownership before evaluating platform flexibility Document which identity actions your team must be able to change without vendor intervention, including workflows, business rules, connectors, and audit logic. If those changes require a support queue or custom development, governance is weaker than it appears.
• Test deployment parity under real governance scenarios Compare cloud, hybrid, and on-prem behaviour for approvals, certifications, and integrations using the same test cases. The goal is to verify that the same governance decision produces the same outcome everywhere, not just a similar interface.
• Separate configuration from customisation debt Inventory every script, workaround, and exception path that currently supports identity governance. Then determine which controls can be expressed as configuration so audit, rollback, and ownership stay inside the operating model.
• Require evidence of administrative authority Ask platform owners to show how quickly a customer can modify policy, update workflows, and integrate new systems without developer dependency. That evidence tells you whether the organisation truly governs the platform or merely operates inside it.

Key takeaways

• Governance by design is about retained authority over identity change, not about platform aesthetics.
• IGA programmes weaken when policy, workflow, and integration changes depend on external implementation paths.
• The practical test is whether the organisation can audit and enforce identity decisions at the point of configuration.

Key terms

• Governance by Design: A control model that embeds standards, validation, and approval directly into the workflow where work is created or changed. Instead of relying on later review, it enforces acceptable state at the point of entry, which makes compliance and integrity part of normal operations.
• Configuration-driven design: Configuration-driven design lets teams change identity workflows and control logic through native settings rather than bespoke code. That approach improves maintainability and auditability because the organisation can own the change process without relying on custom implementation layers that are harder to inspect, test, or upgrade.
• Administrative authority: Administrative authority is the practical ability to modify policies, workflows, integrations, and reporting without waiting on a third party. In identity governance, it is a marker of real control because it determines whether the organisation can respond to risk, compliance, and business change on its own timeline.

What's in the full article

Fischer Identity's full blog covers the operational detail this post intentionally leaves for the source:

• Customer-facing configuration paths for workflows, policies, and connectors without custom code
• Examples of how full administrative access is handled across multi-tenant and dedicated deployments
• The vendor's own explanation of predictable upgrades and shared code base behaviour
• Operational claims about unified control across cloud, hybrid, and on-prem environments

👉 The full Fischer Identity post expands on configuration-driven governance and deployment consistency.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.