How to Configure Microsoft Entra PIM for Least-Privilege Access

Treat PIM as an operating model for privileged access, not a compliance feature. Its value comes from making elevated access exceptional, bounded and accountable while preserving a tested route for legitimate administration.

This guide covers the three main PIM workloads—Microsoft Entra roles, Azure resource roles and privileged groups—and the operating controls that keep eligible access usable in practice.

The usual failure isn’t an administrator being unable to activate a role. It’s permanent access left in place, nobody owning approvals, an unclear emergency route, and audit data nobody reviews. The aim is to avoid that while keeping Microsoft 365, Microsoft Entra ID and Microsoft Azure administration workable.

Start with the three things PIM can manage

Administrators often use “PIM” as though it were one privilege system. The portal actually separates three related jobs, and the distinction matters.

• Microsoft Entra roles are directory roles: Global Administrator, Privileged Role Administrator, Exchange Administrator, User Administrator and similar roles used to administer Entra and many Microsoft 365 services. Microsoft 365 admin roles appear here, but PIM doesn’t govern every fine-grained permission inside Exchange role-based access control (RBAC) or SharePoint RBAC.
• Azure resource roles are Azure role-based access control (RBAC) assignments at management-group, subscription, resource-group or individual-resource scope. Owner, User Access Administrator and Contributor are familiar examples. Someone who needs to operate one resource group shouldn’t receive subscription-wide access for convenience.
• PIM for Groups makes membership or ownership of an Entra security group or Microsoft 365 group eligible and time-bound. It is useful where a group grants access to an application, a vault, Intune, Azure SQL or an Entra role. It isn’t a reason to hide a powerful directory role behind an unmanaged, nested group.

That last point needs care. Role-assignable Entra groups are specially protected groups that can receive Entra roles, but they have restrictions: they must be created as role-assignable from the outset, cannot be nested, and should be tightly controlled. PIM can make members eligible for a role granted through such a group, but the group design remains part of the security boundary. Read Microsoft’s guidance on role-assignable groups before standardising on this pattern.

Prerequisites

• Licensing: check that the tenant has valid Microsoft Entra ID P2 or Microsoft Entra ID Governance licensing, and assign appropriate licences to people receiving eligible or time-bound PIM assignments. Don’t assume a Microsoft 365 plan includes PIM; entitlement varies by SKU and changes over time. Microsoft’s PIM licensing guidance is the authoritative starting point.
• Administrative access: for Entra role settings, use a Privileged Role Administrator or Global Administrator. Azure resource PIM has different control-plane permissions, commonly Owner or User Access Administrator at the relevant scope. Use a separate administrative account where the operating model permits it.
• An accurate privilege inventory: include direct assignments, group-derived access, service accounts, automation identities, external users and old Azure subscriptions. PIM can’t correct privileges nobody has discovered.
• Emergency access: create and test two cloud-only emergency accounts with permanent Global Administrator assignments before making all ordinary Global Administrators eligible. Keep their credentials protected, their use exceptional and their sign-ins actively monitored. Microsoft explicitly recommends two such accounts in its administrator security planning guidance.
• Authentication and logging: ensure administrators can satisfy multifactor authentication (MFA) requirements, including when working remotely or during an incident. Configure diagnostic settings to retain Entra audit and sign-in logs in Log Analytics, a storage account, Event Hub or an appropriate security platform.
• A safe change window: don’t convert every Global Administrator at once. Retain a tested recovery route and record the current assignments and PIM policy settings so they can be restored if an approval or Conditional Access design breaks.

1. Design the role model before assigning anything

Start with jobs, not people. List the administrative tasks that must happen: reset user passwords, manage Exchange, change Conditional Access, administer subscriptions, recover a tenant, operate a production workload. Map each task to the least powerful built-in or custom role at the narrowest workable scope.

Global Administrator isn’t a normal operations role. Reserve it for tenant-level recovery and work that genuinely can’t be delegated. In many tenants, Exchange Administrator, SharePoint Administrator, Authentication Administrator, Security Administrator, User Administrator and Privileged Role Administrator remove much of the routine demand for Global Administrator. In Azure, Owner at an entire subscription is often excessive when Contributor on one resource group plus a separate, tightly governed User Access Administrator route is enough.

