IAM and IGA are converging around hybrid identity risk

At a glance

What this is: This is an analysis of how IAM and IGA must adapt to hybrid identity sprawl, with the key finding that machine identities and overprivileged access now drive much of the risk.

Why it matters: It matters because IAM, IGA, PAM, and lifecycle teams now have to govern human and non-human identities together across cloud and SaaS estates, not as separate problems.

By the numbers:

• Overprivileged service accounts triggered 46.4% of cloud security alerts in H2 2024 and enabled 62.2% of lateral movement incidents.

👉 Read Bravura Security's analysis of IAM, IGA, and hybrid identity risk

Context

IAM and IGA are often discussed together, but they do different jobs. IAM grants and governs access, while IGA provides the audit and certification layer that checks whether access still matches policy. In hybrid environments, that distinction becomes more important because identity is now spread across AWS, Azure, Google Cloud, SaaS, on-premises systems, service accounts, APIs, and workloads.

The primary governance gap is identity sprawl. When organisations cannot maintain a consistent view of who and what has access, least privilege becomes a theory rather than an operating control. That is why the article's focus on machine identities, lifecycle automation, and Zero Trust belongs in the same conversation as human access governance, not alongside it as a separate programme.

Key questions

Q: How should security teams govern access across multi-cloud and SaaS environments?

A: Security teams should govern access with a single entitlement view that spans cloud platforms, SaaS applications, on-premises systems, and machine identities. Native controls in each platform are necessary, but they do not provide a complete governance picture. The practical goal is to certify access across the full estate, not only inside one cloud.

Q: Why do overprivileged service accounts create such persistent cloud risk?

A: Overprivileged service accounts create persistent risk because they combine standing access, weak ownership, and broad lateral movement potential. When those accounts are not tightly reviewed, an attacker or insider can move from a small foothold to broader cloud access. The issue is not only permission size, but how long that privilege remains valid.

Q: What breaks when IGA is not tightly connected to IAM?

A: When IGA is disconnected from IAM, organisations can provision access correctly and still fail governance. Access may remain approved long after the role changed, the workload moved, or the account became unnecessary. That creates a gap between policy and reality, which is where orphaned accounts and excess permissions survive.

Q: How can teams reduce identity sprawl without losing operational speed?

A: Teams should automate provisioning and revocation, but only within a governance model that also includes periodic review, ownership assignment, and exception handling. Speed without lifecycle control creates more drift, not less. The balance is fast execution with evidence that access still serves a current business purpose.

Technical breakdown

Multi-cloud identity sprawl and fragmented entitlement control

Multi-cloud identity sprawl happens when access is distributed across clouds, SaaS platforms, and on-premises systems with different native control planes. IAM can enforce permissions inside each platform, but it does not automatically provide a unified view of entitlement risk across them. CIEM exists to close that gap by discovering excessive permissions and cross-cloud drift. Without that visibility, teams end up managing islands of control rather than a governed identity estate.

Practical implication: build a cross-cloud entitlement inventory before treating least privilege as enforceable at scale.

Why IGA is the audit layer for IAM

IGA sits above access provisioning and is responsible for review, certification, attestation, and policy exception reporting. It does not replace IAM; it checks whether IAM outcomes still match business policy, compliance obligations, and role design. In practice, that means surfacing orphaned accounts, excessive access, and stale entitlements after joiner-mover-leaver events or access changes. In Zero Trust environments, this audit layer becomes the evidence that continuous verification is actually working.

Practical implication: use IGA to verify access outcomes, not just to record approvals.

Machine identities need lifecycle governance, not just secret storage

Service accounts, APIs, workload identities, and other machine identities behave differently from human users because they can be provisioned at scale and forgotten just as quickly. The risk is not only exposed credentials, but also long-lived privilege, unclear ownership, and broken offboarding. IAM for machine identities must therefore cover provisioning, ownership, rotation, revocation, and periodic review. If the lifecycle is not explicit, the identity becomes an unmanaged access path rather than a governed account.

Practical implication: tie every machine identity to an owner, a purpose, and a revocation path.

Threat narrative

Attacker objective: The attacker aims to turn fragmented identity governance into broad access, enabling lateral movement, persistence, and data exposure across cloud and SaaS estates.

1. Entry occurs through identity sprawl, where unmanaged SaaS apps, cloud entitlements, or service accounts expand the attack surface beyond the corporate perimeter.
2. Escalation follows overprivileged access, which allows an attacker or malicious insider to move from a low-value identity to broader permissions and lateral movement opportunities.
3. Impact is achieved when excess privilege, orphaned accounts, or weak lifecycle governance expose data, enable cloud compromise, or let attackers persist across environments.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Identity sprawl is now the primary governance failure, not a side effect of cloud growth. The article shows that IAM and IGA are no longer confined to one domain or one platform. When access is split across AWS, Azure, Google Cloud, SaaS, on-premises systems, and machine identities, the governing assumption of a bounded identity estate no longer holds. Practitioners must treat inventory and entitlement visibility as the first control, not the last report.

