By NHI Mgmt Group Editorial TeamBased on Zluri: “Overcome Legacy Barriers:Modernize Your IGA Now” (August 25, 2025)

TL;DR: Legacy on-prem IGA systems struggle to keep pace with hybrid work, SaaS sprawl, and modern security expectations, according to Zluri, because integration, scalability, and maintenance burdens create visibility gaps that static deployments were never designed to absorb. The governance problem is not just migration friction, but a control model that lags the identity surface it is meant to govern.


At a glance

What this is: This article argues that legacy on-prem IGA now creates visibility, integration, and scaling gaps in hybrid environments, making cloud-based governance the more workable model.

Why it matters: For IAM, IGA, and security teams, the issue is not only modernization cost, but whether their governance model can still see, certify, and update access fast enough across SaaS, cloud, and on-prem estates.

By the numbers:

  • Nearly 40% of organizations still have not deployed cloud-based IGA solutions, according to Omada’s State of Governance 2025 report cited by Zluri.
  • A company with 500 employees can expect to spend anywhere between $300k to $500k on the implementation process, according to Zluri.
  • Zluri says its integration layer includes over 300 prebuilt connectors with popular SaaS and cloud apps.

Context

Legacy on-prem IGA was designed for a fixed estate of servers, directories, and tightly bounded workflows, not for a hybrid workforce and an expanding SaaS stack. In that model, identity data changes slowly enough for periodic administration to keep up, but modern access governance depends on continuous visibility across far more moving parts.

Zluri’s article frames the central problem as a governance gap, not just a deployment preference. The more identities, applications, and access paths spread across cloud services, the less a static on-prem control plane can see, certify, or update in time. That is why the article treats modernization as an operational necessity rather than a convenience.

The article is clearly positioned as a migration and control-model argument: legacy IGA can still function, but it no longer matches the environment it is expected to govern. That is typical for organisations that scaled access management around older infrastructure assumptions and are now trying to extend them to SaaS-heavy operations.


Key questions

Q: What breaks when legacy IGA is used in cloud-first environments?

A: Legacy IGA breaks down when identity change outpaces manual governance. It depends on rigid integrations, on-prem infrastructure, and human reconciliation, so access data becomes stale and remediation slows. That creates gaps in joiner-mover-leaver handling, access reviews, and enforcement, especially when SaaS and hybrid systems change continuously.

Q: Why do legacy IGA tools create more risk for smaller organisations?

A: Legacy IGA often assumes large IT teams, long implementation projects, and custom integrations. In smaller organisations, that leads to partial deployment, manual workarounds, stale access records, and delayed reviews. The risk is not only inefficiency. It is governance failure, because access can drift faster than the process can correct it.

Q: What do teams get wrong when modernising IGA?

A: Many teams focus only on replacing the platform and underestimate the need to redesign access policies, certification cadence, and data sources. Without that reset, a newer tool can still inherit the same slow workflows and incomplete visibility that made the legacy model difficult to govern.

Q: How do organisations know whether their IGA programme is actually working?

A: Look for fewer orphaned accounts, fewer unresolved SoD conflicts, and a lower rate of redundant approvals in certification campaigns. If the programme is healthy, access reviews should produce cleaner entitlement data and fewer exceptions over time, not just higher completion percentages.


Technical breakdown

Why legacy IGA loses sight of modern identity sprawl

Legacy IGA platforms were built around fixed directories, predefined workflows, and integration patterns that assumed relatively stable enterprise systems. Once SaaS applications, third-party tools, and hybrid infrastructure enter the picture, those assumptions break down. Proprietary connectors and custom coding slow integration, while incomplete data flows leave access state fragmented across systems. The result is not simply slower administration. It is weaker identity visibility, delayed certification, and a governance layer that cannot reliably reflect current access conditions across the full estate.

Practical implication: map where identity data is duplicated or delayed before deciding which on-prem workflows can safely remain.

How scalability and maintenance become governance risks

Scalability in IGA is not only a capacity issue, it is a control issue. When every new app or workflow requires manual configuration, specialist support, or expensive infrastructure changes, governance becomes slower exactly where business speed is increasing. That creates a mismatch between access growth and governance throughput. High maintenance overhead also diverts operational attention away from access policy quality, recertification accuracy, and exception management, which means the control plane consumes more effort while producing less usable assurance.

Practical implication: treat platform overhead as a governance constraint, not just an IT cost, when evaluating IGA architecture.

Why modern security perimeters change the access model

The article links modernisation to zero trust and least privilege because the access model itself has changed. In a cloud-first environment, identities and service accounts cannot be assumed safe simply because they sit inside a network boundary. Governance now has to verify access continuously, support micro certification, and respond to role changes before excess access accumulates. That shifts IGA from reactive cleanup toward policy enforcement that is closer to the point of access request and entitlement change.

Practical implication: align certification and access review cycles to current role volatility rather than legacy calendar cadence.


NHI Mgmt Group analysis