Make three classifications while doing this:

• Standing active: rare. Use it only where a technical dependency genuinely prevents just-in-time activation, and give it an owner and expiry date.
• Eligible: the normal choice for human administrators. The person has no active privilege until they activate it under the relevant policy.
• Emergency access: deliberately permanent, tightly protected cloud-only accounts for a failure of ordinary administration. These aren’t day-to-day administrator accounts with a dramatic name.

Include privileges delivered through groups. If a security group gives access to a production application rather than an Entra directory role, PIM for Groups may be the cleanest control. If the objective is just-in-time Exchange or SharePoint administration, use PIM for the Entra role rather than assuming group membership will model the service’s own granular permissions.

2. Pilot eligible assignments, then remove permanent access

1. Choose a low-risk but meaningful pilot role, such as an administrative role used by a small support team. Don’t begin with the entire Global Administrator population.
2. In the Microsoft Entra admin centre, open ID Governance > Privileged Identity Management, then choose Microsoft Entra roles, Azure resources or Groups according to the access being governed.
3. Assign selected pilot users as Eligible, not Active. Give the assignment an end date unless there is a documented reason for enduring eligibility.
4. Ask each pilot user to activate, complete a normal administrative task, deactivate, and record the friction: missing MFA registration, unclear role naming, insufficient duration, unavailable approvers or an overlooked dependency.
5. Remove the pilot users’ direct permanent assignment only once that route is proven. Repeat in manageable batches.

Eligible doesn’t mean harmless. It means the user can acquire the role if they satisfy the policy. Review eligibility itself, and grant it only to named people with an ongoing operational reason.

3. Set activation policy by risk, not by habit

PIM role settings are configured per role. Strong controls for Global Administrator don’t automatically apply to Exchange Administrator, subscription Owner or a privileged group. It’s an easy gap to miss. Microsoft documents the available role-policy controls in its PIM role settings documentation.

A workable baseline is:

For the most powerful roles, choose at least two named approvers or a carefully managed approver group. Approval requests expire after 24 hours if they aren’t acted on, and Microsoft warns of a lockout condition where all Privileged Role Administrators and Global Administrators are eligible, approval is required, and no approvers are configured. Emergency accounts and explicit approvers aren’t optional design niceties.

There is no universal “correct” activation duration. A service-desk administrator resetting accounts may need a short session; a planned Azure recovery operation may reasonably need longer. The right duration is short enough to reduce exposure but long enough that staff don’t learn to activate repeatedly as a workaround. Review actual activation data after the pilot rather than guessing.

PIM’s MFA prompt should complement, not replace, Conditional Access and strong authentication design. Administrators still need resilient authentication methods. Test the authentication journey before an emergency, particularly if your tenant is moving administrators away from SMS or voice methods; Entra ID’s move from SMS and voice MFA to passkeys has practical implications for that test.

4. Configure approvals so they work at 03:00, not just in a demo

Approval is most useful when it is selective. Requiring it for Global Administrator, Privileged Role Administrator, subscription Owner, User Access Administrator and powerful production groups is defensible. Requiring it for every low-impact administration task can push staff towards standing access, shared accounts or informal escalation routes.

Write down the approval standard: what evidence the requester supplies, who may approve, how an emergency is handled, and who checks approvals retrospectively. An approver doesn’t need to hold the role being requested, which makes separation of duties possible. It also means approver membership needs the same care as privileged access.

Test failure cases deliberately: an approver is on leave; a support request has no ticket number; MFA is unavailable; the requester needs a role outside office hours; a critical change outlives the configured activation window. The point isn’t to remove friction. It’s to make sure legitimate friction has an owner and an escalation route.

Expected result and how to verify it

After rollout, ordinary administrators should appear as eligible for their assigned roles and become active only for the limited duration selected during activation. A request should show its justification, ticket reference where required, MFA and approval outcome. At expiry or deactivation, the active assignment should disappear.

Verify this with a controlled test account, not merely a screenshot of policy settings:

