By the end of this sheet you have a quarterly recurring review of who is eligible for Global Administrator, with named reviewers, results that apply themselves, and a proven removal: you will deny a test assignment, watch it disappear from the directory, and find the event in the audit log. You will also know exactly which part of your tier-group model this cannot review on a P2 licence, because that boundary is real and it is better met here than in a design review.
Before you start
You need Microsoft Entra ID P2 or Microsoft Entra ID Governance covering every user assigned to a review and every user who performs one, which means your reviewers consume licences whether or not they hold any privileged role themselves. You need at least Privileged Role Administrator to create the review in PIM. You want the earlier work in place, so Global Administrator is held eligible by a known population, because a review of a role nobody has converted yet is a review of a problem rather than a control. And you need a disposable test assignment, meaning a real account you are willing to have access removed from, because the end-to-end test is the point of this sheet and it cannot be done by inspection.
One thing to decide before you touch anything: who signs off. A review with no owner produces decisions nobody defends, and the single most common failure of access review programmes is that they generate work for people who have no authority to say no. Name the person who owns the tier before you create the object.
Step 1: Create it in PIM, not in the Access Reviews blade
Go to ID Governance, then Privileged Identity Management, then Microsoft Entra roles. Under Manage, select Microsoft Entra roles again, then Access reviews, then New. For Azure resource roles the path is the same except that you select Azure resources and pick the subscription first.
This location is not a detail. Reviews of Entra roles and Azure resource roles are created here and not in the general Access Reviews blade, and the consequence bites organisations that have standardised on that blade: a security lead who looks there for privileged access reviews will find none and reasonably conclude the tenant has none. If you run any kind of review programme, write down which reviews live where, because the product does not present them in one place.
Give the review a name that will still be legible on its eighth recurrence. I use the pattern AR-PIM-<Role>-<Cadence>, so this one is AR-PIM-GlobalAdministrator-Quarterly. Reviews accumulate faster than anything else in this product, for a reason that is worth knowing now rather than discovering: selecting several roles does not create one review covering them all, it creates one review per role. Pick five roles and you have five reviews, five sets of reviewer assignments, and five sets of results to apply. Start with one.
Step 2: Scope it, and understand what each scope asks
Select Global Administrator as the role, then set the assignment type. The three options are eligible assignments only, active assignments only, and all active and eligible assignments, and they are three different questions rather than three degrees of the same one.
| Setting | Value | Why |
|---|---|---|
| Assignment type | eligible assignments only | This asks who should still be able to become a Global Administrator, which is the governance question and the one that keeps the estate small. In a converted tenant this is where the entire population lives. |
| Frequency | Quarterly | Fast enough that a departure is caught within a working quarter, slow enough that reviewers still read it. Monthly reviews of a privileged role produce reflexive approval, which is worse than no review because it manufactures evidence of diligence. |
| Duration | 14 days | Long enough to survive a holiday, short enough to stay urgent. Duration is capped to stop instances overlapping; a monthly review, for instance, can run at most 27 days. |
| Start date | The first working day of a quarter | Line reviews up with something in the calendar that already exists. A review whose deadline is invisible to the business gets treated as optional. |
Run a separate one-off review scoped to active assignments only as well, at least once, and read it as an integrity check rather than as a review. In a tenant that has done the work in this wave, that report should contain your emergency access accounts and essentially nothing else. If it contains a list of people, the conversion did not finish or it has already decayed, and you have learned that more cheaply than any audit would have told you.
Leave the inactive-users scoping alone for a privileged-role review. It exists, it can scope up to 730 days, and it is the wrong instrument here: a Global Administrator who has not signed in is not less of a liability than one who has, and filtering them out of the review removes exactly the assignments you most want somebody to look at. One licensing note if you were considering reviewing service principals: those reviews additionally require Microsoft Entra Workload ID Premium.
Step 3: Reviewers, with a worked example
The reviewer options are Selected users, Members (self), and Manager with a fallback reviewer for anyone who has no manager in the directory.
Worked example. The quarterly Global Administrator review at a mid-sized organisation names two reviewers under Selected users: the head of infrastructure, who owns the tier and knows what each person actually does, and the information security manager, who has no privileged role and whose job in this exercise is to ask why. Two rather than one, because a single reviewer on annual leave stalls the whole instance, and because a second pair of eyes on a list of Global Administrators is cheap. Neither reviewer is drawn from the reviewed population, which is the design decision doing the real work here.
I do not use Members (self) for privileged roles, and I want to be precise about the status of that opinion. It is a supported option, Microsoft documents it without any caution, and Discovery and insights will actively offer to have all Global Administrators review their own access. My position is practitioner guidance, not Microsoft’s: asked whether they still need to be able to become a Global Administrator, almost everyone who currently can will say yes, and a control whose answer is predictable is not a control. Self-review has real uses in high-volume, low-stakes access where named reviewers do not scale. This is neither.
If you do choose Manager, set the fallback reviewer deliberately rather than as an afterthought, because it catches more than you expect: role-assignable groups holding the role are reviewed by the fallback reviewer, since a group has no manager. Under Members (self) those groups are excluded from the review entirely.
Step 4: The completion settings, which decide whether any of this does anything
| Setting | Value | Why |
|---|---|---|
| Auto apply results to resource | Enable | The single most important switch on the page. Disabled, denied users keep their access until a human remembers to apply the results by hand, and the predictable outcome is a folder of completed reviews and an unchanged tenant. Enabled, the removals happen on their own. |
| If reviewers don’t respond | Remove access | This is the Global Administrator review, and the top role does not get the general answer. No change means silence preserves access, which turns a busy quarter into a rubber stamp, and that argument is as correct here as anywhere. Take recommendations is the one that looks safe and is not: the recommendation is a sign-in signal, it does not count role activations, so an eligible Global Administrator who has never once activated the role but opens mail every morning is recommended for approval, and with auto apply enabled that renews the tenant’s highest privilege with nobody in the loop. A review nobody answered is not a neutral event at this role. It means no one was willing to vouch for the assignment, and the honest reading of that silence is removal. Keep Take recommendations on the lower tiers, where the argument for it does hold. |
| Understanding the recommendation | Based on a 30-day sign-in window | Know what you are trusting. Recommendations approve users who have signed in within the last 30 days and recommend denial for those who have not, and the window counts both interactive and non-interactive sign-ins, which is broader than most people assume. It is a proxy for activity, not for need: someone who signs in daily and has not used the role in a year will be recommended for approval. |
| Action to apply on denied guest users | Not editable here | For Entra and Azure role reviews this setting cannot be changed, and denied users always lose access to the role regardless of whether they are guests. Worth knowing so you do not go looking for it. |
State the cost of that choice rather than discovering it. Microsoft’s own caution on the setting is that enabling auto apply together with a default decision risks revoking access for every principal in scope if the reviewers fail to respond, and on this review that is the intended behaviour rather than a side effect, which is why Step 3 names two reviewers instead of one. It can also strip a legitimate holder, who then has to be made eligible again. That is a phone call and a few minutes of work, and it is small next to a standing Global Administrator eligibility that renews itself because somebody reads email. Your emergency access accounts are not exposed to any of it: this review is scoped to eligible assignments, and those two accounts hold permanent active assignments, which an eligible-only review never sees.
One behaviour to internalise before the first instance runs, because it will otherwise generate a support conversation. Nothing changes in the directory while a review is in progress, no matter how emphatically reviewers have denied things. Access rights change only when the review completes and applies, at which point the state moves through applying to applied and denied users are removed from roles within a few minutes. So “we reviewed that” and “that was applied” are two different claims, and only the second one means anything.
One more, which is a snapshot semantic rather than a setting: a review captures the state of access at the beginning of each instance. Changes made during the review window show up in the next cycle, not this one.
The second worked example, and the boundary you will hit
The tier group built earlier in this wave, SEC-PIM-Role-Tier1-IdentityOps, holds three directory roles and has a population eligible for its membership. Reviewing it properly means answering two questions, and only one of them is available to you here.
The first question is which roles the group should still hold, and that is an ordinary role review created exactly as above. Create AR-PIM-UserAdministrator-Quarterly scoped to eligible and active assignments of User Administrator, and the group appears in it as a single line. The reviewer approves or denies the group as a whole, without its membership being expanded, and a denied group loses its assignment to that role when the results apply. That is clean, it is covered by P2, and it is a genuinely useful control: it is how you notice that a tier acquired a role during an incident two quarters ago and never gave it back. On this review, and on the other lower-tier reviews, leave If reviewers don’t respond on Take recommendations. The case for overriding it is specific to the top role, where the population is a handful of people and a silent renewal hands back everything.
The second question is who should still be eligible to activate into the group, and this is the boundary. That review is a review of the PIM-managed group’s membership, it is created in the Access Reviews blade under Teams and Groups rather than in PIM, it covers all eligible and active members, and it requires Microsoft Entra ID Governance or the Entra Suite. It is not included in P2. The licensing matrix carries it as its own row, still marked preview, with the P2 column empty.
So on a P2 tenant, ship the role review from this sheet and handle group membership deliberately by other means: a scheduled export of eligible members reviewed by the tier owner on the same quarterly rhythm, using the six-month eligibility expiry set in the earlier build sheet as the backstop that removes anyone nobody renews. That is a real control, it is just a manual one, and the honest way to present it to a client is as a named gap with a named compensating measure rather than as an oversight. If you do hold Governance licences, two mechanics matter: only active owners are assigned as reviewers and eligible owners are excluded, so a group whose owners are all eligible ends up with no reviewers at all, which is exactly why a fallback reviewer is mandatory on these reviews.
The end-to-end test: prove a denial actually removes access
Do not wait a quarter to find out whether this works. Create a one-time copy of the review, scoped identically, with a duration of one day, and run the whole cycle deliberately.
Make a test account eligible for Global Administrator, and confirm the eligibility exists in Assignments before you begin, so you have a before state rather than a belief. Start the review. As the reviewer, deny the test account and approve everyone else. Then stop the review by hand rather than waiting for it to expire, which triggers the same completion path.
Watch the status move from completed through applying to applied. Then check three things in order. The test account’s eligible assignment for Global Administrator should be gone from the PIM assignments view within a few minutes. The review’s results page should show the denial and its application. And in the audit log, filtered with Service set to PIM, you should find the removal of the eligible assignment for that account, attributable to the review rather than to a person.
The pass condition is that the assignment is actually gone from the directory. Not that the review says denied; the review saying denied is what a review does. The thing being tested is that auto-apply was configured correctly and that the removal reached the object, and the number of programmes I have inherited where that had never once been verified is the reason this step exists.
Then run one deliberately negative variant, because it is the trap from the doctrine article and it is better met on a test account than in production. If any of your Azure resource role assignments are held through a security group, create a one-off Azure role review, deny a user who holds the role via that group, apply it, and then look at the group. The user is still in it. Microsoft documents this and gives its reason, which is that the group may grant other things elsewhere, and its consequence, which is that administrators must implement the change themselves. Seeing it once is what stops you building an Azure review process that produces documented reassurance and no change at all. The same applies to nested groups and to groups synchronised from on-premises Active Directory: neither can be auto-remediated, and both fail in the direction of access being kept.
The same work as one runnable block
Reviews are worth scripting for two reasons: the one-review-per-role rule means a real programme is a dozen near-identical objects, and the reporting side is where the portal runs out of usefulness. Access reviews are Microsoft Graph objects, created as an accessReviewScheduleDefinition, and the scope for a privileged-role review points at the role assignment schedule instances for a given role definition.
# Written against Microsoft.Graph PowerShell 2.38.1 and Microsoft Graph v1.0.
# Pin the module if you are scripting this for reuse. Cmdlet parameter sets move
# between releases, and a sheet that does not say what it was written against ages
# badly and fails in ways that look like your mistake.
$ErrorActionPreference = 'Stop'
Connect-MgGraph -Scopes "AccessReview.ReadWrite.All","RoleManagement.Read.Directory"
# CONTEXT ASSERTION. Fill these in before you run anything below. A build sheet
# executed against the wrong tenant is the worst outcome this series can produce,
# and the check costs two lines.
$ExpectedTenantId = '<your tenant id>'
$ExpectedAccount = '<the account you intend to be>'
$mgContext = Get-MgContext
if ($mgContext.TenantId -ne $ExpectedTenantId) { throw "Wrong tenant: $($mgContext.TenantId)" }
if ($mgContext.Account -ne $ExpectedAccount) { throw "Wrong identity: $($mgContext.Account)" }
# Creating a review is a synchronous write, so there is no request status to poll.
# What it does not prove is that the scope query matched anybody: confirm the first
# instance contains people before you trust the schedule.
# Resolve the role by its immutable ID, then confirm the ID is what you think it is.
# Never key a state change on a display name: names are localised and get renamed.
$RoleId = '62e90394-69f5-4237-9190-012177145e10' # Global Administrator
(Get-MgRoleManagementDirectoryRoleDefinition -UnifiedRoleDefinitionId $RoleId).DisplayName
# A quarterly, 14-day review of ELIGIBLE Global Administrator assignments.
# Note the scope points at roleEligibilityScheduleInstances: swap to
# roleAssignmentScheduleInstances for the ACTIVE-assignment integrity check.
# Rollback: Remove-MgIdentityGovernanceAccessReviewDefinition
# -AccessReviewScheduleDefinitionId $definition.Id
$params = @{
displayName = "AR-PIM-GlobalAdministrator-Quarterly"
descriptionForAdmins = "Quarterly review of who remains eligible for Global Administrator."
scope = @{
"@odata.type" = "#microsoft.graph.accessReviewQueryScope"
query = "/roleManagement/directory/roleEligibilityScheduleInstances?`$filter=roleDefinitionId eq '$RoleId'"
queryType = "MicrosoftGraph"
}
reviewers = @(
@{ query = "/users/[email protected]"; queryType = "MicrosoftGraph" }
@{ query = "/users/[email protected]"; queryType = "MicrosoftGraph" }
)
settings = @{
mailNotificationsEnabled = $true
reminderNotificationsEnabled = $true
justificationRequiredOnApproval = $true
defaultDecisionEnabled = $true
defaultDecision = "Deny" # 'Remove access'; lower
# tiers use "Recommendation"
instanceDurationInDays = 14
autoApplyDecisionsEnabled = $true # the switch that matters
recurrence = @{
pattern = @{ type = "absoluteMonthly"; interval = 3 }
range = @{ type = "noEnd"; startDate = "2026-10-01" }
}
}
}
$definition = New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $paramsThree notes. Creating reviews this way needs Identity Governance Administrator in addition to the Graph scope, which is a different role from the Privileged Role Administrator the portal path requires, and that catches people who assume the two routes have the same prerequisites. The scope query is where mistakes live: an incorrectly filtered query produces a review that runs cleanly over an empty set and reports nothing wrong, which is the same failure shape as the deprecated reporting API and just as quiet, so always confirm the first instance actually contains people. And Microsoft publishes a full tutorial for this pattern covering recurring reviews of principals with active or eligible directory roles, including generating an access review history report, which is the piece the portal genuinely cannot do and the reason to come here at all.
One boundary worth stating rather than discovering: multi-stage reviews, where two or three sets of reviewers act in sequence, are documented for reviews created in the Access Reviews blade, and the PIM review creation flow offers no such option anywhere. Treat multi-stage for PIM-created role reviews as undocumented and design without it.
Where this goes next
The loop is now closed. Assignments are eligible rather than standing, activation costs a phishing-resistant credential, the alerts surface what walks around the machinery, and a review removes quarterly what nobody could justify keeping. What remains is the harder question of where this model’s responsibility genuinely ends, which is the subject of the final article in the wave, and it is largely a list of things PIM does not solve and should not be asked to.
Governance
‹ Previous: [PIM 7] Operating PIM: The Loop That Keeps It Honest
Next: [PIM 8] The Decision: What PIM Owns, and What Governance Adds Next ›
