By NHI Mgmt Group Editorial TeamDomain: Governance & RiskSource: SaviyntPublished March 24, 2025

TL;DR: Traditional IAM is struggling to keep up with multicloud sprawl, AI adoption, and nearly 10 billion identities, according to Saviynt. The editorial issue is no longer whether IAM needs modernization, but whether identity governance can scale across human, machine, and AI-driven access without adding more blind spots.


At a glance

What this is: Saviynt argues that IAM modernization has become a business imperative because legacy models cannot secure modern multicloud identity sprawl.

Why it matters: For IAM, IGA, PAM, and security teams, the message is that identity control now affects resilience, compliance, and business agility across human and non-human access.

By the numbers:

👉 Read Saviynt's analysis of why modernizing IAM is a business imperative


Context

Identity security is now a business operating issue, not just a control-plane issue. In AI-heavy multicloud environments, legacy IAM designs break down because they assume smaller identity populations, slower change, and cleaner boundaries between human users, applications, and machine accounts.

That assumption no longer holds. As organisations expand AI adoption and automate more access workflows, the problem becomes governing identity at scale across human IAM, NHI, and emerging AI-driven access patterns without losing visibility or control.

For practitioners, the question is not whether identity management matters. The question is whether the current IAM programme can still provide lifecycle control, privilege governance, and auditability when access is increasingly dynamic and distributed.


Key questions

Q: How should security teams modernize IAM without losing control of NHI sprawl?

A: Start with identity inventory, actor-type classification, and lifecycle ownership. Human users, service accounts, APIs, and AI-connected identities should not sit in the same governance bucket. Modernization fails when teams automate the wrong processes before they understand which identities exist, who owns them, and how quickly access is revoked when conditions change.

Q: Why do hybrid and multi-cloud environments complicate IAM governance?

A: Because each platform expresses access differently, even when the same identity is involved. Teams end up with inconsistent entitlements, fragmented logs, and policy drift unless they standardise the decision layer. The hard problem is not authentication, but making authorization outcomes consistent across domains.

Q: What do organisations get wrong about automating identity governance?

A: They often automate the workflow without hardening the policy. That scales inconsistency, because the system will grant or certify access according to whatever rules exist, even if those rules are incomplete or too permissive. The real work is policy design, not simply workflow acceleration.

Q: Why do AI agent workflows need identity governance for oversight?

A: Because oversight only works when the organisation can prove who approved an action, what they saw, and why they intervened. Identity governance supplies the enforcement layer through authentication, authorisation, and audit evidence. Without that layer, the human is present but not operationally in control.


Technical breakdown

Why legacy IAM models struggle in multicloud identity sprawl

Traditional IAM platforms were designed around relatively stable user populations and centrally managed systems. Modern estates layer on SaaS, cloud workloads, APIs, service accounts, and automation, which creates far more identities than most programmes can inventory cleanly. Once identity sprawl crosses business units and cloud boundaries, visibility, entitlement review, and policy consistency become progressively harder to sustain. This is where IAM stops being a single control point and becomes an operating discipline spanning provisioning, access governance, and detection.

Practical implication: inventory identities by actor type and ownership so governance controls map to the actual estate, not the org chart.

How AI changes the identity governance problem

AI increases the pace and variability of access decisions, especially when systems consume data, trigger workflows, or influence authorisation paths. The core issue is not simply that AI is present, but that it often sits inside a chain of human, machine, and service identities that blurs accountability. That makes policy design harder, because the programme has to distinguish between who requested access, what identity executed it, and where privilege is actually exercised. Governance failure usually starts when these layers are collapsed into one generic access model.

Practical implication: separate AI-adjacent access paths from standard human IAM flows and assign explicit ownership for each delegated identity.

Why automation helps, but only with governance boundaries

Automation can remove manual delay from revocation, certification, and high-risk permission review, but it does not solve poor identity design. If entitlements are broad, poorly classified, or stale, automating the workflow simply accelerates bad governance. The stronger pattern is to use automation to enforce defined lifecycle rules and to surface exceptions that need human decision-making. That is especially important for privileged access, service identities, and AI-connected workflows where speed without boundary control increases blast radius.

Practical implication: automate revocation and review only after entitlement scope, approval logic, and exception handling are explicitly defined.


Threat narrative

Attacker objective: The attacker aims to exploit identity sprawl and governance gaps to move through trusted access paths without triggering timely control or review.

  1. Entry begins when sprawling identity estates create unmanaged access paths across cloud, SaaS, and automation layers. Escalation follows when excessive permissions, stale accounts, or weak lifecycle controls allow an identity to do more than intended. Impact arrives through data exposure, unauthorized action, or compliance failure that spreads across multiple environments.

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


NHI Mgmt Group analysis

IAM modernization is now an identity governance problem, not a tooling refresh. The article is right to frame modernization as business-critical, but the deeper issue is that legacy IAM assumptions no longer fit identity estates that span humans, workloads, APIs, and AI-connected systems. The operational risk is not only control weakness, it is programme mismatch. Practitioners should treat modernization as a redesign of identity boundaries, ownership, and lifecycle logic.

