Cloud IAM maturity gaps are widening across hybrid estates

At a glance

What this is: Unosecur argues that cloud adoption often outpaces identity modernization, leaving hybrid estates managed by legacy access controls that cannot keep up with mobile users, federated services, and non-human identities.

Why it matters: IAM, IGA, PAM, and cloud security teams need to treat cloud IAM maturity as an operating model problem, because stale access controls increase friction, blind spots, and breach exposure across human and machine identities.

By the numbers:

• 52% of companies have moved most of their IT environments to the cloud, covering infrastructure, applications, data analytics and beyond.

👉 Read Unosecur's analysis of cloud IAM maturity gaps across hybrid estates

Context

Cloud IAM maturity is the gap between where workloads run and how identities are governed. In hybrid estates, the infrastructure may move first while access controls stay tied to on-prem directory assumptions, manual approvals, and slow review cycles that were built for a different operating model.

That mismatch becomes visible when organisations federate access to the cloud but do not modernise lifecycle controls, monitoring, or privilege scoping. The result is not just administrative friction. It is a governance gap across user accounts, service accounts, tokens, and AI-enabled access paths.

Unosecur's article frames this as a business and security problem at the same time: cloud adoption expands speed and complexity, but identity programmes that remain static create cost, delay, and exposure. The article is typical of organisations in transition, not of edge-case environments.

Key questions

Q: What breaks when cloud IAM modernization stops at federation?

A: Federation alone gives the appearance of cloud readiness without fixing entitlement sprawl, review cadence, or privilege persistence. The programme still depends on legacy assumptions about stable users, central directories, and slow-moving access change. In practice, that leaves hybrid estates exposed to stale permissions, weak observability, and machine identities that never enter the human governance workflow.

Q: Why do service accounts and tokens increase risk in hybrid cloud estates?

A: They increase risk because they can carry standing privilege, bypass human lifecycle controls, and persist long after the business need has changed. In hybrid environments, those identities often sit across multiple systems without clear ownership or expiry. That combination makes them easy to overlook and hard to contain once access has drifted beyond its original purpose.

Q: How do teams know if machine IAM is actually working?

A: Look for whether every machine identity has an accountable owner, a documented purpose, and short-lived access that can be revoked without breaking unrelated services. If access still depends on broad standing secrets or exceptions, the programme is governing credentials, not identities. Effective machine IAM reduces both ambiguity and privilege duration.

Q: When should organisations prioritise cloud IAM modernization over more point controls?

A: They should prioritise modernization when access has become fragmented across cloud, on-prem, and automated identities, because more point controls will not close a governance model gap. The priority should be a unified identity operating model that can govern human users and machine identities together. Otherwise, every new control simply layers more complexity onto the same weak foundation.

Technical breakdown

Why legacy IAM struggles in hybrid cloud environments

Traditional IAM was built around static networks, office-bound users, and directory-centric administration. Hybrid cloud environments break those assumptions because identities now span SaaS, public cloud, on-prem systems, contractors, APIs, and automated workloads. Legacy tooling often cannot maintain real-time state across those boundaries, so teams compensate with manual exceptions, federation shortcuts, and fragmented policy enforcement. That creates drift between who should have access and what access is actually active. The deeper issue is not just scale. It is that cloud IAM needs continuous context, not periodic reconciliation, to keep permissions aligned with current work patterns and infrastructure placement.

Practical implication: map where your current IAM stack still depends on static, on-prem review models and identify the hybrid paths that need continuous control.

Service accounts, tokens, and other non-human identities in cloud IAM

Cloud IAM maturity now depends on governing non-human identities as first-class subjects. Service accounts, API tokens, automated scripts, and AI tools can accumulate access just as quickly as people do, but they are often exempted from the same lifecycle discipline. That is where orphaned accounts, token sprawl, and standing privilege appear. In practice, these identities are difficult to see because they do not follow employee onboarding patterns and they often sit outside human access review processes. If the programme treats them as technical exceptions instead of governed identities, the attack surface expands quietly while oversight remains focused on human users.

Practical implication: inventory machine identities separately from human users and enforce ownership, expiry, and review logic for each non-human account class.

Just-in-Time access and real-time visibility in cloud estates

Just-in-Time access is one of the clearest markers of cloud IAM maturity because it reduces standing privilege and narrows exposure windows. But JIT only works when the organisation can see current entitlements, activate access quickly, and audit what happened during the session. Without that visibility, teams end up with federated access that still behaves like persistent access, especially in mixed cloud and on-prem environments. Real-time visibility also matters for compliance and incident response because it shows whether access was actually used, by whom, and for how long. In mature programmes, the control is not simply granting less access. It is making access temporary, observable, and revocable in the same operational flow.

