TL;DR: Unosecur says a survey of IT decision-makers found 52% of companies have moved most of their IT environments to the cloud, yet many still govern user and machine access with on-premises IAM patterns that create friction, risk, and cost. Cloud migration without identity modernization leaves real-time access control, visibility, and lifecycle governance behind.
At a glance
What this is: Unosecur argues that cloud adoption has outpaced IAM maturity, leaving many organisations with legacy access controls that do not fit modern cloud operations or non-human identity sprawl.
Why it matters: IAM, PAM, and cloud security teams need to close the gap between where workloads run and how identities are governed, or they will keep accumulating avoidable access risk.
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 and hidden access risk
Context
Cloud IAM is the set of access controls, identity lifecycle processes, and privilege decisions that govern who and what can reach cloud resources. The governance problem is that many organisations have moved workloads to the cloud faster than they have modernised the identity systems that control those workloads.
This leaves a mismatch between cloud operating speed and legacy IAM design. In practice, that mismatch shows up as manual approvals, limited visibility, federated access without continuous control, and weak governance over service accounts, tokens, bots, APIs, and AI tools.
The article frames this as a maturity gap rather than a technology gap. That is typical of many cloud programmes: infrastructure changes first, then identity controls lag behind and quietly become the constraint.
Key questions
Q: What breaks when cloud IAM is still run like on-premises IAM?
A: Legacy IAM breaks when it is asked to govern cloud workloads at cloud speed. The result is manual access handling, weak visibility, slow provisioning, and privilege that outlives the workload or project it was created for. That gap increases attack surface and makes audit and response work harder.
Q: Why do non-human identities increase privileged access risk in cloud environments?
A: Non-human identities increase risk because they often outnumber humans, operate continuously, and depend on credentials that are easier to reuse than to govern. When those identities retain broad or persistent access, attackers gain a faster path to cloud services, data stores, and automation layers. The risk is structural, not just operational.
Q: How do teams know cloud IAM maturity is actually improving?
A: Look for shorter access lifecycles, fewer standing privileges, better visibility across human and non-human identities, and faster onboarding and offboarding. If access still depends on quarterly reviews and manual exceptions, the operating model has not really changed.
Q: Should organisations prioritise JIT access or identity federation first?
A: Prioritise the control that reduces standing privilege first. Federation can simplify authentication, but it does not remove excess access or improve runtime governance. JIT access changes the risk posture more directly because it limits how long elevated permissions exist.
Technical breakdown
Why legacy IAM breaks under cloud operating speed
Traditional IAM was designed for slower, office-bound, data-centre-era environments. It relies on rigid directory structures, manual processes, and access patterns that assume stable users and static applications. Cloud environments change that model. Workloads move faster, identities are more numerous, and access decisions need to reflect ephemeral infrastructure, distributed teams, and shorter operational windows. When old IAM patterns are stretched into cloud use cases, the result is delay, blind spots, and excessive privilege that nobody can see in time.
Practical implication: map every cloud access path that still depends on on-premises approval, directory, or review processes.
How non-human identities expose cloud IAM gaps
Cloud environments expand the identity population beyond employees and contractors to include service accounts, APIs, scripts, and AI tools. These non-human identities often accumulate access without the same governance discipline applied to people, especially when teams federate access but do not continuously monitor usage or offboard stale credentials. That creates token sprawl, orphaned service accounts, and permissions that outlive the workload or integration they were created for. In cloud IAM, the identity estate is not just larger. It is more dynamic and easier to lose track of.
Practical implication: inventory non-human identities separately from human users and treat their lifecycle as a first-class governance problem.
Why Just-in-Time access matters in cloud IAM maturity
Just-in-Time access reduces standing privilege by granting permissions only when a task requires them. In cloud settings, that matters because access scope can be tightly aligned to workload, time, and purpose instead of being left permanently attached to a role or account. Without JIT, teams rely on broad, persistent access that increases attack surface and complicates audits. With it, the identity system reflects how cloud operations actually work, with shorter-lived trust and less permanent exposure.
Practical implication: replace persistent elevated access with task-scoped issuance for administrators, contractors, and privileged non-human accounts.
Threat narrative
Attacker objective: The attacker aims to turn forgotten, over-permissioned cloud identities into durable access paths that can be abused without immediate detection.
- Entry occurs when cloud workloads or integrations inherit access through legacy identity patterns rather than governed cloud-native controls.
- Credential or token exposure becomes easier when service accounts, APIs, and AI tools are left with excessive or stale permissions.
- Privilege misuse and lateral movement follow when standing access is available long after the original business need has passed.
- Impact is broader attack surface, slower containment, and higher breach cost because the identity layer no longer reflects cloud reality.
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 now a governance problem, not an infrastructure problem. The article describes a common enterprise pattern: workloads move to the cloud faster than identity control models change. That gap matters because access management does not become cloud-ready simply by federating logins or shifting infrastructure. The programme has to be redesigned around cloud operating speed, not legacy directory assumptions. The practitioner conclusion is simple: cloud adoption without identity redesign leaves the hardest part unfinished.
Non-human identity sprawl is where cloud IAM debt becomes visible. The article correctly points to service accounts, APIs, scripts, and AI tools as the identities most likely to accumulate excess access. That is where on-premises governance patterns fail first, because those identities are often created for convenience and then forgotten. Cloud identity blast radius: the more identities you cannot continuously account for, the more permanent access you are actually carrying. Practitioners should treat machine and automation identities as a separate governance domain, not an edge case.
Federation alone does not equal cloud IAM maturity. Many organisations mistake access federation for access governance, but the two are not the same. Federation may move authentication, yet it does not solve continuous visibility, privilege scope, or lifecycle offboarding. That is why the article's concern is not cloud migration itself but the false comfort of partial modernisation. The implication is that cloud IAM must be judged by control quality, not by whether a login route reaches the cloud.
Just-in-Time access is a maturity signal because it shrinks the standing-trust window. The article's emphasis on JIT reflects the right direction of travel: cloud identity systems should issue privilege for a task, then withdraw it. That approach aligns access with real operational need and reduces the amount of exposed privilege sitting idle. Practitioners should use this as a benchmark for whether their IAM stack is behaving like a cloud control plane or merely a migrated directory.
Access review cadences are a poor substitute for cloud-era lifecycle control. Quarterly review habits may satisfy process expectations, but they do not provide the runtime visibility needed to govern dynamic cloud identities. The article's strongest signal is that identity governance now has to move closer to issuance, usage, and revocation. Practitioners who still depend on retrospective review alone are managing cloud risk with a delayed control loop.
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.
- Read next: NHI Lifecycle Management Guide
What this signals
Cloud identity maturity now depends on shrinking the gap between issuance and use. If access is still granted far in advance of need, the cloud simply concentrates old IAM weaknesses at a larger scale. Practitioners should watch whether approval, provisioning, and revocation are becoming shorter-cycle controls rather than separate administrative events.
Cloud identity blast radius: the practical measure of maturity is not how many systems are federated, but how much standing access remains after federation is done. When service accounts and automation retain broad privileges, cloud adoption increases the consequences of every missed lifecycle step.
The direction of travel is clear: cloud IAM programmes will be judged less on directory integration and more on whether they can govern human and non-human access continuously across cloud-native environments.
For practitioners
- Audit cloud identities by control model Identify where cloud workloads, applications, and data still depend on on-premises IAM, then document the exact access paths that have not been reworked for cloud operations.
- Separate non-human identity governance Build a distinct inventory for service accounts, APIs, scripts, tokens, and AI tools so lifecycle ownership, privilege scope, and offboarding can be tracked independently from human users.
- Replace standing access with task-scoped access Use Just-in-Time access for administrators, contractors, and privileged machine identities so elevated permissions exist only for the duration of the task.
- Prioritise the riskiest identity debt first Start with old service accounts, over-permissioned roles, and outdated policies because those are the identities most likely to create hidden cloud exposure.
Key takeaways
- Cloud migration without identity modernization leaves access governance lagging behind the operating model, which creates avoidable risk and friction.
- The biggest blind spots sit in non-human identities, especially service accounts and automation that retain privilege after their original use case changes.
- Cloud IAM maturity improves when teams reduce standing access, increase visibility, and move governance closer to issuance and revocation.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article focuses on excessive cloud access and standing privilege for machine identities. |
| NHI-07 — Long-Lived Secrets | Token sprawl and stale machine access are central risks in the article's cloud IAM gap. | |
| NHI-01 — Improper Offboarding | The article highlights orphaned service accounts and access that remains after its use case ends. | |
| Recommendation — Reduce overprivileged cloud accounts by scoping permissions to the minimum runtime need. Rotate and expire machine credentials so cloud access does not persist beyond operational need. Offboard cloud service accounts and automation identities as soon as the workload or integration ends. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Cloud IAM maturity depends on managing credential lifecycle for both human and non-human access. |
| Recommendation — Apply authenticator lifecycle controls to cloud credentials, tokens, and service account secrets. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about access scope and entitlement governance in cloud environments. |
| Recommendation — Continuously review cloud entitlements and remove excess permissions from human and machine identities. | ||
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.
- 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.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
What's in the full article
Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:
- Survey framing and environment mix behind the 52% cloud adoption figure
- Examples of cloud IAM patchwork patterns such as on-prem Active Directory with cloud federation
- Business-value discussion around onboarding speed, audit effort, and access visibility
- A practical modernization path that starts with old service accounts and over-permissioned roles
👉 Unosecur's full post covers cloud IAM modernization, non-human identity risk, and JIT access 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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org