Identity explosion is the real forcing function behind modern IAM failure. When an enterprise approaches billions of identities, access review, certification, and exception handling can no longer rely on manual correlation. This is where NHI and human IAM converge: both depend on accurate inventory, entitlement scope, and revocation discipline. The implication is that identity governance must be built around actor type and lifecycle state, not around a single access model for everything.

Automation only works when the programme already knows what good looks like. Revoke-at-offboarding, high-risk permission review, and certification workflows improve speed, but they do not correct unclear privilege boundaries or poor identity ownership. If the organisation cannot distinguish a service account from a human approver, automation amplifies confusion. Practitioners should therefore modernise the underlying control model before scaling workflow automation.

AI-driven IAM will expose the weak spots in existing delegated access chains. The moment AI systems begin touching data, tools, and downstream services, the old assumption that access is requested and reviewed by a human becomes fragile. That does not mean every AI-enabled workflow is autonomous, but it does mean identity governance must understand where machine decision support ends and enforceable access begins. Security teams should map delegated access paths now, before AI makes those paths harder to untangle.

Zero Trust only becomes credible when identity governance can scale across all actors. The article’s business-agility framing is valid, but Zero Trust fails in practice if identity visibility, least privilege, and revocation lag behind business change. For practitioners, the lesson is that modern IAM is the control surface that makes Zero Trust operational rather than aspirational. If identity cannot be governed, trust cannot be continuously verified.

From our research:

  • 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
  • Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably prove what is actually in scope.
  • For a broader control baseline, see 52 NHI Breaches Analysis for the breach patterns that keep recurring across exposed identities.

What this signals

Identity modernisation should be planned as a control architecture change, not a product refresh. The organisations that succeed will be the ones that can reconcile identity inventory, entitlement ownership, and revocation speed across human and non-human actors. That is why the practical benchmark is whether IAM can keep pace with business change, not whether the stack has a new feature label.

With 96% of organisations storing secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, the governance gap is already operational. The next wave of IAM change has to connect identity, secrets, and workload access into one programme view, or teams will keep solving one leak while creating another.

As AI use expands, the boundary between human request, machine execution, and delegated access will keep getting harder to audit. Teams should prepare for more explicit identity tiering, tighter privilege segmentation, and better evidence trails before AI-enabled workflows become default in production.


For practitioners

  • Inventory identities by actor type Build a current inventory that separates human users, applications, service accounts, APIs, and AI-connected identities. Use ownership, privilege level, and lifecycle state so review and remediation can be assigned without ambiguity.
  • Tighten lifecycle controls for non-human access Require explicit provisioning, revocation, and rotation ownership for every non-human identity. Prioritise service accounts and API keys that persist across multiple environments or are shared by automation workflows.
  • Automate high-risk review paths first Use automation for offboarding, privileged permission flags, and certification queues where the control decision is already well-defined. Keep human approval for edge cases until entitlement scope and exception handling are stable.
  • Map AI-adjacent access chains before scaling use cases Document where AI systems read data, call tools, or trigger downstream services, then identify the identities that actually execute those actions. This helps separate delegated access from true authorisation boundaries.
  • Align IAM metrics to business outcomes Track review completion, revocation lag, and privileged access exposure alongside uptime, user friction, and audit findings. That makes IAM modernization measurable as resilience and efficiency, not just compliance.

Key takeaways

  • Legacy IAM is no longer sufficient for multicloud, AI-heavy identity estates because it cannot keep visibility and governance aligned at scale.
  • The biggest operational risk is not identity volume alone, but the combination of excessive privilege, weak lifecycle control, and fragmented ownership.
  • Modernization should begin with actor-type inventory and governance boundaries, then use automation to enforce rather than guess the right controls.

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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-1Identity inventory and access governance are central to the article's modernization theme.
NIST SP 800-53 Rev 5AC-2Account management directly fits offboarding, certification, and identity lifecycle control.
NIST Zero Trust (SP 800-207)Zero Trust is explicitly cited as a future direction for modern IAM.
OWASP Non-Human Identity Top 10NHI-03The article's NHI exposure concerns map to identity lifecycle and privilege governance gaps.
NIST SP 800-63SP 800-63CFederation and identity assurance matter where IAM spans multiple cloud and SaaS boundaries.

Use Zero Trust principles to move identity checks closer to each access decision and reduce implicit trust.


Key terms

  • Identity Sprawl: Identity sprawl is the uncontrolled growth of identities, entitlements, and credentials across an environment. For NHIs, it usually appears when automation creates accounts faster than governance teams can inventory, review, and remove them. The result is hidden access, weak accountability, and a wider attack surface.
  • Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
  • Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
  • Delegated Access Chain: A delegated access chain is the sequence of permissions that lets one identity act through another, such as an AI agent using a token to call a tool that reaches sensitive data. These chains are hard to see because the original grant and the final action may live in different control planes.

What's in the full article

Saviynt's full article covers the operational detail this post intentionally leaves for the source:

  • How the vendor frames IAM modernization as a business enabler across security, compliance, and user experience
  • Specific examples of automation use cases for offboarding, access certification, and high-risk permission review
  • The vendor's own view of AI-driven IAM, machine identity management, and Zero Trust alignment
  • The partnership context with PwC Canada and how the vendor positions implementation support

👉 Saviynt's full article covers the business case, operating model shifts, and implementation themes in more detail.

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