Why IAM Auditing Is Broken in Multi-Cloud
Most organizations running AWS, Azure, and GCP have three separate IAM models, three separate audit log formats, three separate native toolsets, and (in practice) three separate teams or workflows responsible for each. The result is that IAM auditing, which should be a unified exercise in understanding who can do what and at what risk, becomes a fragmented collection of point-in-time exports that nobody has the bandwidth to properly correlate.
The tool sprawl compounds this. A typical security team at a mid-sized organization might be running a CSPM for posture, a separate CIEM tool for identity risk, native cloud tools for individual account analysis, and a JIT solution for privileged access, with none of them sharing a data model or producing findings that map to the same identity. The result is multiple priority lists, no shared context, and an audit exercise that takes weeks but still misses the gaps that matter most.
The consequence shows up in standing privilege. Long-lived admin credentials that exist because nobody was sure it was safe to remove them, shared database passwords that have never been rotated, hardcoded API keys in CI/CD pipelines that are technically owned by a developer who left six months ago, and AI coding agents operating with broad cloud credentials that were never designed for agent-initiated sessions. These are not exotic attack vectors. They are the access patterns that show up in cloud incident post-mortems, consistently and repeatedly.
Auditing IAM permissions in a multi-cloud environment is not simply a question of ‘who has access.’ It is a question of effective permissions; what a given identity can actually do after trust boundaries, SCPs, permission boundaries, and deny rules are resolved. It is a question of cross-cloud blast radius; what an attacker can reach if a single identity is compromised across your entire environment. And it is a question of coverage; whether your audit touches humans, service accounts, federated identities, non-human identities, and AI coding agents, or only the human identities that are easiest to enumerate.
This guide covers all of it: the structural differences between IAM models that make multi-cloud auditing genuinely hard, what a complete IAM audit needs to cover, a step-by-step method for doing it, the pitfalls that cause audits to produce false confidence, and what the path from audit to zero standing privilege actually looks like.
The Core Problem
Most IAM audits answer ‘who has access.’ A complete IAM audit answers ‘what can they actually do, what could an attacker reach if they were compromised, and which of those identities have permissions they haven’t used in 90 days?’ Those are three very different questions. And most teams are only answering the first one.
The Multi-Cloud IAM Challenge: Why Each Cloud Is Different
The reason multi-cloud IAM auditing is hard is not organizational; it is architectural. AWS, Azure, and GCP each built their identity and access models independently, with different primitives, different scoping hierarchies, and different mental models for how permissions are evaluated.
Understanding these differences is not a prerequisite for using each cloud, but it is a prerequisite for auditing them in a way that produces comparable, trustworthy findings across all three.
Three Models, Three Mental Frameworks
AWS IAM is policy-centric. Permissions are expressed as JSON policy documents attached to identities (users, roles, groups) or resources. The evaluation logic is nuanced: an explicit deny always wins, permissions from multiple attached policies are unioned, and organization-level Service Control Policies (SCPs) set a ceiling that account-level policies cannot exceed. AWS roles are assumed when a principal calls AssumeRole, receives temporary credentials from STS, and those credentials carry the permissions of the assumed role for the duration of the session. For a deeper look at how AWS CloudTrail fits into the audit picture, see our guide.
The key audit challenge on AWS is that effective permissions are not obvious from looking at a single policy attachment; you have to resolve the full policy evaluation logic, including resource-based policies, permission boundaries, and SCPs, to know what an identity can actually do.
Azure RBAC is assignment-centric. A role definition describes a set of allowed actions; a role assignment binds a principal to a role at a specific scope: management group, subscription, resource group, or individual resource. Permissions inherit downward through the scope hierarchy: a role assigned at the subscription level applies to every resource group and resource within it. The audit challenge on Azure is scope inheritance. An identity with a Contributor role on a management group has effective contributor permissions across every subscription and resource group beneath it, which is not always obvious when reviewing individual resource assignments.
GCP IAM is binding-centric. Each IAM binding links a member (the identity), a role (a set of permissions), and a resource. Permissions also inherit downward through the resource hierarchy: organization → folder → project → resource. GCP’s model is arguably the cleanest of the three, but it has its own audit complexity: IAM conditions can make bindings conditional on attributes like time of day, resource tags, or originating IP, which means a binding that appears permissive at first glance may be more restricted in practice, or the condition may have been configured incorrectly and be less restrictive than intended.
These structural differences mean that a multi-cloud IAM audit cannot simply apply the same methodology to each cloud and expect comparable results. The scoping model, the permission evaluation logic, the meaning of ‘effective permissions,’ and the native audit tooling all differ. Which is exactly why a unified audit approach requires either deep expertise in all three models or a platform that abstracts them into a common model.
Comparison Table: AWS vs Azure vs GCP IAM
| Dimension | AWS IAM | Azure RBAC | GCP IAM |
|---|---|---|---|
| Core unit of privilege | Policy (JSON) attached to identity or resource | Role assignment on a scope | Binding (member + role + resource) |
| Identity types | IAM users, roles, groups, federated, service accounts | Users, service principals, managed identities, groups | Google accounts, service accounts, groups, workload identity |
| Scoping model | Account-level; SCPs add org-level guardrails | Management group → Subscription → Resource group → Resource | Organization → Folder → Project → Resource |
| Role types | AWS managed, customer managed, inline | Built-in roles, custom roles | Predefined roles, custom roles, basic roles (avoid) |
| Trust / federation | STS AssumeRole; IAM Identity Center for SSO | Entra ID; Workload Identity Federation | Workforce Identity Federation; Workload Identity Federation |
| Deny mechanism | Explicit deny in policy; SCPs for org-wide deny | Deny assignments (limited) | IAM deny policies (GA 2023) |
| Permissions boundary | IAM permissions boundaries on users/roles | Azure ABAC (conditions, preview) | IAM conditions on bindings |
| Audit log | CloudTrail (management + data events) | Azure Activity Log + Entra Sign-in Logs | Cloud Audit Logs (Admin Activity, Data Access) |
| Native audit tool | IAM Access Analyzer, Credential Report | Entra ID Access Reviews, Defender for Cloud | IAM Recommender, Policy Analyzer |
| Cross-cloud visibility | Account-scoped only | Subscription-scoped only | Project-scoped only |
Why CSP-Native Tools Hit a Ceiling
Each cloud provider offers native IAM audit tooling: AWS IAM Access Analyzer and Credential Report, Azure Entra ID Access Reviews and Microsoft Defender for Cloud, GCP IAM Recommender and Policy Analyzer. These tools are genuinely useful within their respective clouds. The problem is that they are, by design, single-cloud. An identity that has an over-privileged role in AWS and a Contributor assignment in Azure appears in two separate tools with no connection between them. The cross-cloud blast radius (what an attacker could reach by moving laterally between clouds using the same compromised identity) is invisible to any individual CSP-native tool. The moment your environment spans more than one cloud, CSP-native auditing has a structural ceiling.
What a Proper IAM Audit Should Cover
Most IAM audits start and stop at the identity inventory: a list of who exists and what roles they have attached. This is the starting point, not the finish line. A complete IAM audit covers six distinct layers, each of which surfaces different categories of risk.
1. Complete Identity Inventory: Humans, Machines, and Agents
The inventory needs to cover every principal that can authenticate and authorize against your cloud APIs: human users, service accounts, IAM roles, managed identities, federated identities, workload identity pools, CI/CD pipeline credentials, and AI coding agents. In most production cloud environments, non-human identities outnumber human ones by a wide margin; estimates consistently put the ratio at 40:1 to 80:1 in mature cloud environments. An audit that covers only human users is an audit that misses the majority of the identity surface.
AI coding agents deserve specific attention in 2026. Claude Code, Cursor, Copilot, and similar tools are increasingly operating in production engineering environments with live cloud credentials reading repositories, calling APIs, and in some cases shipping pull requests directly. These agents typically operate with long-lived keys that were set up once and never revisited, and they are almost never included in standard IAM audits. They represent the newest and least-reviewed privileged access surface in most organizations. For more on how agentic AI changes the security landscape, see our dedicated guide.
2. Effective Permissions: Not Just Attached Policies
Attached policies and role assignments describe what a principal is permitted to request. Effective permissions describe what they can actually do, after all the evaluation logic runs.
On AWS, this means resolving the union of all attached managed and inline policies, subtracting any permission boundaries, and then applying the ceiling set by SCPs, plus considering resource-based policies on the resources being accessed.
On Azure, it means following the scope inheritance chain to understand which assignments apply at which scope.
On GCP, it means checking for IAM conditions that may restrict or broaden what a binding actually permits at runtime.
The gap between attached policies and effective permissions is where over-privilege hides. An identity may have an admin policy attached but be bound to read-only operations by a permission boundary. Conversely, an identity may have a narrow policy at the account level but unrestricted permissions granted via a resource-based policy on a specific S3 bucket. Effective permissions analysis resolves both directions.
3. Usage Analysis: Who Actually Used What
Permission entitlement and permission usage are different data points, and the difference between them is your over-privilege profile. AWS CloudTrail, Azure Activity Logs, and GCP Audit Logs all record API calls with the identity, action, resource, and timestamp.
Cross-referencing attached permissions against actual usage data surfaces three categories: permissions used regularly (retain), permissions used rarely (candidates for reduction), and permissions never used in the observable window (strong candidates for removal). AWS IAM Access Analyzer’s last-accessed data and GCP IAM Recommender both do versions of this automatically, but only within their respective clouds, and only for the identities they can see.
4. Cross-Cloud Privilege Mapping: Aggregate Blast Radius
A single human identity may have an IAM role in AWS, a Contributor assignment in Azure, and an Editor binding in GCP. If that identity’s credentials are compromised (through phishing, credential stuffing, or a leaked access token), the attacker’s reach spans all three clouds simultaneously. The aggregate blast radius is the sum of permissions across all clouds, not the permissions in any single cloud. This is the calculation that no CSP-native tool makes, because each tool is blind to the other clouds. Cross-cloud privilege mapping requires a unified identity model that links the same principal’s access across all environments.
5. Standing Privilege Detection
Standing privilege is the state of having always-on, persistent elevated access; no time limit, no approval required, no session expiry. Every identity with standing admin access is a credential that can be exploited at any time, without triggering an access request that might be reviewed. CIEM tools identify who has what; that is the inventory layer. Standing privilege detection goes one step further: it identifies which of those identities could act on their permissions right now, without any additional authentication or approval step. Those are the highest-priority findings in any IAM audit.
6. Toxic Combinations and Attack Paths
A single over-privileged identity in isolation is a finding. An over-privileged identity attached to a publicly accessible resource with an unpatched CVE is an attack path a chain of conditions that, taken together, represent a credible breach scenario with a specific blast radius. Attack path analysis is what separates an IAM audit report from actionable security intelligence.
It requires correlating identity data with posture data (misconfigured resources), vulnerability data (CVEs on workloads), and network data (what is internet-facing), which is why it cannot be done with a standalone CIEM tool that has no visibility into the adjacent security layers.
Step-by-Step: How to Audit IAM Permissions Across Clouds
Step 1: Establish a Unified Identity Inventory
Consolidate identities from all cloud environments into a single view before doing any analysis. This means enumerating AWS IAM users, roles, and groups; Azure users, service principals, managed identities, and groups; GCP service accounts, Google accounts, and workload identity pools. Include CI/CD pipeline credentials, API keys, and any AI coding agent credentials that are in active use. The inventory is not complete until it covers every principal that can make an authenticated API call to your cloud environment; human or otherwise.
Step 2: Map Effective Permissions, Not Just Attached Policies
For each identity in the inventory, resolve what they can actually do, not just what policies are attached. On AWS, this means running through the policy evaluation logic: union attached policies, apply permission boundaries, apply SCPs.
On Azure, follow the scope inheritance chain for each role assignment.
On GCP, check for IAM conditions on bindings. Native tools (IAM Access Analyzer, Policy Analyzer, Entra ID Access Reviews) help here within each cloud, but cross-cloud effective permission analysis requires a platform that maintains a unified model across all three.
Step 3: Analyse Usage and Cross-Reference With Audit Logs
Pull last-accessed data for each identity from CloudTrail (AWS), Azure Activity Logs, and GCP Audit Logs. Identify permissions that have not been used in the past 90 days is your over-privilege surface. Classify findings into three buckets: actively used (retain), rarely used (review and consider reduction), and never used (strong candidates for removal).
Flag dormant accounts (identities that have not authenticated at all in the past 90 days) for deactivation. This step frequently surfaces service accounts that were created for a project that ended, credentials that belong to departed team members, and roles that were granted during an incident and never revoked.
Step 4: Identify Toxic Combinations and Attack Paths
Cross-reference identity findings with posture data to surface attack paths. The pattern to look for: a principal with a broad permission set that has access to a resource that is either publicly exposed, adjacent to a known CVE, or connected to sensitive data. A developer IAM role with s3:* permissions attached to a bucket that has public access enabled is not just an IAM finding; it is an exfiltration path. An EC2 instance role with iam:* permissions is not just an over-privileged service account; it is a privilege escalation path. Prioritise findings by the exploitability of the chain, not by the CVSS score of any individual component.
Step 5: Audit Non-Human Identities and CI/CD Service Accounts
Run a dedicated audit pass on NHIs separately from human identities. List every service account, CI/CD credential, Lambda execution role, Kubernetes service account, and API key in your environment. For each, answer: What permissions does it have? When were those permissions last used? Is this credential rotated on a schedule, or has it been static since creation? Is this credential scoped to the minimum permissions needed for its declared function, or was it granted broad access to avoid friction? CI/CD service accounts are frequently the most over-privileged identities in a cloud environment, because they were set up once under pressure and never revisited.
Step 6: Document Findings and Prioritise by Blast Radius
Prioritise remediation by what an attacker could actually reach, not by the severity score of an individual finding in isolation. A low-CVSS misconfiguration that sits in front of a production database accessed by an over-privileged identity is a higher priority than a high-CVSS finding on an isolated, non-networked dev instance. Structure your findings report in three tiers: immediate action required (attack paths with internet-facing exposure or standing admin access on sensitive resources), remediate within 30 days (over-privilege without a clear attack path, dormant accounts), and review quarterly (permissions that are used but could be right-sized).
Common IAM Audit Pitfalls
A thorough methodology does not guarantee a useful audit. These are the most common failure modes and the ones most likely to produce a false sense of security.
Auditing Policies in Isolation: No Graph Context
A list of IAM findings without context is a to-do list, not a security posture. Knowing that a role has s3:* permissions is a data point. Knowing that the role is attached to an EC2 instance with a public IP, that the EC2 instance has an unpatched CVE rated 9.8, and that the S3 bucket it can access contains customer PII is an attack path. Policy-level auditing without graph context systematically misses the findings that matter most.
Ignoring Cross-Account Trust Relationships and AssumeRole Chains
AWS AssumeRole chains are one of the most commonly missed IAM audit surfaces. A role in Account A may be allowed to assume a role in Account B, which has admin permissions. If Account A’s role is over-privileged or compromised, the attacker can traverse the trust relationship to reach Account B’s admin access even if Account B’s own IAM policies look clean in isolation. Cross-account trust relationships need to be mapped and audited as part of the identity graph, not treated as a separate exercise.
Treating CIEM Output as the Final Answer
CIEM tells you who has what. It does not answer the follow-up question: which of these identities has standing access that should be converted to time-bound JIT? A CIEM finding that an identity has admin permissions is the start of a decision, not the end of one. The next question is always: does this identity need this permission on a persistent basis, or should it be requesting and receiving it on demand for specific sessions? Without that question, CIEM output produces a finding list but not a remediation path.
Not Accounting for AI Coding Agent Credentials
AI coding agents are the newest and least-audited identity surface in most cloud environments. A developer who has set up Claude Code, Cursor, or Copilot with a long-lived AWS access key has effectively created a persistent, always-authenticated session that can make cloud API calls on demand but which does not appear in any standard IAM audit as a separate identity. The key is registered under the developer’s IAM user, and there is no record of which tool is actually using it. These credentials need to be explicitly inventoried and either replaced with scoped, short-lived tokens or governed through an agent-specific JIT model. See also: What is Model Context Protocol (MCP)?
Snapshot Auditing in a Dynamic Environment
A point-in-time IAM audit is accurate for the moment it was run. In a cloud environment where IAM changes can be made at any time through multiple interfaces, the gap between audit cycles is a window of unreviewed risk. An IAM role granted during an incident at 2 AM on a Tuesday will not appear in a quarterly audit report, but it will be exploitable in the intervening months. IAM auditing in multi-cloud environments needs to operate continuously, not periodically, to provide meaningful assurance.
From Audit to Action: Moving Toward Zero Standing Privilege
The audit reveals the problem. Zero standing privilege is the fix. These are not the same step, and treating the audit as the goal (rather than the input to a remediation program) is how IAM risk accumulates despite regular audit cycles.
The Transition Path
The movement from a raw IAM audit to a zero-standing-privilege posture follows a clear sequence: audit to establish the current state, right-size to remove unnecessary permissions and shrink the blast radius, remove standing access for the highest-risk identities, and implement JIT as the operational model for privileged access going forward.
Right-sizing is the step that most teams skip or deprioritize. It is also the step with the most immediate impact. Removing permissions that an identity has never used, revoking roles granted for projects that ended, and downgrading admin assignments to scoped read-write permissions these changes reduce blast radius without requiring any workflow changes for the identities affected. They are the lowest-friction, highest-value actions an IAM audit can generate.
Removing standing access is the step that requires a workflow change. An engineer who currently has persistent Kubernetes cluster-admin access and needs it occasionally for troubleshooting now needs to request that access, have it approved, use it for a time-bounded session, and have it auto-revoked. This is where the friction conversation happens and where the answer matters.
JIT Is Not Friction: It Is the Operational Model
The objection to JIT is usually about speed. If an engineer needs access to debug a production issue, they cannot wait for a 30-minute approval process. This objection is valid against a poorly designed JIT implementation and completely invalid against a well-designed one.
A well-designed JIT system operates in the tools engineers already use (Slack or Microsoft Teams) with approval happening in a single click from a mobile device. Pre-approved request tiers for common, lower-risk access patterns can be auto-approved with enhanced logging, eliminating any latency. High-risk, high-blast-radius access goes through human approval. The total workflow time for a pre-approved tier is under 60 seconds. The result is not friction: it is an access model that is actually faster to use than logging into a separate PAM portal, while generating a complete, identity-attributed audit trail for every session.
JIT in 2026 also needs to cover the full privilege surface; not just cloud console access.
- Multi-surface JIT: cloud consoles across AWS, Azure, and GCP
- Database access with per-query audit
- Kubernetes namespace access
- SaaS application access
- Non-human identity credentials with short TTLs
- AI coding agent credentials brokered through an MCP integration rather than long-lived keys stored in environment files
Cyber insurers and SOC 2 and ISO 27001 auditors now ask for zero standing privilege explicitly, and they are asking about the full surface, not just console access.
The Compliance Driver
JIT / zero-standing-privilege is no longer just a security best practice. Cyber insurers ask for it during underwriting. SOC 2 and ISO 27001:2022 auditors ask for time-bound access with an approval trail. DPDPA requires identity-attributed access audit for data-tier access. The audit findings create the business case; the compliance requirements create the urgency.
How a Unified Asset Graph Changes the IAM Audit
A CIEM tool that sees only IAM produces a list of identity findings. A unified asset graph that connects IAM to posture, to vulnerability data, to network topology, and to runtime behavior produces a security picture. The difference is not incremental; it changes what questions you can answer and how long it takes to answer them.
One Query Across Five Data Layers
In a platform built on a unified asset graph (with 300+ resource types, typed relationships, and recursive attack-path traversal), the question ‘which identities have admin permissions on resources with public exposure and an active CVE?’ is a single query, not a five-tool correlation exercise.
The IAM data, the posture data, the vulnerability data, and the network exposure data share a common model and a common query surface. The same applies to cross-cloud correlation: an identity with roles in AWS and Azure appears as a single node with relationships to resources in both clouds, making the aggregate blast radius calculation immediate rather than manual.
Natural Language Search for IAM Queries
For platform and architecture teams who do not want to write graph query syntax, natural language search over the asset graph means that questions like ‘show me all service accounts with admin permissions that haven’t been used in 60 days’ or ‘which identities have cross-account trust relationships that reach production resources’ can be answered directly without building a custom query or exporting data to a spreadsheet.
BYOR for Custom IAM Audit Logic
Every organization’s IAM standards are different. A financial services firm’s definition of an over-privileged identity is not the same as a Series B startup’s. BYOR (Bring Your Own Rules) via API means that custom audit logic (specific to your architecture, your compliance requirements, or your internal IAM policy) can be authored and run against the same unified graph as the standard rule library. This removes the ‘we’d lose customization’ objection to platform consolidation and makes the audit tool extensible without requiring a fork or a custom deployment.
Cloudanix CIEM and JIT on a Single Graph
Cloudanix’s CIEM capability operates on the same unified asset graph as its CSPM, CWPP, code scanning, and JIT modules. This means IAM audit findings (over-privileged roles, dormant accounts, NHI sprawl, cross-cloud blast radius) arrive with the surrounding context already attached: which resources are affected, what their current posture is, whether there are active CVEs on adjacent workloads, and what the estimated blast radius of a compromise would be.
UEBA v2 adds a 0–100 composite identity risk score per principal, making prioritization a function of the platform rather than a manual judgment call.
The JIT module then closes the loop: once audit findings identify standing privileged access that should be time-bounded, JIT provides the operational model for doing so (across cloud consoles, databases, VMs, Kubernetes, SaaS, NHIs, and AI coding agents via MCP) with Slack-based approval, identity-attributed session audit, and auto-revocation built in. The audit and the fix operate on the same platform, with the same asset graph as the shared foundation.
Customer proof point: Moneyview (FSI, India) eliminated 100% of standing privilege across cloud and database tiers via Cloudanix JIT, used as the lead identity-centric security reference in the Forward Defence workshop.
Customer proof point: Eversana (Healthcare, US: 80+ AWS accounts + Azure + GCP) unified multi-cloud identity posture across business units, reducing HIPAA audit prep from weeks to hours.
Conclusion
IAM auditing in a multi-cloud environment is not optional and it is not a once-a-year exercise. It is the baseline operational practice that underpins zero-trust architecture, compliance assurance, and breach containment. Every compliance framework that matters (SOC 2, ISO 27001, HIPAA, DPDPA, PCI-DSS) has explicit access control evidence requirements that a quarterly spreadsheet audit cannot reliably satisfy.
The method outlined here (unified identity inventory, effective permissions analysis, usage cross-referencing, attack path identification, NHI-specific audit, and blast-radius-driven prioritization) gives you the structure to run an audit that produces actionable findings rather than a long list of policy attachments. The transition from audit to action (right-size, remove standing access, implement JIT) gives you the path from findings to a materially improved security posture.
The specific challenge of multi-cloud is that no single CSP-native tool sees the full picture. The identity that looks clean in AWS may have an over-privileged role in Azure. The service account that appears unused in GCP may be the one your CI/CD pipeline is using to deploy to production. The AI coding agent running on a developer’s machine may be authenticating with a long-lived key that nobody audited because it never appeared in the IAM console as a separate identity. Seeing the full picture requires a unified model, and acting on it requires a platform that connects the audit to the remediation.
People Also Read
- What is Cloud Infrastructure Entitlements Management (CIEM)?
- What is Just-In-Time (JIT) Access?
- Non-Human Identities: Complete Guide to Securing Machine-to-Machine Access
- What Is Attack Path Analysis?
- What Is Blast Radius in Cloud Security?
- What Is a Cloud Security Graph?
- What Is Agentic AI Security?
- Identity and Access Management - The New Edge of Security
- Privilege Elevation and Delegation Management (PEDM)