IGA is the control plane that proves IAM is still aligned to policy. IAM can create and enforce access, but IGA determines whether that access still deserves to exist. That distinction matters when lifecycle events, role changes, or cloud drift make previously approved access inappropriate. The implication is straightforward: organisations that lack a credible audit layer do not really know whether least privilege is active or merely documented.

Overprivileged service accounts expose the real failure mode in hybrid identity programmes. The control gap is not just excess permissions. It is the combination of unclear ownership, weak offboarding, and long-lived access paths that survive operational change. Google Cloud's data on alert volume and lateral movement shows why machine identities cannot be treated as low-friction technical accounts. Practitioners should expect service accounts to be governed like any other privileged asset.

Multi-cloud governance requires unified policy, not duplicated platform controls. Native IAM in each cloud is necessary but insufficient because it fragments the enforcement model. The more estates rely on isolated controls, the harder it becomes to certify access consistently or to identify where privilege has drifted. The field is moving toward cross-platform governance because identity risk now follows the workload, not the perimeter.

Lifecycle automation is the only scalable answer to identity growth, but it must be paired with review discipline. Automated provisioning and revocation reduce manual error, yet automation without recertification simply moves speed without improving governance. The article's strongest signal is that identity programmes need both execution and evidence. Practitioners should align lifecycle automation with periodic attestation so access remains defensible over time.

From our research:

• 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to the 2024 Non-Human Identity Security Report.
• Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, which underscores how immature the control environment still is.
• For the broader lifecycle view, read Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for provisioning, rotation, and offboarding patterns that teams can operationalise.

What this signals

Identity sprawl is moving from an architectural nuisance to a governance signal. As cloud estates, SaaS applications, and machine identities multiply, teams need a repeatable way to prove who has access, why it exists, and when it should be removed. The mature response is to treat entitlement drift as a standing operational metric, not an annual audit finding.

With 35.6% of organisations citing consistent access across hybrid and multi-cloud environments as their top NHI challenge, the control problem is now clearly cross-platform rather than cloud-specific. That means programme owners should expect failures in inventory, review, and offboarding to show up first as identity fragmentation, not as a single compromised account.

Lifecycle discipline will separate controlled identity programmes from reactive ones. Provisioning, review, rotation, and revocation have to be tied together across human and non-human identities, because one weak link leaves the whole estate exposed. Teams that still manage machine identities as tactical exceptions will struggle to sustain Zero Trust in practice.

For practitioners

• Build a unified identity inventory across cloud and SaaS estates Map human accounts, service accounts, API credentials, and workload identities into one entitlement view so you can see where access is duplicated, orphaned, or excessive across AWS, Azure, Google Cloud, and critical SaaS platforms.
• Separate IAM execution from IGA certification Use IAM to provision and enforce access, then use IGA to review whether that access still matches role, policy, and compliance requirements after joiner-mover-leaver events or cloud changes.
• Treat service accounts as governed privileged assets Assign every machine identity an owner, purpose, expiry or review date, and a revocation path. Include service-account permissions in privileged access reviews instead of leaving them outside the certification cycle.
• Close the offboarding gap for non-human identities Verify that dormant accounts, expired SaaS integrations, and orphaned credentials are removed when systems, vendors, or workloads change. Identity risk often persists because offboarding is incomplete rather than because provisioning was incorrect.

Key takeaways

• Hybrid identity risk is now driven by sprawl, not just by weak authentication.
• Overprivileged service accounts remain a major lateral movement path, which makes lifecycle control and entitlement review essential.
• Practitioners need unified governance across IAM and IGA if they want least privilege to hold across cloud, SaaS, and machine identities.

Key terms

• Identity sprawl: Identity sprawl is the uncontrolled growth of human and non-human accounts across clouds, SaaS platforms, and internal systems. It becomes a security problem when access is distributed faster than governance can inventory, review, and revoke it, leaving teams unable to explain who or what still has permission.
• Identity Governance and Administration: Identity Governance and Administration is the control layer that reviews, certifies, and audits access across identity systems. It sits above provisioning to confirm that permissions still match policy, role, and compliance requirements after business or technical change. In practice, it is how organisations prove access still belongs.
• Service account: A service account is a non-human identity used by applications, scripts, workloads, or integrations to access systems programmatically. Unlike a person, it may have no natural offboarding event, so ownership, rotation, and revocation must be deliberately governed to prevent persistent, unattributed access.
• Zero Trust Architecture: Zero Trust Architecture is an assume-breach model that requires explicit, continuous verification before access is granted or maintained. For identity programmes, it means access cannot be treated as permanently trusted once issued, and every entitlement must remain justified by current context and policy.

Deepen your knowledge

Identity sprawl, machine identity governance, and lifecycle automation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to unify IAM and IGA across cloud and SaaS estates, it is worth exploring.

This post draws on content published by Bravura Security: mitigating identity-related access risks in hybrid and multi-cloud environments. Read the original.