Agile identity automation exposes the limits of rigid IGA

At a glance

What this is: NHI Mgmt Group's analysis, drawing on READI's blog post: Identity governance breaks down when scale, decentralised directories, and regulatory expectations outgrow rigid automation models.

Why it matters: IAM and IGA teams need adaptable governance patterns because operational scale, mergers, and distributed application estates quickly expose the limits of static provisioning workflows.

Context

Identity governance becomes brittle when the operating model assumes a stable directory structure, a single tenancy pattern, and a manageable volume of joins, moves, and leavers. Once the environment spans cloud and on-prem systems, multiple business units, and divergent entitlement models, the problem shifts from simple automation to governance that can tolerate local variation without losing control.

READI frames the core issue as one of practicality rather than theoretical coverage. The platform model described in its blog post reflects a broader IAM pattern: organisations often have tools in place, but the tools cannot absorb the pace, fragmentation, and exception handling that real identity operations demand.

Key questions

Q: How do identity teams scale provisioning across fragmented environments?

A: Identity teams scale provisioning by centralising policy and orchestration while using connectors, APIs, and event-driven workflows to reach disconnected systems. Access should be assigned from a single source of truth, with reconciliation, role mappings, and exception handling for systems that cannot support native automation, so accounts, groups, and entitlements stay consistent across heterogeneous estates.

Q: Why do rigid IGA workflows fail in complex enterprise estates?

A: Rigid IGA workflows fail when they cannot model real entitlements, ownership, or exceptions across different platforms, so requests stall or land with the wrong access. Static approval chains and fixed role catalogues break down in estates with legacy systems, local admin rights, and custom applications, where policy needs attribute checks, delegated approvals, and account reconciliation.

Q: How should teams govern custom identity automation scripts?

A: Custom identity automation scripts should be treated as controlled privileged tooling with an owner, source control, change review, and logging. They need least-privilege credentials, secrets stored outside the code, input validation, and tested rollback paths, because a script that provisions accounts or changes entitlements can create or remove access at machine speed.

Q: What should identity leaders prioritise when mergers add multiple directories?

A: Identity leaders should first map where directories overlap, where they are authoritative, and how users, groups, and roles will be merged or separated. Mergers often leave duplicate identities and conflicting entitlements, so consolidation needs matching rules, account linking, access review, and a plan for decommissioning separate groups, roles, and local policies.

Technical breakdown

Why rigid IGA breaks under distributed identity operations

Traditional IGA platforms assume a comparatively uniform estate where access rules, application connectors, and entitlement models can be standardised. That breaks down when identity operations must span thousands of local variations, mixed hosting models, and different role structures across business units. In practice, the failure is not lack of a workflow but lack of elasticity in how the workflow adapts to local conditions. The result is that teams start compensating with scripts, manual exceptions, and side processes, which restores motion but also fragments governance. See the NHI Lifecycle Management Guide.

Practical implication: Treat flexibility as a governance requirement, not just an implementation convenience, when standard workflows cannot represent local identity realities.

How scripting-like automation changes the identity control model

Scripting gives identity teams fine-grained control over edge cases, but it also shifts the control model from central policy orchestration to distributed operational logic. That matters because the more the team depends on custom code, the more governance quality depends on who maintains the scripts, how changes are reviewed, and whether execution remains consistent across environments. The underlying architecture is therefore less about connectors and more about coordination across heterogeneous systems, with cloud and on-prem execution both needing the same policy intent.

Practical implication: Map every custom automation path to an owner, review cycle, and testable policy outcome so operational flexibility does not become hidden control drift.

Why multi-tenant and merger scenarios expose identity governance gaps

Multi-tenant and merger-heavy environments intensify the identity problem because every acquired or separately run organisation brings its own directories, groups, entitlements, and local operating habits. The governance challenge is no longer simply provisioning at scale, but normalising control across systems that were never designed to behave the same way. That makes access certification, entitlement cleanup, and application onboarding harder because the programme must preserve business continuity while still imposing a common control expectation across different identity estates. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.

Practical implication: Design governance patterns that can absorb inherited identity variation without assuming every environment can be flattened into one operating model.

