Using Privileged Identity Management for just-in-time Azu...

Standing administrative access is one of the most common paths attackers use to escalate privilege inside Azure environments. A compromised account holding permanent Owner or Global Administrator rights gives an attacker unlimited time to act, and it gives your security team a much larger surface to monitor around the clock. Azure conditional access PIM — the pairing of Microsoft Entra Privileged Identity Management with Conditional Access policies — closes that gap by making privileged roles temporary, conditional, and fully auditable. Instead of standing access, eligible users request activation, satisfy an access policy such as MFA, device compliance, or approval, and receive the role for a fixed window before it automatically expires. This guide walks through configuring PIM for just-in-time role activation, layering conditional access controls on top of activation requests, and verifying the whole chain actually works before you rely on it in production.

Step 1: Enable and Scope Microsoft Entra Privileged Identity Management

Before you can enforce just in time access Azure workflows, PIM needs to be turned on and scoped correctly across both Entra ID directory roles and Azure resource roles (subscriptions, resource groups, management groups).

1. In the Azure portal, navigate to Microsoft Entra ID > Privileged Identity Management.
2. Under Manage, select Azure AD roles to onboard directory roles, or Azure resources to discover and onboard subscriptions and management groups.
3. Consent to PIM if this is the first activation in the tenant — this creates the underlying service principal PIM uses to manage eligible assignments.

Once onboarded, convert existing permanent role assignments to eligible assignments wherever possible. A user who is "eligible" for Contributor on a subscription has no standing access — they must explicitly activate the role before it takes effect. This single change is the foundation of every other step in this guide.

Step 2: Configure PIM Role Settings for Just-in-Time Activation

With roles onboarded, define how activation behaves per role. Go to Privileged Identity Management > Azure resources (or Azure AD roles) > Roles, select a role such as Global Administrator or Owner, and open Role settings.

Key settings to configure:

• Activation maximum duration — cap this at 4–8 hours rather than the default; short windows limit the blast radius of a compromised session.
• Require justification on activation — forces a documented business reason for every request.
• Require Azure MFA on activation — ensures the person activating is the person who authenticated, not just a session token replay.
• Require ticket information on activation — ties activation to a change record or incident number for audit trails.

Save the update, then repeat for every sensitive role — Global Administrator, Privileged Role Administrator, Owner, User Access Administrator, and any custom roles with broad write permissions.

Step 3: Layer Azure Conditional Access PIM Policies on Top of Activation

This is where Azure conditional access PIM moves from "time-boxed access" to "context-aware access." Conditional Access policies evaluate the sign-in itself — device state, location, risk level — independently of the PIM activation flow, and you can target them specifically at the activation event.

1. In Microsoft Entra ID > Security > Conditional Access, create a new policy scoped to the Users and groups who hold eligible PIM assignments.
2. Under Cloud apps or actions > User actions, select Register security information is not what you want here — instead, under Conditions, filter for the target resource, or use the built-in "Windows Azure Service Management API" cloud app to catch activation requests made through the portal, CLI, or PowerShell.
3. Under Grant, require both Multi-factor authentication and Require device to be marked as compliant.
4. Under Session, consider adding Sign-in frequency set to a short interval so a stale session cannot silently carry an elevated role forward.

Combining PIM activation policies with a dedicated Conditional Access policy means an attacker needs a compliant, MFA-verified device from an approved location even after they already have valid credentials and an eligible assignment. Neither control alone is sufficient — it's the intersection of Azure conditional access PIM that meaningfully raises the cost of privilege abuse.

Step 4: Require Approval and Justification for Sensitive Roles

For your highest-risk roles, activation should not be self-service. Configure a two-person approval flow:

1. In the role's Role settings, enable Require approval to activate.
2. Add one or more approvers — ideally a security engineer or team lead who is not also eligible for the same role, to avoid self-approval.
3. Approvers receive a notification (email and Azure mobile app) and can approve or deny with a comment, which is retained in the audit log.

This approval gate is one of the most effective Privileged Identity Management best practices because it introduces a human checkpoint at the exact moment risk is highest — when a powerful role is about to become active — rather than relying solely on after-the-fact log review.

Step 5: Set Up Alerts and Access Reviews