1. Activate one eligible Entra role and confirm that MFA, justification, ticket and approval requirements behave as designed.
2. Use the role to complete a harmless authorised task, then check that the role is unavailable after manual deactivation or expiry.
3. Inspect Resource audit in PIM for the assignment, activation and policy events. For Entra roles, PIM’s resource audit view covers role-management events for 30 days; longer investigations need exported activity logs.
4. Confirm the same activation and sign-in can be found in the central logging destination, along with an alert or review workflow for high-risk events.
5. Test emergency-account access under a controlled exercise, then review the alerting and incident record. Don’t wait for a tenant lockout to discover that the credentials or exclusion logic is wrong.

5. Review, alert and retain evidence

Access reviews are where PIM stops being a one-off clean-up project. Schedule reviews of eligible and active assignments, concentrating first on Global Administrator, Privileged Role Administrator, Azure Owner, User Access Administrator, security roles and privileged groups. The reviewer should be able to answer one question: does this person still need this specific route to privilege?

There are limits. A review may not remove access inherited through a nested group or through a synchronised on-premises group that Entra can’t change. Treat failed application of review results as a finding, not an administrative footnote. Microsoft’s role access-review guidance explains these practical caveats.

Turn on and triage PIM security alerts. Useful starting points include assignments made outside PIM, roles that don’t require MFA for activation, excessive activation renewals and long-unused privileged assignments. Alerts are prompts for investigation, not proof of compromise; a rare activation might be a legitimate recovery job, while a normal-looking one paired with unusual sign-ins deserves attention.

Don’t depend solely on the portal’s short audit window. Route Entra audit and sign-in logs to a managed destination with retention aligned to security, regulatory and incident-response needs. Microsoft Entra diagnostic settings can send activity logs to Azure Monitor, Event Hub or storage. That lets security teams correlate PIM elevation with sign-in risk, Conditional Access outcomes and subsequent administrative changes.

Common PIM mistakes

• Converting administrators to eligible before creating emergency access. This is how approval designs turn into lockouts.
• Leaving permanent active assignments untouched “temporarily”. Temporary exceptions have a habit of becoming the real access model. Time-box them and review them.
• Applying the same policy to every role. High-impact tenant roles, routine support roles and Azure workload roles don’t have identical operational risks.
• Using Global Administrator as a shortcut for Azure administration. Scope Azure permissions in Azure RBAC; don’t broaden directory privilege to compensate for an unclear subscription model.
• Making approvers a single person or a dormant mailbox. Approval needs availability, ownership and testing.
• Assuming PIM for Groups fixes poor group design. Uncontrolled ownership, dynamic membership and indirect access can still produce privilege-escalation paths.
• Ignoring service principals and automation. PIM primarily changes the human privileged-access workflow. Review application permissions, managed identities, secrets and workload identities separately.

Ongoing maintenance checklist

• Weekly: review high-impact activations, denied or expired approval requests, PIM security alerts and unexpected policy changes.
• Monthly: check permanent active assignments, stale eligible users, approver coverage, notification recipients and central-log ingestion.
• Quarterly: run access reviews for high-impact roles and privileged groups; test a normal activation and the emergency route.
• After organisational change: remove leavers, contractors and role-changers promptly; update approver groups and escalation documentation.
• After a major tenant or Azure change: reassess scopes, custom roles, new subscriptions, new administrative services and automation identities.

Rollback and troubleshooting

If a policy prevents legitimate administration, don’t weaken the entire tenant in haste. Use a protected emergency account to restore access, identify whether the fault is licensing, role scope, authentication registration, approval configuration or Conditional Access, then correct that specific dependency. A narrowly scoped active role with a firm end date can be assigned temporarily while the PIM design is repaired, but document the exception and remove it afterwards.

When activation fails, check the basics in order: whether the user is eligible for the correct role and scope; whether their licence is present; whether the activation policy requires MFA, justification, a ticket or approval; whether the approver exists and can act; and whether Conditional Access or device requirements block the session. Then inspect PIM Resource audit, Entra audit logs and sign-in logs together. Looking at only one view often explains only half the failure.