# Many Clouds, One Question: PanIAM Now Covers Azure > PanIAM now models Azure access. Your Entra ID directory and your subscriptions join the rest of your cloud in one access graph, including the paths that cross from one cloud to another. * URL: * Author: Jean-Yves Pasquier * Published: 2026-11-11 * Tags: feature Ask your teams a simple question: who can reach our customer data? Few can answer with any assurance. When that data spans several clouds, you get one answer per team, delivered by one tool per cloud, and none of them covers the access that crosses from one cloud to another. PanIAM answers one question across your cloud estate: who can really access what, directly or through a chain of steps. Today, we're bringing **Microsoft Azure** into PanIAM. Your Entra ID directory, your subscriptions, and the storage and virtual machines in them now sit in the same access graph as the rest of your cloud. ## Multi-Cloud by Design, Reviewed in Halves Many companies run several clouds on purpose. Spreading workloads across providers limits vendor lock-in, keeps options open when contracts come up for renewal, and lets each workload run where one provider is strongest. It is now the norm: in [Fortinet's 2026 Cloud Security Report](https://fortinet.com/blog/cloud-security/2026-cloud-security-report-data-reveals-complexity-gap), 88% of the organizations surveyed run hybrid or multi-cloud environments, and among them, 81% rely on two or more cloud providers for critical workloads. A multi-cloud strategy is decided once, for the whole company. Access reviews run on each team's own cycle: one team reviews the directory, another the AWS accounts, a third the Azure subscriptions. The strategy spans every cloud. The reviews don't. ## Where Reviews Stop Each review can be thorough and still miss what matters, because the clouds don't line up: - **Two languages for one word.** In AWS, a role is an identity that people and services take on. In Azure, a role is a set of permissions granted at a scope, and Azure has [two separate role systems](https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles): Azure roles for resources, and Microsoft Entra roles for the directory itself. - **Controls live on the other side.** When staff sign in to AWS through Entra ID, [the protections on that sign-in](https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/aws/aws-azure-ad-security) (multifactor authentication, Conditional Access, Privileged Identity Management) are set in Entra. The person reviewing AWS access cannot see the control that access depends on. - **Review tools stop at their border.** IAM Access Analyzer reviews access to AWS resources; Entra access reviews check who belongs to which group or application. [Microsoft's own comparison](https://learn.microsoft.com/en-us/azure/architecture/aws-professional/security-identity) presents them as counterparts. Neither tells you what an Entra group can do inside AWS. Yet the clouds are joined on purpose. Staff can sign in to AWS with their Entra ID account, and their Entra groups decide which AWS roles they get. AWS workloads can [obtain access to Azure through workload identity federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation), using [tokens issued by AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound.html) instead of stored secrets. And whoever can change those Entra groups decides who gets into AWS: Microsoft lists "services that federate to Microsoft Entra ID" among [what a Global Administrator manages](https://learn.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles). Each team reviews its own end of these crossings. The AWS team sees a role that trusts an identity provider, not who in the directory can obtain it. The Azure team sees a group, not the production AWS account its members open. In most organizations, nobody looks at what happens where the clouds meet. ## What You Are Asked to Prove For a CISO or a DPO, this gap comes with a deadline. [NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) asks essential and important entities for access control policies and asset management (Article 21(2)(i)) and, once aware of a significant incident, for a first assessment of its severity and impact within 72 hours (Article 23(4)). The [GDPR](https://eur-lex.europa.eu/eli/reg/2016/679/oj) asks a controller to regularly test its security measures (Article 32(1)(d)) and to notify a breach within 72 hours where feasible, with the approximate number of people and records concerned (Article 33). Both come down to one question: what could the identities involved reach? If the answer takes one review per cloud and a meeting to reconcile them, the deadline arrives first. We covered NIS2 in more detail in [NIS2: From Compliance to Competitive Advantage](https://blog.paniam.cloud/posts/nis2.md). ![Everything three AWS single sign-on administrator roles can reach, from AWS resources to the Azure storage accounts holding KYC, payment and card transaction data, in one PanIAM graph](https://blog.paniam.cloud/_astro/multi-cloud-blast-radius.DQvBCLHU.png) ## One Model, One Graph PanIAM reads your Azure estate through a read-only app registration in your Entra ID directory: a read-only role on your tenant root management group, and read-only permissions on Microsoft Graph. The role carries no data actions, so PanIAM cannot read what your storage accounts hold. It computes effective access in Azure with the same engine it uses for the rest of your cloud, across every subscription in the directory at once, and puts the result in the same graph. In Azure, PanIAM now resolves: - **Who your identities are.** Every Entra ID user is a starting point, and nested group memberships are followed to every grant they carry. - **What Azure RBAC really grants.** Role assignments are evaluated through the whole scope chain, from management groups down to a single resource, with deny assignments taken into account. - **Who can reach your data.** Who can read or write your Azure Storage accounts and the containers that hold their files, including anyone who can read an account's access keys, which unlock all of its data. - **Who can run code on your machines.** Run Command on virtual machines and scale sets is followed to the managed identities attached to them, and on to everything those identities can reach. The result is not a list of permissions but access paths: chains of steps from an identity to a sensitive resource, each step named. Remediations are worded in Azure terms (the role assignment to remove, the managed identity to detach), with the risk each fix takes away, so your teams can weigh an Azure change against an AWS change on the same scale. And because your clouds sit in one graph, the crossings stop being blind spots. A path that starts on an AWS workload, crosses into Azure, runs a command on a virtual machine there and ends in the storage account holding your KYC documents is shown end to end, at the scale of your whole estate. ![An access path in PanIAM from the payments-gateway workload on AWS, through two AWS roles, into an Azure identity, then through Run Command on the fraud-scoring virtual machine to the storage account holding KYC documents](https://blog.paniam.cloud/_astro/multi-cloud-attack-path.BwclRo5H.png) ## Every Cloud You Run, in One Graph Several clouds should not mean several partial answers. Your board, your regulator and your incident responders all ask the same question: **who can really reach this data, whichever cloud it sits in?** If you're already using PanIAM, contact us to turn on the analysis of your Azure directory. If not, [get secure now](mailto:get-secure-now@paniam.cloud) and see your clouds in one graph. ## Google Cloud Is Next Azure is not the last cloud to join the graph. Google Cloud is coming soon, with the same model: its identities and resources in the same graph as the rest of your cloud, and the same question answered across all of it. If Google Cloud is part of your estate, [join the waiting list](https://44d742c7.sibforms.com/serve/MUIFAAbCtt0bh0DUFbmfQmsoT-sFQeRj4IrSvAHdDAP5FGR084mHHkcCc3-JBl3rkyKQQkYHUJmK3D97sdOK_4NV8d9iIH2eF9iwhoc4kM1Uk5jGKt85sSzh9N6ZBXQTphVkVOyCwv0tFDhOsm-H5v96taNnNRvDKuRyes5gIgXdPhSFZJaELVg5E05D8exj-Q9zQIHzeO2fTb6s) and be among the first to get access.