Microsoft Azure — Privileged Identity Management (PIM)

Azure is Microsoft's cloud computing platform offering over 200 services. This article covers privileged identity management (pim) with production-ready configurations, best practices, and hands-on examples.

Why PIM Exists: The Problem of Standing Admin Access

In any Azure environment, the most common security failure is not a sophisticated attack—it's an admin who leaves a browser tab open, or a service principal with Contributor rights that never gets rotated. Standing admin access means every credential is a ticking bomb. Privileged Identity Management (PIM) solves this by enforcing just-in-time (JIT) activation: users get elevated roles only when needed, for a limited time, and with approval workflows. Without PIM, you're one leaked token away from a full subscription compromise. I've seen orgs lose entire resource groups because a Global Admin's session was hijacked. PIM is not optional for any production Azure environment.

az rest --method get --uri "https://management.azure.com/providers/Microsoft.Authorization/roleDefinitions?\$filter=type eq 'BuiltInRole'&api-version=2022-04-01" --query "value[?properties.roleName=='Contributor'].{id:id, name:properties.roleName}" -o tsv

PIM Architecture: Roles, Assignments, and Activation Policies

PIM operates on three core concepts: eligible assignments, active assignments, and activation policies. An eligible assignment means a user can request activation for a role, but doesn't have it until approved. Active assignments are permanent—avoid these for humans. Activation policies define max duration (typically 1-8 hours), approval requirements (e.g., must be approved by a security team member), and justification (ticket number, reason). You can also enforce multi-factor authentication (MFA) and conditional access during activation. The architecture is simple: Azure AD holds the role definitions, PIM manages the time-bound grants, and Azure RBAC enforces the permissions. Always use eligible assignments for human users; reserve active assignments for service principals that cannot perform interactive activation.

Connect-AzureAD
$roleDefinitionId = "b24988ac-6180-42a0-ab88-20f7382dd24c" # Contributor
$principalId = "user@contoso.com"
$schedule = New-Object Microsoft.Open.MSGraph.Model.PrivilegedRoleScheduleRequest
$schedule.Type = "AdminAdd"
$schedule.AssignmentState = "Eligible"
$schedule.StartDateTime = (Get-Date).ToUniversalTime()
$schedule.EndDateTime = $schedule.StartDateTime.AddYears(1)
$schedule.Reason = "Onboarding for production support"
$schedule.TicketNumber = "IT-12345"
Open-AzureADPrivilegedRoleAssignmentRequest -ProviderId "aadRoles" -ResourceId "subscriptionId" -RoleDefinitionId $roleDefinitionId -SubjectId $principalId -Type $schedule.Type -AssignmentState $schedule.AssignmentState -StartDateTime $schedule.StartDateTime -EndDateTime $schedule.EndDateTime -Reason $schedule.Reason -TicketNumber $schedule.TicketNumber

Configuring PIM in the Azure Portal: Step-by-Step

To configure PIM, navigate to Azure AD > Privileged Identity Management > Azure AD roles. First, enable PIM for your directory (one-time). Then, under 'Roles', select a role (e.g., Global Administrator) and add an eligible member. Set the activation max duration to 4 hours, require approval from a specific group (e.g., 'PIM Approvers'), and enforce MFA. For Azure resource roles (e.g., subscription Owner), go to 'Azure resources' tab, select your subscription, and manage roles similarly. Always test with a non-production user first. I've seen admins accidentally lock themselves out by removing their own permanent access without setting up an eligible assignment. Have a break-glass account with permanent access for emergencies.

az rest --method put --uri "https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleManagementPolicies/...?api-version=2022-04-01" --body '{"properties":{"rules":[{"id":"ExpirationRule","ruleType":"RoleManagementPolicyExpirationRule","target":{"caller":"Admin","operations":["All"]},"isExpirationRequired":true,"maximumDuration":"PT4H"}]}}'

Automating PIM with PowerShell and Azure CLI

Manual configuration doesn't scale. Use PowerShell or Azure CLI to automate PIM assignments. For Azure AD roles, use the AzureADPreview module (Open-AzureADPrivilegedRoleAssignmentRequest). For Azure resource roles, use az rest with role management policies. Automate the creation of eligible assignments for new hires, and removal on termination. Also automate approval workflows: you can use Logic Apps to send approval requests to Teams or email. I recommend storing PIM configuration as code in a Git repo, using Azure DevOps pipelines to apply changes. This ensures auditability and consistency. Never manually assign roles in production—it's error-prone and untraceable.

