Azure IAM: Entra ID, RBAC, and Conditional Access

Azure's identity model is the most complex of the three major clouds, and for good reason: Microsoft built it to handle both cloud infrastructure access and the enterprise identity problems that organizations have been solving with Active Directory for decades. The result is a two-plane system that confuses even experienced engineers — and creates audit findings when the two planes are conflated.

This lesson breaks down Azure's identity and access model into its two distinct planes, covers the Azure-specific concepts that have no direct equivalent in AWS or GCP, and explains why Conditional Access and Privileged Identity Management make Azure the strongest cloud for identity governance out of the box.

Two planes: Identity and resources

Azure separates identity management from resource management into two distinct systems that happen to share a portal. Understanding this separation is the single most important concept in Azure IAM.

┌─────────────────────────────────────────────────────┐
│                   IDENTITY PLANE                     │
│                   (Entra ID)                         │
│                                                      │
│  Who exists? How do they authenticate?               │
│                                                      │
│  ┌──────────┐  ┌──────────┐  ┌───────────────────┐  │
│  │  Users    │  │  Groups  │  │  App Registrations│  │
│  └──────────┘  └──────────┘  └───────────────────┘  │
│                                                      │
│  Entra ID Roles:                                     │
│  - Global Administrator                              │
│  - User Administrator                                │
│  - Security Administrator                            │
│  - Application Administrator                         │
│  (These control the DIRECTORY, not Azure resources)  │
│                                                      │
│  Controls: Conditional Access, MFA, Password Policy  │
├──────────────────────┬──────────────────────────────┤
│                      │                               │
│              Authentication                          │
│              (identity verified)                      │
│                      │                               │
│                      ▼                               │
│                   RESOURCE PLANE                      │
│                   (Azure RBAC)                        │
│                                                      │
│  What can they do with Azure resources?              │
│                                                      │
│  ┌────────────────┐  ┌───────────┐  ┌────────────┐  │
│  │ Management     │  │Subscription│ │  Resource   │  │
│  │ Groups         │  │            │ │  Groups     │  │
│  └────────────────┘  └───────────┘  └────────────┘  │
│                                                      │
│  Azure RBAC Roles:                                   │
│  - Owner                                             │
│  - Contributor                                       │
│  - Reader                                            │
│  - 300+ service-specific roles                       │
│  (These control AZURE RESOURCES, not the directory)  │
└─────────────────────────────────────────────────────┘

Entra ID (formerly Azure Active Directory) is the identity plane. It manages users, groups, application identities, authentication policies, and directory-level roles. When you create a user, reset a password, enforce MFA, or configure Conditional Access, you are working in Entra ID.

Azure RBAC is the resource plane. It controls what authenticated identities can do with Azure resources — virtual machines, storage accounts, databases, networking. When you grant someone the ability to create VMs or read storage blobs, you are creating an Azure RBAC role assignment.

The confusion: Entra ID roles vs Azure RBAC roles

This is the number one source of misunderstanding in Azure IAM, and it is a frequent audit finding.

Entra ID roles control the directory. A Global Administrator can manage all users, groups, and settings in Entra ID. A User Administrator can create and manage users. A Security Administrator can manage security features and read security reports. These roles have nothing to do with Azure resources. A Global Administrator cannot, by virtue of that role alone, access a virtual machine or read a storage account.

Azure RBAC roles control Azure resources. An Owner can manage all resources and grant access. A Contributor can create and modify resources but not manage access. A Reader can view resources but not change them. These roles have nothing to do with the directory. An Owner on a subscription cannot create users or manage Conditional Access policies.

There is one exception: a Global Administrator can elevate themselves to get User Access Administrator at the root management group, which then gives them Azure RBAC access. This elevation is an auditable event and should be monitored — it is the bridge between the two planes, and it should almost never be used.

The Azure RBAC hierarchy

Azure RBAC role assignments follow a hierarchy similar to GCP's resource hierarchy, with policies inheriting downward:

