Privileged Access Management for Azure means removing standing administrative rights from Entra ID and Azure Resource Manager roles and replacing them with time-boxed, approved, logged activations. Done properly it is Entra Privileged Identity Management (PIM) plus Conditional Access plus a hard look at every service principal and managed identity that can touch production.
- Native PIM covers Entra roles and Azure resource roles; it does not cover on-premises accounts, network devices, or session recording for RDP and SSH, so most enterprises still run a PAM platform alongside it.
- The most common gap in audits is not missing MFA, it is standing Owner or Contributor rights on service principals and automation accounts that nobody reviews.
- Assessors want evidence: access review reports, activation logs, and a documented joiner-mover-leaver process, not a policy document describing intent.
Why Native Azure Controls Are Not Enough On Their Own
Azure gives you two separate control planes for privilege: Entra ID roles (Global Administrator, User Administrator, Application Administrator) and Azure Resource Manager roles (Owner, Contributor, User Access Administrator) scoped to management groups, subscriptions, resource groups, or individual resources. PIM can put both under time-bound activation. That is a real control, but it only covers accounts and roles that are actually enrolled in PIM. An account with a permanent role assignment outside PIM is invisible to the activation workflow entirely, and Azure will not warn you about it.
The gap that actually gets exploited is standing access on identities nobody thinks of as privileged: automation accounts, CI/CD service connections, Logic App managed identities, and break-glass accounts created once during tenant setup and never revisited. None of these show up in a PIM activation report because none of them ever went through PIM.
Entra PIM: Eligible Assignments, Activation, and Approval
PIM's core mechanic is the split between eligible and active assignment. An eligible user has no standing permission; they request activation, and only for the activation window do the permissions actually apply. Three settings decide whether this is a real control or theatre.
Activation duration and justification
Set the maximum activation window per role, not a blanket default. Global Administrator and Owner at subscription scope should be shorter than reader-tier roles. Require a justification string on every activation; it is the field auditors read first because it is the only place intent gets recorded.
Approval workflow
Roles above a defined blast radius (Global Administrator, Owner at management group or subscription scope, User Access Administrator) should require a named approver, not self-service activation. Self-approval defeats the point of PIM: it becomes MFA with extra steps.
Alert and review cadence
PIM generates alerts for roles being assigned outside PIM, roles with no MFA on the account, and duplicate role assignments. These alerts are silent by default; someone has to be assigned to receive and act on them, and access reviews need an owner and a schedule, not a one-time setup task.
Conditional Access Is Where the Policy Actually Bites
PIM decides who can activate a role. Conditional Access decides under what conditions that activation is allowed to succeed. The two need to be linked through authentication context, otherwise a role activation from an unmanaged device or an unfamiliar location goes through unopposed.
A workable policy set for privileged roles: require phishing-resistant MFA rather than SMS or voice, require a compliant or Entra-joined device, block legacy authentication protocols outright, and apply sign-in risk and user risk conditions so a session flagged as risky cannot activate a role even with a valid password. Geographic and network location restrictions help but are the weakest layer; treat them as a tripwire, not a control.
The Part Everyone Skips: Service Principals and Managed Identities
Workload identities do not have a PIM equivalent in most tenants, which is exactly why they accumulate standing privilege. A service principal with Owner on a subscription, created for a one-time migration and never revoked, is a more common finding in access reviews than any human account misconfiguration. Treat every service principal and managed identity as a privileged account.
- Inventory role assignments by service principal, not just by user, and flag any with Owner or Contributor at subscription scope.
- Prefer managed identities over service principal credentials wherever the resource supports it; there is no secret to leak if there is no secret.
- Scope automation accounts to the specific resource group they operate on, never to the subscription, even when it is faster to set up that way.
- Rotate and expire client secrets on any service principal that still uses one, and alert on secrets nearing expiry rather than finding out when a pipeline breaks.
Where a Dedicated PAM Platform Still Earns Its Place
Entra PIM and Conditional Access cover Azure and Entra roles well. They do not extend to on-premises Active Directory, network appliances, database accounts, or session recording for interactive RDP and SSH sessions into servers. Organisations running both Azure and on-premises infrastructure typically pair PIM with a privileged access management platform such as BeyondTrust for session isolation and credential vaulting across both environments, rather than trying to stretch Microsoft Entra ID native controls to cover infrastructure it was never built to manage. The decision point is usually session recording: if an assessor or regulator expects recorded, replayable privileged sessions on servers and network devices, native Azure logging will not satisfy that on its own.
What Assessors Actually Ask For
Whether the driver is CBUAE guidance, NESA controls, or an internal audit, the evidence requests tend to repeat: a current list of privileged role holders with business justification, activation and approval logs covering a defined period, proof that MFA is enforced on every privileged account without exception, a documented process for onboarding and offboarding privileged access tied to HR events, and records of the last access review with remediation actions closed out. See the PAM fundamentals FAQ for the underlying control set. A policy that exists only as a document with no logs behind it fails this conversation immediately.
A Rollout Order That Survives Contact With Production
Doing all of this at once breaks change management and the help desk. The sequence that holds up in practice:
- Inventory every Entra and Azure Resource Manager role assignment, human and non-human, before touching PIM settings.
- Enrol the highest blast-radius roles into PIM first (Global Administrator, Owner at subscription and management group scope), with approval required and a short activation window.
- Link Conditional Access authentication context to those same roles so activation itself is gated on device compliance and phishing-resistant MFA.
- Clean up service principal and managed identity assignments in parallel; this is usually where the largest number of findings sits.
- Extend PIM to lower-tier roles once the alerting and approval workflow is proven not to block legitimate work.
- Put access reviews on a recurring schedule with a named owner, not a calendar reminder that gets snoozed.
