PIM for Groups and access reviews: govern privileged group membership

PIM for Groups in Microsoft Entra ID turns membership and ownership of a security or Microsoft 365 group into something users activate just in time, with MFA, justification or approval, instead of holding permanently. To govern a privileged group, create it as role-assignable, bring it under Privileged Identity Management, configure the Member and Owner settings, make people eligible rather than active, and then run a recurring access review that covers both eligible and active members so stale access is removed automatically.

Who this is for and what you will have at the end

This guide is for identity and security administrators who already use groups to grant access to Entra roles, Azure roles, Intune, Key Vault or line-of-business apps, and want the same just-in-time control they get from PIM for individual roles. If you haven't set up PIM for Entra roles yet, start with the role side first; the concepts carry over.

At the end you will have:

• A role-assignable group managed in PIM for Groups, with no permanent members.
• Activation rules for members and owners: maximum duration, MFA or authentication context, justification and approval.
• Eligible assignments that expire, created in the portal or with Microsoft Graph PowerShell.
• A recurring access review that recertifies eligible and active members and applies the results.

How PIM for Groups works

Each group in PIM for Groups has two independent policies: one for membership and one for ownership. An eligible member who activates is added to the group within seconds and removed within seconds when the activation ends or is cancelled. Anything that grants access through the group, such as a role assignment, an app role or an Azure RBAC assignment, follows that membership.

Role-assignable versus ordinary groups

The second row is why Microsoft recommends role-assignable groups for any group that grants sensitive access: with an ordinary group, a lower-privileged admin could reset an eligible user's password and activate on their behalf. For the same reason, Microsoft recommends requiring approval for eligible member assignments on groups used to elevate into Entra roles.

Limits to know before you start

• Dynamic groups and groups synchronized from on-premises can't be managed in PIM for Groups.
• Groups in restricted management administrative units aren't supported.
• Once managed, a group can't be taken out of PIM management.
• Role-assignable groups can't have other groups as active members, but a group can be an eligible member of another group. When a user activates through such a nested eligibility, only that user becomes active, not the whole group.
• Administrators and owners can still change membership through the normal Groups experience, which overrides PIM. Restrict who holds those rights.

Licensing and roles

PIM doesn't honour permissions that start with microsoft.directory/groups.security/ or microsoft.directory/groups.unified/ in custom roles; use the microsoft.directory/groups/ permissions instead.

Prerequisites

• The licences above.
• A Conditional Access authentication context and policy if you want stronger checks at activation (Step 4).
• Two or more approvers per group if you require approval.
• Microsoft Graph PowerShell (Microsoft.Graph.Groups and Microsoft.Graph.Identity.Governance) if you want to script it.
• Emergency access accounts that don't depend on any PIM group.

Step 1: Create a role-assignable group

In the admin center, sign in as at least a Privileged Role Administrator, go to Entra ID > Groups > All groups > New group, and set Microsoft Entra roles can be assigned to the group to Yes. Leave members empty. You're asked to confirm, because this setting can't be changed later.

With PowerShell:

Connect-MgGraph -Scopes "Group.ReadWrite.All"
 