Connect-AzureAD
$roleAssignmentRequest = New-Object Microsoft.Open.MSGraph.Model.PrivilegedRoleScheduleRequest
$roleAssignmentRequest.Type = "AdminRemove"
$roleAssignmentRequest.AssignmentState = "Eligible"
$roleAssignmentRequest.RoleDefinitionId = "b24988ac-6180-42a0-ab88-20f7382dd24c"
$roleAssignmentRequest.SubjectId = "user@contoso.com"
$roleAssignmentRequest.Reason = "User offboarded"
$roleAssignmentRequest.TicketNumber = "IT-67890"
Open-AzureADPrivilegedRoleAssignmentRequest -ProviderId "aadRoles" -ResourceId "subscriptionId" -RoleDefinitionId $roleAssignmentRequest.RoleDefinitionId -SubjectId $roleAssignmentRequest.SubjectId -Type $roleAssignmentRequest.Type -AssignmentState $roleAssignmentRequest.AssignmentState -Reason $roleAssignmentRequest.Reason -TicketNumber $roleAssignmentRequest.TicketNumber

Approval Workflows and Justification Requirements

PIM allows you to require approval for activation. This is critical for high-risk roles like Global Administrator or Subscription Owner. Configure approval groups (e.g., 'PIM Approvers') and require a justification (ticket number, reason). Approvers receive email notifications and can approve via Azure Portal or email. For maximum security, enforce that approvers are different from requestors (no self-approval). Also set a maximum activation duration (e.g., 1 hour) and require MFA. I've seen orgs skip approval for 'low-risk' roles like Security Reader—don't. Every activation should be approved and logged. Use Azure Monitor to alert on activations outside business hours.

{
  "properties": {
    "rules": [
      {
        "id": "ApprovalRule",
        "ruleType": "RoleManagementPolicyApprovalRule",
        "target": {
          "caller": "Admin",
          "operations": ["All"]
        },
        "setting": {
          "isApprovalRequired": true,
          "approvalStages": [
            {
              "approvalStageTimeOutInDays": 1,
              "isApproverJustificationRequired": true,
              "isEscalationEnabled": false,
              "primaryApprovers": [
                {
                  "id": "group-id-for-pim-approvers",
                  "type": "Group"
                }
              ]
            }
          ]
        }
      }
    ]
  }
}

Monitoring and Auditing PIM Activations

PIM logs all activations to the Azure AD audit logs and Azure Monitor. You must set up alerts for suspicious activations: multiple activations in a short period, activations from unusual locations, or activations outside business hours. Use Azure Monitor Workbooks to create dashboards showing activation trends. Also export logs to a SIEM (e.g., Sentinel) for correlation. I've seen orgs ignore PIM audit logs until a breach occurs. Regularly review who has eligible assignments—stale assignments are a risk. Automate monthly reports of all eligible assignments and their last activation date. Remove assignments that haven't been used in 90 days.

AuditLogs
| where ActivityDisplayName == "Activate role"
| where TimeGenerated > ago(1h)
| extend User = tostring(InitiatedBy.user.userPrincipalName)
| extend Role = tostring(TargetResources[0].displayName)
| extend IP = tostring(InitiatedBy.user.ipAddress)
| project TimeGenerated, User, Role, IP
| where IP !in ("trusted-ip-range")

PIM for Azure Resources vs Azure AD Roles

PIM supports two scopes: Azure AD roles (e.g., Global Admin, User Admin) and Azure resource roles (e.g., Subscription Owner, Resource Group Contributor). The configuration is similar but there are nuances. For Azure AD roles, activation applies directory-wide. For Azure resources, you can scope to a specific subscription or resource group. This allows granular JIT access. For example, a developer might have eligible Contributor on a dev subscription but not prod. Always use the narrowest scope possible. Also note that PIM for Azure resources requires Azure AD Premium P2. I've seen orgs enable PIM for Azure AD roles but forget to protect Azure resources—attackers pivot through resource permissions.

az role assignment create --assignee "user@contoso.com" --role "Contributor" --scope "/subscriptions/{subscriptionId}/resourceGroups/{rgName}" --assignable-scopes "/subscriptions/{subscriptionId}/resourceGroups/{rgName}" --description "Eligible Contributor on dev RG"

Emergency Access: Break-Glass Accounts and PIM

Even with PIM, you need emergency access accounts that bypass PIM in case of an outage (e.g., Azure AD is down, PIM service degraded). These break-glass accounts should have permanent Global Administrator rights, but be tightly controlled: use complex passwords (20+ characters), store in a physical safe, require two-person approval to use, and audit every usage. PIM can also be used for break-glass by having a separate tenant or using cloud-only accounts. I've seen orgs rely solely on PIM and get locked out when Azure AD experiences a regional outage. Always have a break-glass plan. Test it quarterly.

