By NHI Mgmt Group Editorial TeamPublished 2026-05-25Domain: Governance & RiskSource: Omada Identity

TL;DR: EMA’s January 2026 survey of 135 enterprise IT leaders found that 30% of organisations have scaled back IGA or Zero Trust programs, and 56.4% of that group reported an identity-related breach in the past year versus 18.7% of those that did not, according to Omada Identity. The pattern shows that governance risk concentrates where integration, complexity, and scaling failures outrun the operating model.


At a glance

What this is: The article argues that identity governance fails less on strategy than on execution, with breach risk concentrating when IGA programs stall under integration, complexity, and scaling constraints.

Why it matters: That matters because IAM teams across NHI, autonomous, and human identity programmes need operating models that keep control intent intact as environments, approvals, and ownership change.

By the numbers:

👉 Read Omada Identity's analysis of why identity governance stalls and breach risk concentrates


Context

Identity governance breaks when the operating model cannot keep pace with integration, scale, and control ownership. In practice, that means the program may still be strategically approved, but day-to-day execution becomes fragile enough that access drift, privilege creep, and ownership gaps begin to accumulate.

This article uses a January 2026 survey of 135 enterprise IT decision-makers and practitioners to show where IGA programmes stall and why that matters for IAM teams. The primary keyword here is identity governance, but the governance problem spans NHI, autonomous, and human identity programmes because the failure mode is operational consistency, not just policy intent.


Key questions

Q: How should organisations stop identity governance from stalling in practice?

A: Treat IGA as an operating model problem first. Strengthen integration with core systems, reduce manual exception handling, and validate that the review and approval process still works at scale. If the programme cannot sustain daily operations, adding more controls will not improve governance because the control fabric itself is unstable.

Q: Why does scaled-back governance increase breach risk?

A: When governance slows, access drift and privilege creep continue even if no single control fails outright. That means overprovisioned access can accumulate across users, workloads, and service accounts until an attacker or insider finds a path that should have been removed earlier.

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: Who is accountable when an identity governance programme fails?

A: Accountability sits with the operating model owner, not just the product owner. If control requirements, deployment architecture, and human review processes are not aligned, the programme can look compliant while still allowing exposure to build. Governance needs an explicit owner for the control outcome, not only for the platform.


Technical breakdown

Why identity governance stalls in real operating environments

The article points to integration with existing systems, complexity of use, and difficulty scaling as the main reasons IGA programs stall. That is a governance signal, not a tool complaint. If controls cannot survive contact with the current application estate, approval workflow, and ownership model, they do not become dependable security controls. The technical issue is usually not a missing feature. It is that the programme architecture cannot absorb real-world identity volume, exception handling, and change cadence without weakening policy enforcement.

Practical implication: evaluate IGA platforms against integration depth, exception handling, and scale resilience before expanding scope.

Access drift and privilege creep as governance failure modes

Access drift is the widening gap between the access an identity has and the access it actually needs. Privilege creep is the accumulation of rights over time as roles expand and reviews lag behind changes. In this article, those conditions are central because scaled-back governance allows risk to build quietly rather than appear as a single event. The mechanism matters because once ownership is unclear and review cycles cannot keep pace, overprovisioning becomes structurally normal instead of exceptional.

Practical implication: measure entitlement growth against job, workload, or service ownership changes, not just periodic review completion.

Why deployment architecture is part of identity governance

The blog argues that deployment choices are not just infrastructure preferences. On-premises, private cloud, and tenant-owned cloud models each change how data residency, regulatory controls, and audit authority are enforced. A multi-tenant platform can simplify operations, but it also shifts the control boundary. Where organisations need tenant ownership or sovereignty constraints, the architecture must support those obligations without pushing governance exceptions back into manual process.

Practical implication: treat deployment architecture as a control decision and document whether it satisfies data residency, audit, and ownership requirements.


Threat narrative

Attacker objective: The objective is to exploit governance decay so excessive access persists long enough to enable breach or misuse.

  1. Entry occurs when governance is adopted faster than the organisation can integrate it with existing systems, leaving controls partially implemented.
  2. Escalation follows as complexity and scaling limits prevent reviews, ownership checks, and policy enforcement from keeping pace with access growth.
  3. Impact emerges as privilege creep and overprovisioning accumulate, increasing the chance of an identity-related breach while the programme still appears in place.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Identity governance does not fail because leaders stop valuing it. It fails because the operating model cannot preserve control quality under integration pressure, scaling pressure, and daily exception handling. The article’s data shows that strategic support remains high while execution breaks down, which is exactly why sustainability has become the real measure of programme quality. Practitioners should read this as an operating-model problem, not a tooling preference.

