Entra ID, Conditional Access & PIM

Two identity planes, adaptive sign-in, just-in-time roles.

Azure security begins in Entra ID (formerly Azure AD), because identity is the real perimeter and Azure has two distinct identity planes that people constantly conflate. Getting them straight is the difference between a coherent access model and a pile of over-grants.

Two planes: directory roles vs Azure RBAC

Entra directory roles (Global Administrator, User Administrator, Application Administrator) govern the tenant itself — users, groups, app registrations, Conditional Access. Azure RBAC roles (Owner, Contributor, Reader) govern Azure resources — VMs, storage, Key Vaults. They are separate systems with separate assignments: a Global Administrator has no automatic power over resources, and an Azure Owner has no automatic power over the directory (though a Global Admin can elevate to gain it). Treat each plane’s privileged roles as crown jewels in their own right.

# Directory (Entra) role — governs tenant objects:
#   Global Administrator, Privileged Role Administrator, Application Administrator
 
# Azure RBAC role — governs resources at a scope:
az role assignment create \
  --assignee app-team@acme.com \
  --role "Contributor" \
  --scope /subscriptions/SUB/resourceGroups/payments-prod
 
# A Global Admin can toggle "access management for Azure resources" to gain
# User Access Administrator at the ROOT — a known elevation path to watch.

Conditional Access and just-in-time

Conditional Access is the policy engine that makes sign-in adaptive: require MFA, a compliant device, or a trusted location — or block risky sign-ins outright. Pair it with Privileged Identity Management so privileged roles are eligible rather than permanently active: admins elevate just-in-time, with approval and MFA, for a bounded window that is fully logged. Standing Global Administrator on a dozen accounts is exactly the exposure PIM removes.