IGA best practices are established, but often ignored

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Fischer Identity's blog post: IGA best practices already exist, but the main failure is organisations and vendors ignoring them in favour of shortcuts that erode governance.

Why it matters: It matters because IAM and IGA teams need repeatable lifecycle, access, and certification controls, not fragile custom implementations that complicate audits and slow change.

Context

Identity governance and administration already has a mature body of practice, but many programmes still struggle because they treat configuration choices as if they were governance strategy. When teams replace authoritative data, lifecycle automation, policy-based access, and certification discipline with custom logic, the result is not flexibility but control drift.

This article is about the gap between established IGA principles and how they are actually implemented. For IAM and IGA practitioners, the question is whether the programme is enforcing repeatable control or compensating for weak design with scripting, manual work, and one-off exceptions.

Key questions

Q: Why do IGA programmes fail even when the policy framework looks complete?

A: They fail when the platform cannot see all the systems where access exists or when entitlement ownership is unclear. Policy language does not control what discovery cannot find, and certification does not meaningfully reduce risk if reviewers are approving stale or unowned access.

Q: What breaks when identity governance is coded from scratch?

A: What breaks first is usually maintainability. Homegrown governance struggles when connectors change, policies need refinement, or new identity types appear, because the platform depends on custom code everywhere. Over time, this makes access visibility, certification, and offboarding harder to keep accurate and auditable.

Q: How do teams know if IGA is actually working?

A: Look for evidence that entitlement changes are being governed before access expands beyond need. Useful signals include shorter exception queues, fewer unresolved access outliers, and review outcomes that lead to measurable entitlement reduction rather than paperwork completion.

Q: What is the difference between policy-driven IGA and flexible custom implementation?

A: Policy-driven IGA expresses decisions in configuration, so the rules are visible and repeatable. Custom implementation pushes those decisions into code, where they become opaque and harder to govern. The practical difference is whether identity control survives routine change without losing auditability or creating hidden exceptions.

Technical breakdown

Authoritative source alignment in IGA

IGA depends on trusted source systems because identity governance only works when the programme can determine who someone is, what relationship they have to the organisation, and when that relationship changes. HR, student, ERP, and CRM systems are examples of authoritative sources because they anchor provisioning and deprovisioning logic. When those sources are bypassed, identity state becomes subjective and inconsistent across platforms, which makes certification and audit trails unreliable.

Practical implication: anchor lifecycle decisions to authoritative systems before layering access workflows on top.

Policy-based access instead of custom code

Policy-based access control uses roles, attributes, and rules to express entitlement decisions in configuration rather than code. That distinction matters because custom scripts create hidden dependencies that are hard to test, hard to upgrade, and easy to break during platform change. In mature IGA design, access logic should be inspectable, repeatable, and separable from implementation plumbing so that governance survives product updates and organisational change.

Practical implication: encode access policy in governed configuration, not in brittle custom workflows.

Continuous attestation and auditability

Access certification is only useful when it is repeatable, traceable, and tied to current identity state. Periodic reviews lose value when provisioning and deprovisioning are inconsistent or when managers are reviewing stale data. A defensible IGA programme therefore needs evidence trails that show who approved what, when the entitlement changed, and whether the control state matches policy at the moment of review.

Practical implication: make review evidence and decision history part of the control, not a reporting afterthought.

NHI Mgmt Group analysis

IGA failures are usually execution failures, not framework failures. The core principles of authoritative data, automated lifecycle, policy-based access, and auditable certification are already settled across the discipline. What breaks in practice is the decision to replace them with shortcuts that optimise for perceived speed while weakening control determinism. Practitioners should treat inconsistent implementation as the real governance risk, not a lack of guidance.

Customization debt is a governance problem, not just a technical one. When identity logic lives in scripts or external development, the programme inherits fragility that surfaces during upgrades, exceptions, and audits. That turns IGA into a maintenance burden rather than a control system. The practical conclusion is that configuration-driven governance is not an aesthetic preference; it is what keeps access decisions durable under change.

Auditable IGA is built on repeatability, not one-off success stories. A programme that works only when a small set of implementers are available has not achieved governance maturity. Repeatable outcomes are the signal that the control design is stable, inspectable, and sustainable across cloud, hybrid, and on-prem environments. The discipline to enforce the same rules every time is what separates governance from administration.

Identity governance should be judged by control fidelity, not feature breadth. Many organisations accumulate capability but still fail to enforce authoritative data, lifecycle automation, and certification discipline as a coherent operating model. That creates a programme that looks modern but behaves inconsistently under pressure. The field should measure whether IGA systems preserve policy intent across the identity lifecycle, because that is where governance either holds or collapses.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.

What this signals

Configuration is the control boundary: IGA programmes that rely on scripts and side workflows make governance depend on implementation knowledge instead of policy intent. The more control logic moves outside governed configuration, the harder it becomes to prove that access decisions are repeatable across upgrades and organisational change.

The stronger signal for practitioners is whether lifecycle decisions, access policy, and certification evidence all come from the same control model. If those pieces live in different places, the programme may still function, but it will not scale cleanly or withstand audit scrutiny.

For practitioners

• Enforce authoritative source governance Map each identity population to a single source of truth for joiner, mover, and leaver events, then remove competing manual entry points that can override lifecycle state.
• Replace scripted access logic with configuration Move entitlement rules, approvals, and exception handling into governed configuration so changes remain visible, testable, and upgrade-safe.
• Standardise certification evidence Require every access review to retain approver identity, decision timestamp, entitlement snapshot, and policy rationale so audit trails remain defensible.
• Retire fragile custom workflows Inventory bespoke IAM and IGA scripts, rank them by operational dependency, and plan their removal where they duplicate native platform controls or create upgrade risk.

Key takeaways

• IGA maturity is not blocked by missing standards, but by programmes that ignore the standards they already have.
• Custom code, manual governance, and inconsistent provisioning are the main reasons identity controls become fragile.
• Practitioners should judge IGA by repeatability, evidence, and policy fidelity rather than by feature count.

Key terms

• Authoritative Data Source: A trusted source used to confirm identity attributes, such as a government database or regulated banking record. These sources reduce reliance on self-reported information and improve confidence in onboarding decisions. The quality of the verification outcome depends heavily on source coverage, freshness, and whether the data can be matched reliably.
• Access Certification: Access certification is the periodic review of whether an identity still needs its current entitlements. For NHIs, certification is only reliable when reviewers know the identity's owner, purpose, and expiry, otherwise stale machine access can persist long after the original use case has ended.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• Lifecycle Automation: The automation of identity events such as onboarding, access changes, and revocation so governance follows the full user or account lifecycle. It reduces manual errors, shortens exposure windows, and helps organisations enforce consistent access controls at scale.

Deepen your knowledge

NHI governance, identity lifecycle, and secrets management 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 or IGA programme, it is worth exploring.