Get-AzureADAuditSignInLogs -Filter "userPrincipalName eq 'break-glass@contoso.com'" -Top 10 | Select-Object CreatedDateTime, Status, IPAddress

PIM Best Practices for Production Environments

Based on real-world failures, here are non-negotiable best practices: (1) Never assign permanent active roles to humans. (2) Set activation max duration to 1 hour for critical roles, 4 hours for others. (3) Require approval for all roles with write permissions. (4) Enforce MFA on activation. (5) Use conditional access to restrict activation to trusted locations. (6) Automate assignment lifecycle with HR integration. (7) Monitor and alert on all activations. (8) Regularly review eligible assignments and remove unused ones. (9) Have break-glass accounts. (10) Test your PIM configuration quarterly with a red team exercise. I've seen every one of these violated in production, leading to incidents.

{
  "properties": {
    "rules": [
      {"id": "ExpirationRule", "ruleType": "RoleManagementPolicyExpirationRule", "target": {"caller": "Admin", "operations": ["All"]}, "isExpirationRequired": true, "maximumDuration": "PT1H"},
      {"id": "MFA", "ruleType": "RoleManagementPolicyAuthenticationContextRule", "target": {"caller": "Admin", "operations": ["All"]}, "isAuthenticationContextRequired": true, "authenticationContextId": "c1"}
    ]
  }
}

PIM for Groups: Eligible Group Membership

PIM now supports eligible assignments for Azure AD groups, not just roles. This means you can make a user eligible for group membership, and they activate membership just-in-time. This is powerful because group memberships control access to apps, SharePoint sites, and Azure resources via RBAC. For example, create a group 'Prod-DB-Admins' and assign users as eligible members. When they need access, they activate the group membership for a limited time. This reduces the number of individual PIM role assignments needed. For production, use PIM for groups to govern access to applications and resources that don't have their own Azure RBAC roles. Monitor group activations in the same audit log as role activations.

Connect-MgGraph -Scopes 'RoleManagement.ReadWrite.Directory'

# Make a user eligible for a group
$group = Get-MgGroup -Filter "displayName eq 'Prod-DB-Admins'"
$user = Get-MgUser -Filter "userPrincipalName eq 'dev@contoso.com'"

$params = @{
    principalId = $user.Id
    groupId = $group.Id
    action = 'AdminAssign'
    justification = 'Onboarding for on-call DBA rotation'
    scheduleInfo = @{
        startDateTime = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
        expiration = @{ type = 'noExpiration' }
    }
}

New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

PIM and Conditional Access Integration for Activation Security

PIM activation can be protected with Conditional Access policies using authentication context. Configure a CA policy that requires phishing-resistant MFA, compliant device, or trusted IP when a user activates a PIM role. This ensures that even if a user's credentials are compromised, the attacker cannot activate a privileged role from an untrusted device or location. Create an authentication context for 'PIM Activation' and reference it in the PIM role settings. For production, require device compliance and location-based policies for any role with write permissions. This layered defense makes PIM activation significantly harder to exploit.

{
  "displayName": "Require Compliant Device for PIM Activation",
  "conditions": {
    "authenticationContext": {
      "includeAuthenticationContexts": ["c1a2b3c4-d5e6-7890-abcd-ef1234567890"]
    },
    "users": { "includeUsers": ["All"] }
  },
  "grantControls": {
    "builtInControls": ["compliantDevice", "mfa"],
    "operator": "AND"
  }
}

PIM Licensing Strategy: Optimizing P2 License Costs

PIM requires Microsoft Entra ID P2 licenses, but not every user needs one. Only users who will be eligible for, activate, or approve privileged roles need P2 licenses. Regular users with no administrative duties can use P1 or free licenses. A common mistake is assigning P2 to everyone 'just in case,' which inflates costs significantly. The rule: assign P2 only to users with eligible assignments, approvers, and access reviewers. Use groups to manage P2 license assignments and audit quarterly. For production, also consider that P2 includes Identity Protection — if you're using risk-based Conditional Access, factor that into your licensing needs.

# Check which users have P2 vs who needs it
Connect-MgGraph -Scopes 'User.Read.All', 'Organization.Read.All'

$pimUsers = Get-MgRoleManagementDirectoryRoleEligibilityScheduleInstance -All |
  Select-Object -ExpandProperty PrincipalId -Unique

$totalP2 = (Get-MgUser -All | Where-Object {
  $_.AssignedLicenses | Where-Object { $_ -match 'P2' }
}).Count

Write-Host "Users with P2 license: $totalP2"
Write-Host "Users needing P2 (PIM eligible): $($pimUsers.Count)"
Write-Host "Potential savings: $(($totalP2 - $pimUsers.Count) * 9 * 12) USD/year"