Why do cloud migrations often increase IAM risk instead of reducing it?

Why Cloud Migrations Raise IAM Risk

Cloud migration usually increases IAM exposure because identity controls lag behind infrastructure movement. Teams often lift and shift workloads into a new environment while leaving behind legacy directories, manual approval chains, and static secrets that were already fragile. That creates a gap between the speed of deployment and the maturity of access governance, especially when non-human identities multiply faster than human accounts. The result is more standing privilege, less clarity over who or what is acting, and a larger attack surface for lateral movement and privilege escalation, as seen in patterns discussed in the Top 10 NHI Issues and the NIST Cybersecurity Framework 2.0. In the 2024 Non-Human Identity Security Report, 88.5% of organisations said NHI practices lag human IAM, which explains why migration frequently widens risk before it reduces it. In practice, many security teams discover the weakest identity paths only after a cloud incident has already exposed them rather than through controlled migration planning.

How It Works in Practice

A migration changes how access is issued, checked, and revoked. In on-prem environments, identities are often anchored to fixed network boundaries and slower release cycles. In cloud environments, workloads, pipelines, containers, and services need machine-speed access that does not fit long approval queues or permanent credentials. That is why current guidance suggests shifting from static RBAC alone toward workload identity, short-lived tokens, and runtime policy checks. The operational model should favour JIT credential issuance, ephemeral secrets, and a clear distinction between human users and NHI workloads. For cloud infrastructure, the identity primitive should be what the workload proves about itself, not a password copied into a pipeline or a secret stored in a vault forever. This is consistent with the risk patterns in the Azure Key Vault privilege escalation exposure analysis and the broader direction in OWASP NHI Top 10. Practical steps include:

• Replace shared secrets with workload identity tokens that expire quickly.
• Use policy evaluation at request time instead of broad, pre-granted roles.
• Separate human admin access from service-to-service access.
• Log entitlement changes and token use so privilege drift is visible.
• Align cloud control planes to least privilege before expanding production scope.

For teams formalising the control model, the NIST Cybersecurity Framework 2.0 provides a useful baseline for governance, while the migration risk remains highest when hybrid estates keep old secrets alive inside new automation paths. These controls tend to break down when legacy applications cannot support federated workload identity because teams fall back to long-lived service accounts.

Common Variations and Edge Cases

Tighter identity control often increases delivery overhead, so organisations must balance migration speed against assurance. That tradeoff becomes sharper in hybrid estates, multi-cloud estates, and regulated environments where the same workload may need different access patterns across platforms. Best practice is evolving here: there is no universal standard for every cloud-to-cloud migration, but the direction is clear toward shorter credential lifetimes, stronger provenance, and continuous verification. The 230M AWS environment compromise and the Snowflake breach both underscore how quickly identity mistakes become scale events once cloud access is centralised or over-broadened. For some teams, the hardest edge case is not migration itself but the coexistence of human IAM, PAM, and NHI controls that were never designed to work together. Where agents or automation are introduced, the problem becomes even more dynamic because access must follow intent and task context, not just role membership. The current guidance suggests treating migration as an identity redesign exercise, not a lift-and-shift of permissions. In highly fragmented environments, these controls lose effectiveness when teams cannot inventory all secrets, service accounts, and cross-account trust relationships before cutover.

Related resources from NHI Mgmt Group

• Why do Salesforce integrations increase NHI risk?
• How should teams reduce over-privilege in cloud IAM for non-human identities?
• When does standing privilege create unacceptable cloud risk?
• When does NHI sprawl become an operational risk for IAM teams?