Legacy IGA is now a visibility control problem, not just a deployment problem. The article shows that on-prem governance breaks down when identity data, SaaS entitlements, and workflow triggers are scattered across too many systems for a static control plane to reconcile quickly. That creates blind spots in certification, access updates, and exception handling. The practitioner conclusion is straightforward: if governance cannot see current access, it cannot credibly govern it.

The real gap is control latency between identity change and governance action. Legacy IGA assumes access changes can be absorbed through slower, centrally managed processes. That assumption was tolerable in bounded environments, but it fails when organisations add cloud apps, rotating roles, and faster onboarding cycles. The implication is not merely that teams need more automation; it is that their governance model must match the tempo of the environment it oversees.

Static IGA architecture is misaligned with zero trust operating logic. The article’s emphasis on least privilege, micro certification, and continuous verification reflects a broader shift in identity governance. Access is no longer a one-time entitlement state that can be periodically reviewed in isolation. Practitioners should read this as a signal that governance controls need to move closer to issuance, role change, and application onboarding.

Cloud-based IGA is becoming the baseline for governable identity sprawl. Zluri’s article does not prove that every legacy platform should be replaced immediately, but it does show that the category itself has shifted. The market is moving toward systems that can integrate quickly, certify continuously, and scale with SaaS growth. For teams, the practical question is no longer whether on-prem IGA can still run, but whether it can still keep pace with the programme it is meant to support.

Modernisation exposes an identity governance gap that many programmes have normalised. Organisations often treat manual effort, custom integration, and delayed certification as tolerable friction. In reality, those are symptoms of a control model that no longer matches the identity surface. The practitioner takeaway is to re-evaluate whether the current IGA estate is controlling access, or simply recording it after the fact.

From our research library:

What this signals

Legacy IGA modernization is really a control-plane redesign. The issue is not whether an older platform can still function, but whether it can govern an identity surface that now changes faster than its workflows were built to handle. Teams should evaluate whether their current process still gives them timely entitlement visibility or only retrospective audit evidence.

Identity governance now has to absorb SaaS growth, not just monitor it. That means certification, provisioning, and access policy enforcement need to happen closer to the rate of change in the environment. If those controls remain calendar-driven and integration-heavy, the programme will continue to trail the actual access estate.

Least privilege and micro certification are only effective when the governance model can execute them at speed. In practice, that pushes teams toward more automated integrations, shorter review windows, and cleaner identity data flows across HR, IdP, and application systems.


For practitioners

  • Map current identity sources and workflow delays Inventory where identities, entitlements, and access requests are stored, then measure provisioning, deprovisioning, and certification cycle times across those systems.
  • Prioritise integrations that reduce custom coding Favour IGA options that connect directly to IdPs, HRMS platforms, SaaS applications, and on-prem systems without heavy bespoke scripting.
  • Rebuild access policies around zero trust and least privilege Replace static entitlement assumptions with policies that verify access at change points and limit permissions to the minimum needed for current tasks.
  • Shorten certification cycles for fast-changing apps Use more frequent access certification where application sprawl or role churn is highest so stale permissions do not accumulate between reviews.
  • Measure whether manual governance effort is falling After modernization, track how much human intervention remains in provisioning, approvals, and recertification to confirm the new control model is actually reducing friction.

Key takeaways

  • Legacy on-prem IGA can still operate, but it struggles to govern modern hybrid environments with enough speed and visibility to stay reliable.
  • The article’s core evidence is operational, not theoretical: integration effort, maintenance burden, and scale limits all grow as SaaS and hybrid complexity increase.
  • Modernisation matters because the control model must move closer to current access state, not just record historical entitlement changes after the fact.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AA-05 — Access Permissions, Entitlements and AuthorizationsThe article is about entitlement visibility and access governance across changing environments.
Recommendation — Use PR.AA-05 to tighten entitlement review and authorization handling across hybrid identity estates.
CIS Controls v8CIS-5 — Account ManagementLegacy IGA pain shows up in account lifecycle, provisioning, and access administration.
Recommendation — Apply CIS-5 to improve account governance and reduce manual access administration drift.
NIST SP 800-53 Rev 5AC-6 — Least PrivilegeThe article explicitly ties modern IGA to least privilege and reduced access sprawl.
Recommendation — Enforce AC-6 so access stays minimal as roles and SaaS apps change.
NIST Zero Trust (SP 800-207)Principle of Least Privilege — Principle of Least PrivilegeThe article frames modern IGA around zero trust verification and least privilege.
Recommendation — Align IGA policy with least-privilege principles and verify access at change points.

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.
  • 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.
  • Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.
  • SaaS Sprawl: SaaS sprawl is the uncontrolled spread of software-as-a-service applications across teams and business units. It creates fragmented ownership, duplicated functionality, and weak visibility into who can access what. For IAM and NHI teams, the main risk is not only cost but persistent entitlements that outlive business need.

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.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 11, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org