Most IAM advice assumes a single platform here's how to do access right in AWS, here's how to do it right in Azure. That advice is genuinely correct, taken individually. It's also incomplete for a growing number of enterprises, because the actual hard problem in IAM right now isn't getting identity right on any one platform. It's getting it consistent across two or three platforms that were never designed to share a security model, running side by side, in the same organization, often managed by different teams with different assumptions.
My honest opinion here: single-platform IAM is close to a solved problem at this point. Multi-cloud IAM consistency is not, and most enterprises running hybrid or multi-cloud environments are quietly carrying identity risk they haven't fully mapped, because nobody's specifically responsible for the seams between platforms everyone's responsible for their own platform, and the gaps live in exactly the space between those ownership boundaries.
Each Platform's Identity Model Is Genuinely Different, Not Just Differently Named
This is the assumption that trips people up first. AWS IAM, Azure Entra ID, and Google Cloud IAM aren't the same concept wearing different labels they have real structural differences in how roles, policies, and trust relationships actually work under the hood. Porting a mental model built on one platform directly onto another produces subtly wrong assumptions that don't show up as obvious errors, they show up as gaps nobody notices until something goes wrong specifically at the boundary between platforms.
Teams managing multi-cloud environments need genuine fluency in each platform's actual identity model, not a translated version of whichever platform they learned first applied loosely to the others. This sounds obvious stated directly, and it's routinely skipped anyway, because deep expertise in one platform's IAM feels transferable in a way that it genuinely isn't at the level of detail that actually matters for security decisions.
Federated Identity: The Right Answer, Implemented Inconsistently
Federating identity through a central provider Entra ID, Okta, or a similar identity provider serving as the source of truth across platforms is the architecturally correct approach for multi-cloud environments, and most organizations running multiple clouds have some version of this in place. The gap is usually in how thoroughly it's actually implemented rather than whether the concept is understood.
Partial federation some access genuinely flowing through the central identity provider, other access still using platform-native accounts created directly and independently on each cloud creates exactly the inconsistency that undermines the entire point of federating in the first place. A user or service with both a federated identity and a separate, platform-native account represents two access paths to audit, two places permissions can drift out of sync with each other, and two places an attacker could potentially find the weaker of the pair and use that as the entry point instead of the better-secured one.
Consistent Least-Privilege Policy Across Platforms That Enforce It Differently
Least-privilege is a universal principle, but enforcing it consistently across platforms with genuinely different policy languages and permission models is real, non-trivial work not just applying the same conceptual standard in three different places using three different syntaxes.
A role that's appropriately scoped in AWS IAM syntax doesn't automatically translate to an equally well-scoped role in Azure RBAC or Google Cloud IAM just because someone tried to apply "the same policy" conceptually across all three. Genuine cross-platform least-privilege requires platform-specific expertise applied consistently against a shared standard not a single policy document that assumes translation between platforms is more mechanical and lossless than it actually is in practice.
Centralized Visibility Across Platforms Is Rare, and It's the Actual Gap
Most organizations have reasonably good IAM visibility within each individual platform you can audit AWS IAM permissions, you can audit Azure RBAC assignments, each in their own respective consoles or tooling. Far fewer have genuine, unified visibility across all platforms simultaneously, in one place, answering a simple but surprisingly hard question: what access does this specific person or service actually have, in total, across every environment they touch.
This gap matters more than it initially sounds like it should, because access risk doesn't respect platform boundaries even though visibility tooling frequently does. A person with moderate, individually reasonable-looking access on each of three separate platforms might have genuinely excessive combined access when all three are considered together and nothing in a per-platform review, however thorough within its own scope, would ever surface that, because each individual review is only ever looking at one piece of the whole picture.
Service Account and Machine Identity Sprawl Across Platforms
Machine identities service accounts, application identities, automated integrations multiply rapidly in multi-cloud environments specifically, because each platform, and frequently each service within each platform, tends to spawn its own service accounts and credentials as part of normal, unremarkable operation. Tracking these consistently across platforms is genuinely harder than tracking human identities, because machine identities don't go through the same onboarding and offboarding processes human accounts typically do, and there's rarely a single, obvious "employee left the company" trigger prompting a review the way there naturally is for human accounts.
A genuine cross-platform inventory of machine identities what exists, what it can access, whether it's still actually in use is foundational and consistently missing at real enterprise scale. Without it, machine identity sprawl accumulates quietly across every platform simultaneously, in parallel, largely unnoticed until an audit or an incident specifically forces someone to go looking for it directly.
Privileged Access Needs Cross-Platform Consistency, Not Just Per-Platform Rigor
Just-in-time privileged access Azure's PIM, AWS's equivalent approaches to temporary elevated access genuinely reduces standing privilege risk within whichever platform it's actually configured on. The gap in multi-cloud environments is consistency: privileged access managed rigorously on one platform while another platform in the same organization still relies on standing, always-on administrative access, simply because the just-in-time tooling and discipline that's genuinely mature on the first platform was never extended to the second one.
Attackers, for their part, don't particularly care which platform offers the path of least resistance into an organization's broader environment they'll use whichever one is weaker, and a multi-cloud environment is only as strong, in practice, as its least-rigorously-managed platform, regardless of how well-secured the other platforms happen to be.
Audit Logging Needs Genuine Cross-Platform Correlation
Each platform generates its own access and activity logs CloudTrail for AWS, Azure Activity Log and sign-in logs for Azure, equivalent logging for Google Cloud. Investigating a genuine incident that spans platforms which is increasingly common precisely because attackers actively look for exactly this kind of gap between platforms to exploit requires correlating these logs together, and that correlation is real, non-trivial technical work if the logs were never designed with cross-platform correlation in mind from the start.
Centralized log aggregation specifically built for genuine cross-platform correlation, not just parallel collection into a shared storage location without any real correlation layer on top, is what actually makes incident investigation feasible across a genuinely multi-cloud environment rather than technically theoretically possible but practically prohibitively difficult to execute quickly under real incident pressure.
Compliance Requirements Don't Care Which Platform Holds the Data
For organizations subject to PCI DSS, HIPAA, or similar frameworks, compliance requirements apply to the data and the process, not to whichever specific cloud platform happens to be hosting a given workload at a given moment. IAM controls need to genuinely meet compliance standards consistently across every platform actually in scope not just on whichever platform happened to be the primary focus during the original compliance assessment or the initial architecture review, with other platforms picking up equivalent scrutiny later, if at all.
What Genuine Multi-Cloud IAM Maturity Actually Looks Like
Pulled together, this generally requires:
Deep, platform-specific expertise on every platform actually in use, not one platform's mental model loosely applied everywhere else
Full, consistent federation through a central identity provider, eliminating the parallel platform-native accounts that undermine the entire point of federating
Least-privilege enforced consistently, translated correctly and deliberately across genuinely different policy languages, not assumed to transfer automatically
Unified cross-platform access visibility, answering "what does this identity actually have, in total" rather than only "what does this identity have on this one platform"
A genuine cross-platform machine identity inventory, closing a gap that consistently exists in parallel, independently, across every platform simultaneously
Consistent just-in-time privileged access, not rigorous on one platform and standing and unmanaged on another
Genuine cross-platform log correlation, built for actual incident investigation speed, not just centralized storage without real correlation capability
The Actual Point
Multi-cloud IAM risk doesn't concentrate on any single platform it concentrates specifically in the seams between platforms, in the places where each team's ownership boundary ends and nobody's individually accountable for what happens to identity and access at that exact boundary. An organization can have genuinely excellent IAM practices on every individual platform it runs and still carry real, meaningful risk purely from the inconsistency between them.
If nobody in your organization can currently produce a single, accurate answer to "what access does this person or service have, across every platform we run, right now" — that gap, not any single platform's specific IAM configuration, is usually the actual place multi-cloud identity risk is concentrated.
Top comments (0)