Notifications
Clear all
Topic starter
11/08/2026 3:22 pm
TL;DR: Modern IGA should not force a trade-off between flexibility and control, because governance built into configuration, administration, and upgrade paths can preserve auditability while reducing dependence on vendor-led change, according to Fischer Identity. The practical lesson is that governance-by-design is less about features than about who retains authority over workflows, policies, and integrations.
NHIMG editorial — based on content published by Fischer Identity: Governance by Design - Where Flexibility Meets Control
Questions worth separating out
Q: How should IAM teams evaluate an IGA platform for lifecycle governance?
A: Start with lifecycle completeness, not feature count.
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.
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.
Practitioner guidance
- 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.
- Test deployment parity under real governance scenarios Compare cloud, hybrid, and on-prem behaviour for approvals, certifications, and integrations using the same test cases.
- Separate configuration from customisation debt Inventory every script, workaround, and exception path that currently supports identity governance.
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
👉 Read Fischer Identity's governance-by-design blog on flexibility and control →
Governance by design in IGA - are your controls keeping up?
Explore further
11/08/2026 3:33 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Governance by design in IGA: what flexibility and control really mean