Practical implication: align JIT workflows with audit trails and entitlement telemetry so temporary access is both usable and measurable.

Breaches seen in the wild

• Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
• Stryker Microsoft Intune Wiper Attack: Compromised Microsoft Intune credentials enable wiper attack wiping 200,000 Stryker devices.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud IAM maturity is not a cloud adoption milestone. It is the point at which identity controls match the speed, distribution, and mixed subject types of modern estates. When organisations move workloads but leave access governance anchored to on-prem assumptions, they create a structural mismatch that shows up first as friction and then as exposure. The practical implication is that modern IAM has to be evaluated by operating model fit, not by cloud usage alone.

Machine identities are now part of the core governance problem, not a side issue. The article correctly points to service accounts, tokens, and AI tools as identities that can quietly accumulate privilege in cloud environments. That matters because traditional identity programmes still centre human lifecycle events, while the riskiest access in hybrid estates often belongs to accounts no one remembers to review. The implication is that NHI governance has to sit inside mainstream IAM design, not beside it.

Identity blast radius becomes the more useful concept than access volume in hybrid estates. Once access spans multiple clouds, federated directories, and automated identities, the question is no longer how much access exists in total. It is how far a single stale entitlement, orphaned account, or mis-scoped federation path can move before it is detected. That shifts the governance focus from broad inventory to containment and ownership. Practitioners should measure how much damage one unmanaged identity can do.

Cloud IAM maturity is increasingly a control-synchronisation problem. The article shows the gap between federation, Just-in-Time access, auditability, and continuous oversight. Those controls are often deployed in isolation, but hybrid estates only become governable when they operate as one system of record for entitlement, usage, and revocation. The implication is that programme leaders should stop treating cloud, NHI, and human access as separate tracks when the attack surface does not separate them.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• More than 95% of infrastructure-as-a-service accounts use less than 3% of the entitlements they are granted, according to Gartner.
• Read next: NHI Lifecycle Management Guide

What this signals

Cloud IAM maturity will increasingly be judged by machine identity governance. The next phase of hybrid identity programmes will not be about whether access exists in the cloud, but whether service accounts, tokens, and AI tools are managed with the same ownership and lifecycle discipline as people. Organisations that keep treating those identities as exceptions will keep inheriting invisible privilege.

69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey. That direction of travel matters even for articles centred on cloud IAM because the boundary between human, machine, and autonomous access is already collapsing in practice. Programme leaders need governance models that can absorb that change without fragmenting controls by identity type.

For practitioners

• Inventory hybrid identity paths Map where access is still governed by on-prem directories, local cloud roles, and manual exceptions so you can see the real control boundary.
• Separate non-human identity ownership Assign a named owner, expiry expectation, and review cadence to service accounts, tokens, scripts, and API credentials that currently sit outside human access governance.
• Move privileged access to JIT Replace persistent admin rights in cloud estates with task-scoped elevation, session logging, and explicit approval paths for high-risk operations.
• Measure entitlement drift continuously Track which identities retain access after the original business need changes, especially across federated cloud accounts and orphaned machine identities.

Key takeaways

• Cloud IAM maturity depends on whether identity controls have caught up with hybrid operating models, not on whether workloads have moved to the cloud.
• Service accounts, tokens, and other non-human identities create hidden risk when they sit outside the same ownership and lifecycle discipline applied to people.
• The strongest practical response is a unified identity model that makes access temporary, observable, and revocable across cloud and on-prem environments.

Key terms

• Cloud IAM maturity: The extent to which identity and access controls are designed for cloud operating conditions rather than legacy data-centre assumptions. Mature cloud IAM aligns provisioning, visibility, lifecycle, and privilege management with dynamic workloads, distributed users, and non-human identities.
• Hybrid estate: A hybrid estate combines on-prem and cloud infrastructure under one operational model, usually with identities and access controls split across both. The security challenge is that policy, visibility, and review discipline often lag behind the speed of workload movement.
• 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.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• Practical examples of how legacy on-prem IAM creates friction in AWS and Azure estates
• The vendor's step-by-step rationale for treating service accounts and tokens as governed identities
• Specific ways Unosecur positions Just-in-Time access, audit trails, and unified visibility in hybrid environments
• The article's own business-value framing for IAM modernisation across security, compliance, and cost

👉 The full Unosecur blog covers hybrid access friction, machine identity risk, and modern IAM operating models.

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.