Cloud identity security is the practice of monitoring, governing, and protecting user accounts, service accounts, machine identities, and access privileges across cloud IAM systems (AWS IAM, Azure Entra ID, Google Cloud IAM), SaaS platforms, and federated identity providers. In multi-cloud environments, identity security requires cross-platform visibility that neither single-cloud tools nor traditional IAM governance systems provide.
Key takeaways
- Multi-cloud environments fragment identity across AWS IAM, Azure Entra ID, Google Cloud IAM, and dozens of SaaS platforms—each with its own auth events and audit logs that rarely correlate with each other
- Attackers exploit the visibility gaps between platforms, pivoting across cloud environments before any single tool detects the activity
- Cloud identity sprawl—service accounts, OAuth grants, machine identities, and dormant accounts—creates an under-monitored attack surface most organizations can’t fully inventory
- Effective cloud identity security requires five capabilities: unified identity inventory, least-privilege enforcement, behavioral detection across all identity sources, cross-platform correlation, and real-time response
- Zero trust verifies identity before granting access; ITDR detects when that verification has been circumvented—both are required for a complete cloud identity security program
On-premises identity security had a relatively tractable scope: Active Directory, VPN, and a defined user population. Multi-cloud environments shattered that model. Today, enterprise identity spans AWS IAM, Azure Entra ID, Google Cloud IAM, Okta, dozens of SaaS platforms, machine identities, service accounts, and federated trust relationships between all of them. Each platform produces its own authentication events and audit logs—most of which exist in isolation, never correlated with identity activity in adjacent systems. Identity threat detection and response (ITDR) closes this visibility gap, providing behavioral detection across cloud identity telemetry that single-platform tools can’t deliver. This page covers multi-cloud IAM fragmentation, cloud identity sprawl, and the five principles of cloud identity security that modern enterprises need.
What is multi-cloud IAM fragmentation?
Multi-cloud IAM fragmentation is the condition in which a single enterprise’s identity management is distributed across multiple cloud platforms, each with its own IAM system, permission model, authentication events, and audit logs—with no unified visibility layer across them.
In practice, this means:
- An AWS IAM role granted to a CI/CD pipeline is invisible to Azure Entra ID
- An Okta authentication event doesn’t automatically correlate with the Google Cloud Audit log entry from the same user in the same session
- A SaaS platform’s OAuth grant isn’t visible in any cloud IAM system, even if it accesses cloud-hosted data
This fragmentation isn’t a configuration failure—it’s a structural property of multi-cloud architecture. Cloud providers build IAM systems optimized for their own platforms. They’re not designed to talk to each other. The enterprise must build the unified visibility layer.
The security consequence: attackers exploit the gaps. An attacker who compromises an Okta account may pivot into AWS and Azure before any single platform’s monitoring tools detect the activity, because the cross-platform correlation that would reveal the attack doesn’t exist in any single tool.
| Platform | IAM system | Authentication logs | Audit log location |
|---|---|---|---|
|
AWS |
AWS IAM | CloudTrail (authentication events) | CloudTrail → SIEM/ITDR |
|
Azure |
Entra ID (formerly Azure ID) | Sign-in logs, audit logs | Entra ID → SIEM/ITDR |
|
Google Cloud |
Google Cloud IAM | Cloud Audit Logs | Cloud logging → SIEM/ITDR |
|
Identity provider |
Okta, Ping, Azure, Entra ID | Authentication events, session logs | IdP → SIEM/ITDR |
|
SaaS |
Platform-specific | OAuth grants, sign-in events | Varies—often no SIEM integration |
What is cloud identity sprawl, and why is it dangerous?
Cloud identity sprawl is the uncontrolled proliferation of human accounts, service accounts, machine identities, API keys, OAuth grants, and temporary credentials across cloud environments. It’s the identity analog to shadow IT: identities that exist, have privileges, and produce activity—but that no one is actively managing or monitoring.
The primary contributors to cloud identity sprawl:
- Service accounts: Created for application integrations, pipelines, and automation, then left running long after the use case ends. Service accounts frequently have broad permissions and are never audited with the rigor applied to human accounts.
- Temporary credentials: AWS instance roles, Google Cloud service account keys, and Azure managed identities issued for specific tasks and not revoked when the task completes.
- OAuth grants: Third-party applications granted access to cloud data through OAuth. These grants persist indefinitely unless explicitly revoked, and most organizations have no inventory of them.
- Federated identities: Identities that authenticate through one platform but access resources in another via trust relationships. The originating platform may have no visibility into the federated access.
- Dormant accounts: Former employee accounts, test accounts, and bot accounts that were never deprovisioned. Attackers specifically target dormant accounts because they have valid credentials and no active owner to notice suspicious activity.
What are the five principles of cloud identity security?
Effective cloud identity security in multi-cloud environments requires more than deploying each platform’s native IAM tools. These five principles provide the framework.
Principle 1: Unified identity inventory
You can’t protect identities you don’t know exist. Cloud identity security starts with a comprehensive inventory of all identity types across all platforms: human accounts, service accounts, machine identities, OAuth grants, API keys, and federated trust relationships. This inventory must be maintained continuously—cloud environments change constantly.
Principle 2: Least-privilege access enforcement
Over-permissioned identities are the path of least resistance for attackers who gain initial access. Enforce least privilege rigorously: no account should have permissions beyond what its current role requires. In cloud environments, this means regular access reviews, automated privilege drift detection, and just-in-time (JIT) access provisioning for sensitive operations.
Principle 3: Behavioral detection across all identity sources
IAM governance alone can’t detect when a valid, policy-compliant account is being abused. Cloud identity security requires behavioral monitoring that spans all identity sources—AWS CloudTrail, Azure Entra sign-in logs, Google Cloud Audit Logs, Okta authentication events, and SaaS platform logs—with per-identity behavioral baselines that can surface anomalies within any platform or across platforms.
Principle 4: Cross-platform identity correlation
The most dangerous multi-cloud attacks exploit the visibility gaps between platforms. Cloud identity security requires a detection layer that correlates identity events across cloud providers: an Okta authentication event that precedes anomalous AWS API activity from the same session should fire a single, correlated alert—not two isolated events that no one connects.
Principle 5: Response capability
Detection without response is incomplete. Cloud identity security requires the ability to act on detected threats in real time: account suspension, session revocation, OAuth grant removal, and privilege rollback across cloud platforms. Response capabilities must match the speed at which cloud identity attacks move—attackers operating with valid cloud credentials can exfiltrate data or establish persistence in minutes.
How does ITDR detect attacks across cloud identity systems?
ITDR detects cloud identity attacks by ingesting authentication and access telemetry from each cloud IAM platform and applying behavioral analytics that span the full multi-cloud identity estate.
Cloud-specific detection sources and signal types:
AWS CloudTrail:
- IAM role assumption anomalies (AssumeRole events from unexpected principals)
- API calls to sensitive services (S3, KMS, SecretsManager) from accounts with no history of accessing them
- New IAM user or role creation outside change windows
- Security group or IAM policy modifications
Azure Entra ID sign-in logs:
- Sign-ins from anonymous IP addresses or Tor exit nodes (Entra risk signals and behavioral baseline)
- Conditional access policy failures followed by successful bypass
- Service principal authentication anomalies
- MFA registration events, password changes, and access token issuance anomalies
Google Cloud Audit Logs:
- Service account key creation and usage anomalies
- IAM policy bindings added or removed outside normal change windows
- Unusual API calls to data services from identities with no history of that access
Cross-platform behavioral correlation:
- A single user account authenticating to Okta, then showing elevated API activity in AWS and Azure within the same session window—correlated across three telemetry sources
- Impossible travel detected across platforms: Okta sign-in from one geography, Azure sign-in from another within an impossible timeframe
For more on how ITDR detects specific identity attack techniques, see what are identity-based attacks? and how to detect MFA bypass attacks.
How does cloud identity security connect to zero trust?
Zero trust architecture and cloud identity security are deeply intertwined—but they operate at different layers.
Zero trust says: never assume trust based on network location; always verify identity before granting access. In cloud environments, zero trust is implemented through conditional access policies, device compliance requirements, least-privilege IAM policies, and continuous verification at every access request.
Cloud identity security—specifically ITDR—operates one layer deeper: it assumes that identity verification will sometimes be circumvented (credentials stolen, MFA bypassed, session tokens hijacked) and provides the behavioral detection layer that zero trust doesn’t include.
| Layer | Zero trust role | ITDR role |
|---|---|---|
|
Access verification |
Enforce strong authentication and conditional access | Detect when authentication was bypassed |
|
Privilege control |
Least-privilege IAM policies | Detect privilege escalation and policy violations |
|
Session management |
Session controls, token lifetime limits | Detect session token theft and replay |
|
Threat detection |
Not designed for active threat detection | Purpose-built behavioral detection across identity and telemetry |
Zero trust reduces the attack surface. ITDR detects breaches in the control. Both are required for a cloud identity security program that addresses the full threat model.
Expel’s take
Multi-cloud environments don’t just expand the identity attack surface—they fragment the visibility needed to monitor it. AWS CloudTrail, Azure Entra ID sign-in logs, and Google Cloud Audit Logs each capture a slice of identity activity, but none of them capture cross-platform pivots. An attacker who compromises an Okta account and moves into AWS and then Azure can operate in each platform’s blind spot relative to the others—the cross-platform correlation that would reveal the full attack chain doesn’t exist in any single tool’s native monitoring. That visibility has to be built deliberately, not assumed.
Frequently asked questions
How do you secure identities in multi-cloud environments?
Multi-cloud identity security requires five capabilities: a unified identity inventory across all platforms (AWS, Azure, Google Cloud, SaaS), least-privilege access enforcement, behavioral detection across all identity telemetry sources, cross-platform identity event correlation, and response capability to act on detected threats in real time.
What is cloud identity sprawl?
Cloud identity sprawl is the uncontrolled proliferation of service accounts, machine identities, OAuth grants, API keys, and dormant accounts across cloud environments. These identities often have broad permissions and no active owner—making them primary targets for attackers who gain initial cloud access.
What is multi-cloud IAM fragmentation?
Multi-cloud IAM fragmentation is the condition in which enterprise identity management is distributed across multiple cloud platforms—each with its own IAM system and audit logs—with no unified visibility layer. Attackers exploit the correlation gaps between platforms to pivot across cloud environments before any single platform’s tools detect the activity.
How does ITDR detect attacks across cloud identity systems?
ITDR ingests authentication and access telemetry from AWS CloudTrail, Azure Entra ID sign-in logs, Google Cloud Audit Logs, and SaaS platforms, and applies behavioral analytics that span the full multi-cloud identity estate. Cross-platform correlation surfaces attacks—like a single account authenticating through Okta and then showing elevated API activity across AWS and Azure—that no single platform’s native tools would detect.