PIM ships with built-in alerting for risky patterns: roles being activated too frequently, roles assigned outside of PIM, and duplicate role assignments. Under Privileged Identity Management > Alerts, review each alert category and route notifications to your SOC's email distribution or SIEM ingestion endpoint.

Pair alerting with recurring Access Reviews:

1. Go to Identity Governance > Access reviews > New access review.
2. Scope it to PIM-eligible assignments for a specific role or group.
3. Set a recurrence (monthly or quarterly) and assign reviewers — typically the resource owner, not the requester.
4. Enable auto-apply results so that assignments not confirmed by the review deadline are automatically removed.

Access reviews close the loop on eligibility creep, which is the slow, quiet way just-in-time architectures degrade back into standing access over time.

Step 6: Automate Verification with PowerShell and Azure CLI

Manual portal checks don't scale across dozens of subscriptions. Use the Microsoft Graph PowerShell SDK to script both activation and auditing.

To activate a role programmatically (useful for break-glass automation or CI pipelines that need temporary elevated access):

Connect-MgGraph -Scopes "RoleAssignmentSchedule.ReadWrite.Directory"

$params = @{
    Action           = "selfActivate"
    PrincipalId      = "<object-id-of-user>"
    RoleDefinitionId = "<role-definition-id>"
    DirectoryScopeId = "/"
    Justification    = "Scheduled maintenance window CR-4821"
    ScheduleInfo     = @{
        StartDateTime = (Get-Date)
        Expiration    = @{
            Type     = "AfterDuration"
            Duration = "PT4H"
        }
    }
}
New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params

To audit all currently active PIM assignments across a subscription with Azure CLI:

az rest --method get \
  --uri "https://management.azure.com/subscriptions/<sub-id>/providers/Microsoft.Authorization/roleAssignmentScheduleInstances?api-version=2020-10-01" \
  --query "value[].{principal:principalId, role:roleDefinitionId, endTime:endDateTime}"

Scripting these checks means you can validate PIM role activation state as part of a nightly compliance job rather than trusting that the portal configuration hasn't drifted.

Troubleshooting and Verification

Once the pieces are in place, confirm the chain end-to-end rather than assuming each control is working in isolation.

• Activation succeeds but Conditional Access doesn't seem to fire. Check that the Conditional Access policy targets the correct cloud app. Portal-based activation, PowerShell, and Graph API calls can route through different app IDs; test each channel your users actually use.
• Users report activation is "stuck" on approval. Confirm approvers are correctly assigned in role settings and that they're receiving notifications — a common cause is an approver group with no active members or an approver who is also excluded by their own Conditional Access policy.
• MFA is not being re-prompted on activation. Sign-in frequency and "remember MFA on trusted devices" settings can suppress the re-authentication PIM expects. Set a session control specifically for the PIM-targeted policy rather than relying on tenant-wide MFA settings.
• Access review results aren't removing stale assignments. Verify auto-apply is enabled and that the review has a defined end date; reviews left open indefinitely never trigger cleanup.
• Sign-in logs show activation without a corresponding audit entry. Cross-reference the Entra ID audit log (Directory > Audit logs, filtered to "Add member to role in PIM completed (timebound)") against your SIEM to confirm log forwarding isn't dropping PIM-specific event categories.

Run through each scenario with a test account before rolling the policy out tenant-wide — conditional access misconfigurations that block legitimate activation are far more disruptive to discover in production than in a pilot group.

How Safeguard Helps

Configuring Azure conditional access PIM correctly is necessary, but it only covers identity and access at the control-plane level — it doesn't tell you whether the credentials, service principals, and build pipelines feeding your Azure environment are themselves trustworthy. Safeguard extends the same just-in-time, least-privilege philosophy into your software supply chain: continuously verifying that the CI/CD systems, package registries, and automation identities that ultimately request PIM activations haven't been tampered with upstream.

Safeguard maps privileged Azure roles and PIM-eligible assignments against the pipelines and service connections that use them, flagging cases where a build system has standing access it no longer needs, or where an activation pattern deviates from historical baselines in a way that suggests credential compromise rather than legitimate maintenance. Combined with the access reviews and approval workflows above, Safeguard gives security teams a single view of both human privilege escalation and machine-identity risk — so the same discipline you apply to Privileged Identity Management best practices for people extends to every automated identity touching your cloud infrastructure.