$group = New-MgGroup -DisplayName "PIM-Intune-Administrators" `
    -Description "Eligible members activate to receive Intune Administrator" `
    -MailEnabled:$false -SecurityEnabled -MailNickName "pim-intune-admins" `
    -IsAssignableToRole:$true

Step 2: Bring the group under PIM

1. Go to ID Governance > Privileged Identity Management > Groups.
2. Select Discover groups, select the group and select Manage groups > OK.

The group now appears in the PIM Groups list. If it doesn't appear in discovery, check that it isn't dynamic, synced from on-premises, or in a restricted management administrative unit.

Step 3: Configure Member and Owner settings

Open the group, select Settings, select Member, then Edit. Repeat for Owner. The settings are independent per group and per role.

On the Notifications tab, send activation and assignment alerts to a monitored mailbox in addition to the defaults. A single event notifies at most 1,000 recipients.

Note that the simple MFA option may not prompt a user who already has a strong credential or did MFA earlier in the session. If you need a fresh, specific check at every activation, use an authentication context.

Step 4: Protect activation with an authentication context

1. In Conditional Access, create an authentication context, for example PIM group activation.
2. Create a Conditional Access policy that targets that authentication context and requires what you need, such as the Phishing-resistant MFA authentication strength and a compliant device. To force reauthentication on every activation, add Sign-in frequency set to Every time.
3. Scope the policy to all users, or to the eligible users. Don't scope it to the PIM group itself: at activation time the user isn't a member yet, so the policy wouldn't apply.
4. Back in the group's Member settings, select On activation, require Microsoft Entra Conditional Access authentication context and pick the context.

Create and enable the Conditional Access policy before you reference the context in PIM. As a safety net, if no policy targets the context, PIM falls back to requiring MFA, but that fallback doesn't trigger if the policy is off, in report-only mode, or excludes the eligible users.

After one reauthentication, a 10-minute window applies across Entra roles, Azure resource roles and PIM for Groups, so a second activation within that window doesn't prompt again. Also remember that the authentication context checks only the activation. To require a compliant device for every use of the elevated access, scope a separate Conditional Access policy to the eligible users. Anyone who can edit Conditional Access policies can weaken these requirements, so treat Conditional Access Administrators as highly privileged. For the wider design, see the zero trust remote access architecture.

Step 5: Make users eligible

In the portal:

1. Open the group in PIM and select Assignments > Add assignments.
2. Under Select role, choose Member (or Owner) and select the users.
3. Select Next, set Assignment type to Eligible, set an end date, and select Assign.

Assignments can't be shorter than five minutes and can't be removed within five minutes of being created.

With Microsoft Graph PowerShell:

Connect-MgGraph -Scopes "PrivilegedEligibilitySchedule.ReadWrite.AzureADGroup"
 
$params = @{
    accessId      = "member"
    principalId   = "<user object ID>"
    groupId       = $group.Id
    action        = "AdminAssign"
    justification = "Intune administration rota Q4"
    scheduleInfo  = @{
        startDateTime = [System.DateTime]::Parse("2026-10-12T00:00:00Z")
        expiration    = @{
            type        = "AfterDateTime"
            endDateTime = [System.DateTime]::Parse("2027-01-12T00:00:00Z")
        }
    }
}
 
New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest -BodyParameter $params

The same request with action = "AdminExtend" extends an eligibility before it expires, and "AdminRenew" renews an expired one. For a role-assignable group, the caller needs Privileged Role Administrator; for other groups, roles such as Groups Administrator or Identity Governance Administrator work.

Finally, remove any remaining permanent active members so that eligibility is the only path in.

Step 6: Connect the group to the privilege

Assign the privilege to the group: an Entra role, an Azure role, an Intune role, or an app role. For Entra roles there are two patterns:

Microsoft warns that the second pattern can take significant time to make SharePoint, Exchange and Purview permissions usable after activation, and recommends PIM for Entra roles directly for those workloads.

If the group is assigned to an enterprise app with provisioning, activation triggers provisioning of the membership within 2 to 10 minutes. Beyond five activations within 10 seconds for the same app, requests are throttled and later ones wait for the next 40-minute sync cycle.

Step 7: Activate

Eligible users go to ID Governance > Privileged Identity Management > My roles > Groups (or https://aka.ms/pim), select Activate on the assignment, complete any MFA or authentication context prompt, set a start time if needed, enter a reason and select Activate. Pending approvals appear under My requests > Groups, where they can also be cancelled.

Applications may cache group membership. If access doesn't appear straight after activation, or doesn't disappear after it ends, signing out and back in often resolves it.

Step 8: Recertify membership with an access review

Eligibility that is never reviewed becomes standing access by another name. Access reviews of PIM for Groups (currently in preview) include both eligible and active members.

1. Sign in as at least an Identity Governance Administrator and go to ID Governance > Access Reviews > New access review.
2. Select Review access to a resource type, then Teams + Groups > Select Teams + groups, and pick the PIM-managed groups. Each selected group becomes its own review.
3. Set the user scope to Everyone. Optionally restrict it to Inactive users (on tenant level) with a number of days inactive, up to 730.
4. Choose reviewers. If you choose Group owner(s), you must add a fallback reviewer: only active owners are assigned, eligible owners aren't, and fallback reviewers are used if no owner is active when the review starts. Selected user(s) or group(s), such as a security team, avoids that dependency.
5. Set Duration (in days), the recurrence, start date and end.
6. Under Upon completion settings, select Auto apply results to resource and choose what happens If reviewers don't respond: No change, Remove access, Approve access or Take recommendations.
7. Under Enable review decision helpers, select No sign-in within 30 days so reviewers see a recommendation and last sign-in.
8. Under Advanced settings, turn on Justification required, Email notifications and Reminders.
9. Name the review and select Create.

Microsoft warns that combining Remove access or Take recommendations with auto-apply can remove all access if reviewers don't respond. For privileged groups that is usually acceptable, since users can request eligibility again, but agree it with the group owners first. Also note that reviews flatten nested groups: a user denied through a nested group is removed only from direct membership, not from the nested group.

Verify

• In PIM, open the group and check Assignments: Eligible assignments should list your users with end dates; Active assignments should be empty except during activations.
• Resource audit on the group shows every assignment, activation and settings change; My audit shows a user's own activity.
• Activate as a test user and confirm the privilege works, then confirm it disappears when the activation ends.
• After the first review completes, check the results and confirm denied users were removed.

Troubleshooting

The authentication context policy never prompts. The Conditional Access policy is scoped to the group, so it can't apply before activation. Scope it to users instead.

An owner's activation won't end. Entra ID doesn't allow removing the last active owner. PIM keeps trying to deactivate for up to 30 days; add another active owner so deactivation succeeds, or the owner stays active after 30 days.

Exchange or SharePoint admin rights arrive late. You're using an active group-to-role assignment with eligible members. Switch to the pattern where the group is eligible for the role.

The role-assignable option isn't shown when creating a group. The Microsoft Entra roles can be assigned to the group option is shown to Privileged Role Administrators, the role that can set it. Sign in with that role, and check that the tenant has Microsoft Entra ID P1 or P2.

Group owners aren't receiving the access review. Only active owners are reviewers; eligible owners aren't. Check the fallback reviewer, or use selected reviewers.

PIM changes are being undone. Someone is editing membership through the Groups blade or another interface, which overrides PIM. Remove standing group management rights from those accounts.

Checklist

• Privileged groups are role-assignable, cloud-only and managed in PIM.
• No permanent active members or owners; eligible assignments expire.
• Member and Owner settings configured separately, with approval and two approvers where the group grants Entra roles.
• Activation protected by an authentication context policy scoped to users.
• Exchange, SharePoint and Purview roles use the group-eligible-for-role pattern.
• Recurring access review covering eligible and active members, with fallback reviewers and auto-apply.
• PIM notifications routed to a monitored mailbox.

References

• Privileged Identity Management (PIM) for Groups
• Bring groups into Privileged Identity Management
• Configure PIM for Groups settings
• Assign eligibility for a group in PIM
• Activate your group membership or ownership in PIM
• Audit activity history for group assignments in PIM
• Create a role-assignable group in Microsoft Entra ID
• Create eligibilityScheduleRequest (PIM for Groups)
• Create an access review of PIM for Groups (preview)
• Create an access review of groups and applications