Threat narrative

Attacker objective: The practical objective is not attacker compromise but organisational drift, where identity control loses consistency and operational risk rises as the estate expands.

1. Entry occurs through operational complexity, where a fragmented identity estate outgrows the control model and creates governance blind spots rather than a technical exploit path.
2. Escalation follows when teams compensate with hand-built scripts and parallel processes, increasing the number of places where policy intent can drift from execution.
3. Impact appears as delayed onboarding, slower offboarding, higher manual workload, and governance that no longer scales cleanly across the organisation.

NHI Mgmt Group analysis

Identity governance fails first as an operating model problem, not a connector problem. The central constraint in this kind of environment is not whether a platform can technically reach more systems, but whether it can absorb local variation without turning governance into a patchwork of exceptions. Once identity work depends on scripts and ad hoc orchestration to survive scale, the programme has already moved away from repeatable control into managed improvisation. Practitioners should treat that as a governance signal, not a tooling preference.

Flexibility becomes a control property when identity estates stop being uniform. A programme that can only work when directories, role models, and application patterns are standardised is fragile by design. The harder question is how to keep policy intent intact while allowing different business units, tenants, and environments to operate differently. That is where many IAM and IGA programmes overestimate the value of standardisation and underestimate the cost of exception handling.

Scale exposes the limits of human-operated remediation loops. When identity operations grow into millions of annual changes, the real test is whether the workflow still produces timely, auditable outcomes without requiring proportional staff growth. If the answer is no, the programme has not achieved automation in the identity-governance sense, only faster manual work. The consequence is predictable: backlog, inconsistency, and a widening gap between policy and practice.

Lifecycle governance is the right lens for this problem, but lifecycle alone does not solve it. Joiner, mover, and leaver processes still matter, yet they must now operate across many different identity sub-estates with distinct ownership and control patterns. The discipline is the same, but the execution model has to account for organisational fragmentation. Practitioners should judge governance tools by whether they preserve lifecycle control under heterogeneity, not just under ideal conditions.

What this signals

Identity programmes that depend on perfect standardisation will keep failing in organisations that grow through acquisition, decentralised operations, or mixed hosting. The practical answer is not more abstraction, but governance that can survive exception handling without losing auditability.

Governance elasticity: the next generation of IAM programmes will be judged less by connector count and more by whether they can preserve lifecycle control across heterogeneous systems. Teams that still measure success mainly by automation coverage will miss the harder question, which is whether the control model remains stable when the environment does not.

For practitioners

• Define the identity estate by operating pattern Separate systems by tenancy model, ownership model, and entitlement complexity before deciding how much automation each group can tolerate.
• Map manual work to governance failure points Track where identity teams fall back to scripting, spreadsheets, or service desk intervention, then treat those points as control design gaps.
• Test workflows against mixed environments Validate provisioning and certification flows across cloud, on-prem, and disconnected applications instead of only in the most standardised environments.
• Review ownership for every custom automation path Assign explicit operational and policy owners to scripts, proxies, and exception handlers so control intent does not disappear into local fixes.

Key takeaways

• Identity governance breaks down when the environment becomes too diverse for a single operating model to describe cleanly.
• The practical failure mode is not lack of tooling, but the accumulation of scripts, exceptions, and manual interventions that fragment control.
• Teams should evaluate IAM and IGA by whether they still produce consistent outcomes across mixed estates, not just in standardised ones.

Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Top 10 NHI Issues · Ultimate Guide to NHIs: Regulatory and Audit Perspectives

Key terms

• Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
• Joiner Mover Leaver: Joiner Mover Leaver is the identity lifecycle process for creating, changing, and removing access as people enter, change roles, or leave an organization. It governs provisioning, modification, and deprovisioning across systems, ensuring access matches current job needs and reducing orphaned accounts, privilege creep, and residual access risk.
• Identity Lifecycle Management: Identity Lifecycle Management is the process of creating, changing, reviewing, and removing digital identities across their full lifespan. It governs how users, service accounts, API keys, certificates, and other NHIs are provisioned, updated, certified, and deprovisioned to keep access aligned with business need, policy, and risk.
• Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.