TL;DR: Cloud IAM gets harder as access, provisioning, integrations, and compliance reporting spread across SaaS and departmental admins, according to Zluri. The core issue is not authentication alone but lifecycle control, visibility, and least-privilege enforcement across a decentralised identity surface.
At a glance
What this is: This is a Zluri analysis of four IAM challenge areas in cloud environments, with the key finding that decentralised SaaS and departmental administration weaken centralized access control.
Why it matters: It matters because IAM teams must govern human identities, service access, and application entitlements across the same operating model, or risk privilege creep, shadow apps, and compliance gaps.
By the numbers:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
👉 Read Zluri's article on the top IAM challenges in cloud environments
Context
Identity and access management in cloud environments is really about controlling who can access which applications, data, and administrative functions, then proving that control across a growing SaaS stack. As organisations decentralise application ownership, the IAM problem shifts from a single directory question to a governance question across human identities, delegated admins, and application entitlements.
Zluri’s article frames four recurring pressure points: centralized visibility, user lifecycle management, application integrations, and compliance reporting for third-party SaaS tools. Those are not separate problems in practice. They are the same governance gap showing up in different places when identity control no longer matches how work is distributed.
Key questions
Q: How should organisations govern SaaS access when teams can buy apps outside central IT?
A: Treat SaaS governance as an inventory and entitlement problem, not just a login problem. Central IT needs visibility into app ownership, usage, approvals, and direct-admin access so it can identify shadow apps, overprovisioning, and dormant entitlements. Without that control plane, decentralised purchasing turns into decentralised risk.
Q: Why does user lifecycle management break down in cloud IAM programmes?
A: It breaks down because joiner, mover, and leaver events often update the directory faster than they update each SaaS application. That leaves stale access behind after role changes or offboarding. The fix is not only faster tickets. It is automated entitlement changes across every app that can grant access independently.
Q: What do security teams get wrong about access request management?
A: They often optimise for speed and approval convenience instead of entitlement precision. If business requests are not translated into exact technical permissions, least privilege becomes vague and inconsistent. Good access request management defines the smallest workable role, records who approved it, and ensures the entitlement is revocable later.
Q: Who is accountable when former employees still have SaaS access after offboarding?
A: Accountability sits with the identity and application owners who control revocation, not with the directory alone. If offboarding stops at SSO or email, residual SaaS entitlements can outlive employment. Governance should require verification that every direct application account, token, or delegated admin path has been closed.
Technical breakdown
Centralized identity visibility in decentralized SaaS environments
A centralized IAM model assumes one control point can see identities, entitlements, and usage across the environment. In SaaS-heavy organisations, that assumption breaks because departments buy apps, admins create local access, and SSO only shows part of the picture. Centralised visibility is therefore not just a dashboard problem. It is an identity inventory problem that includes app ownership, login events, and unused access. Without that layer, IT cannot distinguish active entitlements from dormant sprawl, and finance cannot see where licenses and access are being wasted. Practical implication: build a single inventory that ties identities, apps, and entitlements together across SSO and direct app administration.
Practical implication: build a single inventory that ties identities, apps, and entitlements together across SSO and direct app administration.
User lifecycle management and offboarding gaps
User lifecycle management covers joiner, mover, and leaver events across the full access lifecycle. The technical challenge in cloud and SaaS environments is that provisioning and deprovisioning are often split between central IT, department admins, and application owners. That creates a gap between the directory state and the actual access state. If a former employee still has direct SaaS access after offboarding, the identity is no longer governed by the HR event that should have closed it. Mid-lifecycle role changes create a second failure mode because entitlements often lag behind job changes. Practical implication: automate role-based provisioning and deprovisioning across every app that can create its own local account.
Practical implication: automate role-based provisioning and deprovisioning across every app that can create its own local account.
Access request management and least privilege in practice
Access request management is where business language meets technical entitlements. Users ask for access in terms that are easy for managers to understand but hard to translate into exact permissions, groups, or roles. That translation gap is where least privilege usually fails. If approvals are broad, vague, or delayed, the result is over-provisioning, shadow app buying, and inconsistent access records. The technical problem is not simply speed. It is precision. IAM must map request intent to the smallest workable entitlement and keep that mapping auditable across SaaS apps, groups, and administrative roles. Practical implication: standardise request forms around technical entitlement models, not business phrases alone.
Practical implication: standardise request forms around technical entitlement models, not business phrases alone.
Threat narrative
Attacker objective: The objective is to exploit weak access governance to reach applications, data, or administrative functions that should no longer be reachable.
- Entry occurs when identity control is fragmented across SaaS apps, local admins, and incomplete SSO visibility, allowing unmanaged access paths to persist.
- Escalation follows when users, former employees, or over-privileged admins retain permissions beyond their legitimate need, often because lifecycle offboarding and recertification lag reality.
- Impact is broad access to sensitive systems, audit failure, shadow IT sprawl, and a larger blast radius when compromised identities or stale entitlements are abused.
Breaches seen in the wild
- Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Cloud IAM is now a lifecycle governance problem, not just an authentication problem. The article’s four challenges all point to the same failure: identity state no longer matches access state once SaaS ownership fragments across teams. That makes directory-centric control insufficient because the real governance unit is the entitlement across apps, admins, and request flows. Practitioners should treat IAM as continuous access governance, not a login layer.
Centralized visibility is the control plane that decides whether IAM is real or merely reported. If IT cannot see app usage, app ownership, and direct application access in one model, it cannot govern what it does not know exists. This is where shadow apps, duplicate licenses, and dormant entitlements become security and financial issues at the same time. The implication is that visibility must include lifecycle and usage data, not just directory sync.
Access request workflows fail when business intent is not translated into technical entitlement precision. The article shows how vague request language and delayed approvals push organisations away from least privilege and toward convenience-based access. That is not a user-experience problem alone; it is a governance design flaw that creates over-access by default. Practitioners should rework request logic around specific app entitlements and approval boundaries.
NHI governance becomes relevant the moment SaaS access is issued outside a human-only model. Application admins, service connectors, and delegated access paths behave like non-human identities even when the article discusses them as operational convenience. That means lifecycle discipline, visibility, and revocation must extend beyond employee offboarding into app-owned and system-owned access. The implication is that IAM and NHI governance are converging on the same control problem.
Identity blast radius grows when offboarding controls stop at the directory. The article makes clear that revoking email or core network access is not enough if SaaS entitlements remain active elsewhere. That leaves former employees, stale admins, or unused app accounts capable of reaching business data after the employment relationship has ended. Practitioners should view offboarding as an enterprise-wide entitlement closure event.
From our research:
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
- NHI Lifecycle Management Guide is the next resource to review if your programme needs to close lifecycle and revocation gaps across identities.
What this signals
Identity blast radius is the practical issue hiding inside cloud IAM sprawl. As apps, admins, and request flows fragment across teams, the reader’s programme needs a single entitlement map that can show what access exists, who owns it, and what can be revoked without delay.
The control gap will widen unless lifecycle events are linked to real application entitlements rather than only to directory records. That is why reviewers should look at offboarding, role change handling, and access recertification together instead of treating them as separate workstreams.
With 97% of NHIs carrying excessive privileges according to the Ultimate Guide to NHIs, the same over-access logic that hurts machine identities also shows up in SaaS admin sprawl and delegated access. The programme signal is clear: entitlement precision is now a baseline requirement, not an optimisation.
For practitioners
- Map every SaaS app to an accountable owner Create an inventory that links each application to its owner, the identity source, and the approval path used to grant access. This closes the gap between central IAM records and departmental administration, and it makes it possible to identify unused or unowned access before renewal or audit.
- Automate joiner-mover-leaver workflows across all app types Connect HR events, directory changes, and application entitlement changes so a role change or offboarding event triggers access updates in every system, not just the primary SSO or email stack. That is the difference between directory hygiene and actual lifecycle governance.
- Translate access requests into technical entitlements Replace vague business request text with defined roles, groups, or app-level permission sets. Require approvers to confirm the exact entitlement being granted, because least privilege fails when requests are interpreted loosely and implemented inconsistently.
- Review third-party SaaS access on a fixed cadence Run periodic access reviews for both human users and delegated application admins, with a separate check for inactive apps and stale permissions. This helps catch orphaned access that central IAM reports often miss.
- Close the offboarding gap beyond the core directory When an employee leaves, confirm revocation in every business app that held direct access, not only in the identity provider. Back up any needed application data before access is removed, then verify that no residual entitlements remain.
Key takeaways
- Cloud IAM fails when access governance is fragmented across SSO, SaaS admins, and department-owned apps.
- Lifecycle control matters as much as authentication because stale entitlements survive role changes and offboarding.
- Practitioners need precise request, review, and revocation workflows or least privilege becomes a policy statement without operational force.
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.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Cloud IAM sprawl creates unmanaged identity and entitlement exposure. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access enforcement sit at the core of the article's IAM challenges. |
| NIST Zero Trust (SP 800-207) | SP 800-207 | The article's visibility and access control gaps align with continuous verification needs. |
Inventory app-owned and delegated identities, then remove access paths that are not centrally governed.
Key terms
- Identity and Access Management: Identity and Access Management is the discipline of deciding who or what can reach systems, data, and administrative functions, then enforcing those decisions consistently. In cloud environments it must cover direct app access, delegated admins, lifecycle changes, and audit evidence, not only user login flows.
- User Lifecycle Management: User Lifecycle Management is the process of provisioning, changing, and removing access as people move through joiner, mover, and leaver stages. In mature programmes, it extends beyond directory updates to the actual removal or adjustment of entitlements across every application that can grant access independently.
- Least Privilege: Least Privilege means granting the minimum access needed for a task and nothing more. In practice, it depends on precise entitlement mapping, regular review, and timely revocation, because vague business requests and manual approvals often expand access beyond what the role truly needs.
- Shadow IT: Shadow IT is software or services adopted outside approved procurement and governance processes. In IAM terms it matters because unauthorised apps create hidden identities, hidden approvals, and hidden access paths that central controls may not see until audit, incident response, or renewal time.
Deepen your knowledge
NHI governance, agentic AI identity, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity strategy, access governance, or security operations, it is worth exploring.
This post draws on content published by Zluri: Security & Compliance Top 4 Identity and Access Management Challenges. Read the original.
Published by the NHIMG editorial team on 2025-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org