Access drift is the clearest name for what happens when governance pauses. The concept is useful because it captures a structural gap between entitlement state and entitlement need, rather than a one-time configuration error. Once reviews slow, ownership blurs, and role boundaries widen, overprovisioning becomes cumulative. The implication is that identity risk is being stored in the programme itself, not only in the environment it governs.

Tool selection must follow control requirements, not reverse them. The article shows that many organisations still let platform capabilities shape policy, which is backwards from a governance perspective. If the control model is the output of the tool choice, then the programme inherits the tool’s assumptions. Practitioners should treat governance requirements as the design input and the technology stack as the constraint to test against.

Deployment architecture is now part of the identity control surface. The article’s discussion of on-premises, private cloud, and customer-tenant cloud models shows that governance decisions now include residency, sovereignty, and audit authority. That matters because a platform can meet workflow needs while still failing the organisation’s control boundary. The implication for practitioners is to evaluate where the control plane lives, not just where the identities reside.

From our research:

What this signals

Access drift is becoming the practical measure of whether identity governance is still real. When organisations let exception queues, ownership gaps, and privilege creep outpace review cycles, the control plane stops reflecting actual access state. That is why the operational question is no longer whether IGA exists, but whether it still changes entitlement outcomes before risk becomes permanent.

The same governance logic now applies across human, NHI, and autonomous programmes because operating-model failure does not respect identity type. For readers building or resetting their programme, the next step is to tie control requirements to deployment choices and lifecycle processes, then compare them against the NIST Cybersecurity Framework 2.0 rather than treating governance as a reporting function.

With 72% of organisations already reporting or suspecting NHI breaches according to The 2024 ESG Report: Managing Non-Human Identities, stalled governance is not a theoretical concern. The field signal is clear: identity programmes that cannot sustain integration and scale will keep producing exposure faster than reviews can remove it.


For practitioners

  • Test IGA resilience against real integration paths Map the systems, directories, and applications that must exchange identity data, then validate whether joins, movers, leavers, and exceptions still work when scale increases. Focus on failure points that create manual rework or orphaned entitlements.
  • Measure privilege creep as a programme health signal Track entitlement growth, role expansion, and unresolved exceptions between reviews so you can see whether access is accumulating faster than governance can correct it. Use those trends to prioritise cleanup before breach exposure compounds.
  • Separate control requirements from platform defaults Write down the non-negotiable control requirements for audit, ownership, and data residency, then compare the platform’s operating model against those needs instead of accepting the easiest workflow path.
  • Treat deployment architecture as a governance decision Decide whether on-premises, private cloud, or tenant-owned cloud best satisfies sovereignty and change-control obligations, then document the control boundary in the identity operating model.

Key takeaways

  • Identity governance fails most often as an operating-model problem, not a strategy problem.
  • When reviews, ownership, and scaling break down, access drift and privilege creep become the default risk state.
  • Practitioners should evaluate control requirements, deployment architecture, and integration depth together, not separately.

Standards & Framework Alignment

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

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4Access permissions need governance to prevent privilege creep and drift.
NIST Zero Trust (SP 800-207)GV.OC-01Zero Trust governance depends on control boundaries that stay current as access changes.
OWASP Non-Human Identity Top 10NHI-03Lifecycle and rotation discipline apply to non-human identities discussed in the article.

Document the control boundary and test whether identity governance still holds as environments and access paths change.


Key terms

  • Identity Governance and Administration: Identity Governance and Administration is the discipline of defining, approving, reviewing, and removing access so identity state matches business need. In practice, it spans entitlement lifecycle control, evidence collection, and enforcement across human users, service accounts, and increasingly autonomous systems.
  • Access Drift: Access drift is the gradual divergence between the access an identity has and the access it actually requires. It usually builds through delayed reviews, role expansion, exceptions, and weak ownership, creating exposure that appears normal until a breach or audit exposes the gap.
  • Privilege Creep: Privilege creep is the accumulation of permissions over time as users, workloads, or service accounts retain rights they no longer need. It is not a single misconfiguration but a governance failure that compounds when lifecycle controls, recertification, and removal processes lose pace with operational change.
  • Operating Model: An operating model is the practical way a governance programme is run, including decision ownership, workflow design, integrations, and control boundaries. For identity security, the operating model determines whether policy intent survives real execution across human, NHI, and AI-assisted processes.

Deepen your knowledge

Identity governance operating models and lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is stalling under integration or scale pressure, that course will help you ground the controls in a practical governance model.

This post draws on content published by Omada Identity: Where Identity Governance Stalls, Breach Risk Concentrates. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-05-25.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org