Azure PIM: A Practitioner's Guide to Just-in-Time Privileged Access

PIM is specifically for Entra ID directory roles and Azure RBAC resource roles. It governs eligibility and activation for roles like Global Admin, Privileged Role Admin, Exchange Admin, Owner on a subscription, and Contributor on a resource group. When a user is eligible for a role, the role does not appear in their effective permissions until they activate it, at which point it is added for a defined time window. After expiration, the role drops off automatically. The model assumes the user can authenticate to the tenant; PIM does not protect against credential compromise on its own, only against the consequences of compromise during the unprotected windows when no role is active. This is why MFA and Conditional Access on activation are non-negotiable. PIM is not a substitute for a privileged access management tool in the on-premises or application-level sense. CyberArk, BeyondTrust, Delinea, and equivalents handle credential vaulting, session recording, and privilege for on-prem AD, databases, network devices, and applications outside Microsoft's identity perimeter. PIM and a PAM tool complement each other: PIM governs cloud directory and RBAC roles, the PAM tool governs everything else. Conflating them produces gaps in both directions.

Start by inventorying current permanent assignments to high-impact roles: Global Administrator, Privileged Role Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, Security Administrator, Application Administrator, Cloud Application Administrator, Authentication Administrator, Privileged Authentication Administrator. For each user with permanent assignment, convert to eligible assignment via the PIM blade. Configure role settings before converting users; the settings apply at activation time and getting them wrong propagates immediately. Recommended baseline settings for Global Administrator: activation duration of 1 to 4 hours, never 8 hours unless a documented justification exists; MFA on activation, with a separate MFA prompt distinct from sign-in MFA; justification required with a minimum character count to prevent one-word entries; approval required by at least one other privileged role admin; notification on activation to a security distribution list. For other privileged roles, similar settings with role-appropriate activation durations and approval requirements. Avoid eligibility for service accounts; service principals should use managed identities or workload identity federation, not PIM eligibility. Document the configuration as code via Microsoft Graph or Terraform; the PIM portal does not show configuration history, and drift over time is the most common audit finding.

Directory roles govern Entra ID itself; Azure RBAC roles govern Azure resources. PIM extends to Azure RBAC and the configuration model is identical but applied at the management group, subscription, or resource group scope. The high-impact roles to govern with PIM are Owner, User Access Administrator, and Contributor on subscriptions and production resource groups. Reserved Instances Administrator and Billing Reader are lower risk and can remain permanent for operational simplicity. Apply eligibility at the highest reasonable scope to reduce assignment count; managing 200 individual resource group eligibilities is operationally painful and prone to error. Prefer management group or subscription eligibility with role-based scoping rather than per-resource-group assignment. For production subscriptions, require approval on activation and short activation windows. For development subscriptions where engineers need frequent access, longer windows without approval may be appropriate, with the explicit acknowledgment that the data sensitivity is lower. Monitor for permanent assignments at the subscription level; these accumulate through application deployment scripts that assign Owner to service principals, and should be reviewed against the principle of least privilege quarterly.

Eligibility accumulates. An engineer changes teams, a project ends, a contractor leaves, and the eligible assignment persists because no one revoked it. Within 18 months, a tenant that started with clean PIM hygiene will have eligible assignments for users who no longer need them, and the attack surface grows quietly. PIM access reviews are the structural control. Configure quarterly reviews for every privileged role, scoped to the role's eligible members. The review owner should be the manager of the eligible user, not the security team; security teams cannot evaluate need-to-have for hundreds of users, and managers can. For high-privilege roles like Global Admin, add a secondary review by the CISO or designated security lead. Configure auto-revoke on no-response after 14 days; reviewers who do not respond effectively approve continued access, which is the wrong default. Use the PIM review API to extract review results programmatically and feed them into a quarterly access governance report; relying on the portal UI for reporting hides trends. Track the revocation rate per review; healthy reviews should revoke 5 to 15 percent of assignments quarterly. A 0 percent revocation rate means the reviewers are rubber-stamping, not reviewing.

PIM activity produces Entra ID audit log events that must reach your SIEM. The events to monitor include RoleAssignmentActivated, when a user activates an eligible role; RoleAssignmentDeactivated, when activation expires or is explicitly ended; RoleEligibilityCreated, when a user becomes eligible for a role; RoleAssignmentCreated with a permanent assignment, which should be near zero in a mature tenant outside break-glass accounts; and AdminMFAFailed during activation, which indicates either a misconfigured user or active attack against an admin account. Build detections around these events. Alert on any RoleAssignmentCreated to a high-privilege role with a permanent rather than time-bound assignment; investigate immediately. Alert on activation outside of business hours or from unusual geographies. Alert on multiple failed activation attempts followed by a successful one, which can indicate credential compromise with MFA fatigue. Correlate activation events with the user's downstream activity; an admin who activates Global Admin and performs no actions during the window may have been a session takeover target. Include break-glass account sign-ins as a separate high-priority alert with explicit on-call paging; these accounts should sign in essentially never.

Break-glass accounts are the failsafe when PIM, Conditional Access, or the tenant itself misbehaves. Configure two of them. Two, because one is a single point of failure and three is operational overkill. Each account is cloud-only, meaning created directly in Entra ID and not synchronized from on-prem AD; on-prem identity issues must not block break-glass access. Each is assigned Global Administrator permanently, the exception that proves the rule, because activation flows might be the thing that is broken. Each is excluded from every Conditional Access policy explicitly, by named user exclusion rather than group exclusion, because group exclusions are easier to misconfigure. Each authenticates with hardware FIDO2 keys only; no passwords, no SMS, no authenticator app. The keys are stored in separate physical locations, ideally a safe in the security office and a safe in a senior leader's home or a secure off-site location, with documented retrieval procedures. Sign-in to break-glass accounts triggers a high-priority alert paging the security on-call, regardless of time of day; legitimate use is exceedingly rare and any sign-in deserves immediate investigation. Test break-glass account sign-in quarterly to verify the keys work and the alerting fires; an untested break-glass account is no break-glass account at all.