Management Groups are the top-level container (similar to GCP's Organization/Folders). They organize subscriptions into a hierarchy for applying policies and RBAC at scale. The root management group sits at the top.

Subscriptions are the primary billing and access boundary (similar to AWS accounts or GCP projects). Each subscription contains resource groups and resources.

Resource Groups are logical containers within a subscription for organizing related resources (a web app, its database, and its storage account might share a resource group).

Resources are individual Azure services — a VM, a storage account, a database.

A role assignment at the management group level inherits down to all subscriptions, resource groups, and resources within it. The same additive model as GCP: you cannot remove an inherited assignment at a lower level without using deny assignments (which are rare and primarily used by Azure Blueprints).

Managed Identities

Managed identities are Azure's equivalent to IAM roles for services (AWS) or attached service accounts (GCP). They provide an identity for Azure resources without any credentials to manage — no passwords, no certificates, no secrets.

There are two types:

System-assigned managed identities are tied to a single Azure resource. When you enable a system-assigned identity on a VM, Azure creates an identity in Entra ID that is bound to that VM's lifecycle. When the VM is deleted, the identity is automatically deleted. The identity can only be used by that specific VM.

User-assigned managed identities are standalone Entra ID resources that you create and manage independently. You can assign the same user-assigned identity to multiple resources. This is useful when multiple services need the same permissions — for example, three microservices that all need to read from the same Key Vault.

The credential management is handled entirely by Azure. The VM or service obtains tokens from the Azure Instance Metadata Service (IMDS), which provides short-lived tokens that are automatically rotated. No key files, no client secrets, no credential rotation process.

# Create a user-assigned managed identity
az identity create \
  --resource-group my-resource-group \
  --name my-app-identity

# Assign the Azure RBAC role "Storage Blob Data Reader" on a storage account
az role assignment create \
  --assignee <managed-identity-client-id> \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>

When you find an application using client secrets or certificates to authenticate instead of managed identities, and that application runs on Azure infrastructure, that is a finding. Client secrets expire, can be extracted from configuration files, and require a rotation process. Managed identities eliminate all of these risks.

Conditional Access

Conditional Access is where Azure's identity model pulls ahead of AWS and GCP for GRC purposes. It is a policy engine in Entra ID that evaluates signals about the user, their device, their location, and their risk level, then enforces controls before granting access to applications.

A Conditional Access policy has three parts:

Assignments define who the policy applies to and what applications it targets. You can target all users, specific groups, specific applications, or exclude break-glass accounts.

Conditions define the signals that trigger the policy: user risk (is this account likely compromised?), sign-in risk (is this login anomalous?), device platform (iOS, Android, Windows), location (trusted network vs unknown), client app type (browser, mobile app, legacy auth).

Controls define what happens when the conditions are met: require MFA, require a compliant device, require a managed device, block access entirely, limit the session duration, require terms of use acceptance.

Here is what makes Conditional Access powerful for GRC: it lets you enforce different controls based on context. Examples:

• Require MFA for all users, all applications, all the time (the baseline policy every organization should have)
• Block access from countries where the company has no operations
• Require a compliant device (enrolled in Intune, disk encrypted, firewall enabled) for accessing sensitive applications like financial systems
• Block legacy authentication protocols that cannot support MFA (IMAP, POP3, SMTP basic auth)
• Force session re-authentication every hour for high-risk applications
• Automatically block sign-ins flagged as high risk by Entra ID Protection

Each of these policies is a control that maps directly to compliance requirements. SOC 2 CC6.1 asks about logical access controls — Conditional Access policies are the evidence. ISO 27001 A.9.4.1 asks about restricting access to information — Conditional Access enforces those restrictions dynamically based on real-time signals.

Privileged Identity Management (PIM)

Privileged Identity Management is Azure's built-in just-in-time (JIT) access solution. It eliminates standing privileged access by making users activate their roles when they need them, with time limits and approval workflows.

Without PIM, a Global Administrator has that role 24/7. They have it while checking email, while browsing the web, while attending meetings — all times when they do not need administrative access. If their account is compromised during any of those times, the attacker inherits Global Administrator.

With PIM, the user is eligible for Global Administrator but does not have it by default. When they need to perform an administrative task, they activate the role through PIM. The activation can require:

• Justification — the user must explain why they need the role
• Approval — another administrator must approve the activation
• MFA verification — re-authenticate before activation
• Time limit — the role automatically deactivates after a set period (e.g., 4 hours)

PIM also provides access reviews, which periodically ask role holders to justify their continued need for the role. If they do not respond, the assignment is automatically removed.

For a GRC engineer, PIM provides built-in evidence for three common audit requirements: (1) privileged access is time-limited (the activation records show start and end times), (2) privileged access is justified (the justification text is logged), and (3) privileged access is reviewed (the access review results are exportable). This is evidence that usually requires a third-party PAM tool in AWS and GCP.

App registrations and service principals

Applications in Azure get identity through a two-part model:

App registrations define the application — its name, what permissions it needs, how it authenticates. An app registration lives in a specific Entra ID tenant and represents the application's identity configuration.

Service principals are the local instance of an app registration in a tenant. When a third-party SaaS vendor registers their app and your organization consents to use it, a service principal is created in your tenant that represents that vendor's app. Your Conditional Access policies and role assignments apply to the service principal, not the app registration.

Applications authenticate using one of three methods:

• Client secrets — string passwords that the application presents. They have expiration dates but are otherwise static credentials. This is the weakest option and should be avoided for production applications.
• Certificates — X.509 certificates that the application uses for assertion-based authentication. Stronger than client secrets, but still requires certificate management and rotation.
• Managed identities — the best option when the application runs on Azure infrastructure. No credentials to manage at all.

The audit finding pattern: applications using client secrets with distant expiration dates (or that have been rolled over repeatedly without decommissioning old secrets), applications with overly broad Microsoft Graph API permissions (e.g., Directory.ReadWrite.All when they only need User.Read), and applications where admin consent was granted for high-privilege permissions without documented justification.

Mapping Azure concepts to what you already know

The key takeaway: Azure has the most mature identity governance features built into the platform. Conditional Access and PIM are capabilities that AWS and GCP customers typically need third-party tools (Okta, CyberArk, Teleport) to achieve. For organizations that are Azure-native, these features are available out of the box and should be configured from day one.

What to carry forward

Azure's two-plane model, Conditional Access, and PIM make it the most feature-rich cloud for identity and access governance. But that richness creates complexity: two separate role systems to audit, application identities with their own credential lifecycles, and Conditional Access policies that can interact in unexpected ways when layered.

You now have a working understanding of IAM across all three major clouds. In the next exercise, you will take an AWS IAM architecture and map it to equivalent controls in GCP and Azure — the kind of cross-cloud translation that GRC engineers do when organizations expand from one cloud to multiple.