Setting Up Recurring Entra ID Access Reviews for Guests

#Operational requirement

Guest accounts are the fastest-growing unmanaged attack surface in most Microsoft 365 tenants. Every project that invites a contractor, auditor or partner through B2B collaboration leaves behind an Entra ID guest object that almost never gets cleaned up. Nobody owns the offboarding step because nobody is explicitly told to. Eighteen months later you have three hundred guest accounts with Contributor access to SharePoint sites for projects that finished a year ago, and your ISO 27001 or SOC 2 auditor flags “no evidence of periodic access recertification” as a finding. That finding does not go away with an apology; it goes away with a documented, repeatable, automated review process.

This is precisely the kind of task a junior identity engineer gets handed in the first month: “set up a recurring review so we stop finding stale guest accounts during audit season.” Get the scope wrong and you either annoy every project owner in the business with reviews they cannot action, or you silently strip access from a guest who is still actively working, breaking a live vendor integration on a Friday afternoon. Get it right and you have a defensible, auditable, low-maintenance governance control that runs itself every quarter.

#Prerequisites and required permissions

You need an Entra ID P2 licence assigned at tenant level (Access Reviews is a Governance feature, not available on P1). Confirm this before you start; Global Administrator will not bypass a licensing gate, and you will burn an afternoon chasing a phantom permissions error that is actually a licence problem.

Role-wise you need Identity Governance Administrator or User Administrator combined with Identity Governance Administrator, or Global Administrator for the initial build. In production, do not run this under Global Administrator long-term; request a Privileged Identity Management (PIM) eligible assignment for Identity Governance Administrator and activate it only for the build window.

You also need the Microsoft Graph PowerShell SDK installed, an approved change ticket referencing the guest population you are reviewing, and a named business reviewer for each scoped group — access reviews with no accountable human reviewer just expire unresolved and generate more audit noise than the problem they solve.

1Install-Module Microsoft.Graph -Scope CurrentUser
2Connect-MgGraph -Scopes "AccessReview.ReadWrite.Membership","Directory.Read.All","Group.ReadWrite.All"

#Step 1: Scope the review and get change sign-off

Action: identify exactly which guest population is in scope. Do not write “all guests” into a change ticket — that is unreviewable in large environments for a first pass. Scope to a single dynamic group (built in Step 2) representing all guest-type users, then narrow by resource in later cycles if the population is large.

Expected result: a change record (CAB or lightweight change ticket, depending on your organisation’s process) stating the scope, recurrence, reviewer, and the default decision on non-response.

Evidence to capture: the change ticket number, and a plain-text scope statement such as “Quarterly review of all Entra ID guest accounts, reviewer: resource owner group, auto-deny and remove on non-response after 14 days.”

Checkpoint: do not proceed to Step 2 without a signed-off change record. Auto-apply reviews that remove access are a production change, not a reporting exercise.

#Step 2: Build a dynamic group for guest accounts

Access reviews need a defined group as their scope. If your tenant does not already have a dynamic group capturing all guest-type users, create one.

1New-MgGroup -DisplayName "All-Guest-Accounts-Dynamic" `
2 -MailEnabled:$false -MailNickname "allguestsdyn" -SecurityEnabled:$true `
3 -GroupTypes @("DynamicMembership") `
4 -MembershipRule "(user.userType -eq "Guest")" `
5 -MembershipRuleProcessingState "On"

Expected result: a new security group whose membership self-populates from Entra ID guest objects. Dynamic membership processing can take up to several hours on first run in large tenants — do not assume the group is empty just because it shows zero members five minutes after creation.

Evidence: capture the group Object ID with Get-MgGroup -Filter "displayName eq 'All-Guest-Accounts-Dynamic'" and record it in the change ticket.

Checkpoint: confirm membership count is non-zero and roughly matches your known guest population before moving on.

#Step 3: Create the access review schedule definition

Build the review against the dynamic group using the Identity Governance Graph API surface.

1$params = @{
2 DisplayName = "Quarterly Guest Access Review"
3 DescriptionForAdmins = "Recurring recertification of all Entra ID B2B guest accounts."
4 DescriptionForReviewers = "Confirm this guest still requires access. No response results in removal."
5 Scope = @{
6 "@odata.type" = "#microsoft.graph.accessReviewQueryScope"
7 Query = "/groups/<GroupObjectId>/transitiveMembers"
8 QueryType = "MicrosoftGraph"
9 }
10 Reviewers = @(
11 @{
12 Query = "/groups/<ReviewerGroupObjectId>/members"
13 QueryType = "MicrosoftGraph"
14 }
15 )
16 Settings = @{
17 MailNotificationsEnabled = $true
18 ReminderNotificationsEnabled = $true
19 JustificationRequiredOnApproval = $true
20 DefaultDecisionEnabled = $true
21 DefaultDecision = "Deny"
22 InstanceDurationInDays = 14
23 AutoApplyDecisionsEnabled = $true
24 Recurrence = @{
25 Pattern = @{ Type = "absoluteMonthly"; Interval = 3 }
26 Range = @{ Type = "noEnd"; StartDate = (Get-Date).ToString("yyyy-MM-dd") }
27 }
28 }
29}
30New-MgIdentityGovernanceAccessReviewScheduleDefinition -BodyParameter $params

Expected result: a new schedule definition returned with a GUID identifier. Replace the placeholder Object IDs with your actual guest group and reviewer group.

Evidence: capture the returned Id value — you will need it for pausing, editing or deleting the definition later.

Checkpoint: verify in the Entra admin centre under Identity Governance > Access Reviews that the definition appears with the correct recurrence and scope before its first instance fires.

#Step 4: Confirm auto-apply and non-response handling

The most consequential setting here is DefaultDecision = "Deny" combined with AutoApplyDecisionsEnabled = $true. This means a reviewer who does nothing for fourteen days causes that guest’s access to be automatically removed. That is the intended governance outcome, but it is also the setting most likely to generate an angry email from a project owner who missed a notification. Make sure reminder notifications are genuinely reaching reviewers — check reviewer mailbox rules and confirm they are not routing Entra ID governance emails to a folder nobody checks.

#Step 5: Pilot the first cycle before going tenant-wide

Do not launch this against your full guest population on day one. Run the first instance against a single project’s guest subset, with a human reviewer who has agreed in advance to action it within the fourteen-day window. This is your hands-on validation task: create a second, narrower access review scoped to one known project group, walk through approving one guest and explicitly denying another, and confirm the deny actually triggers removal from the underlying resource, not just a status change in the review record.

#Verification and evidence

After the pilot instance completes, pull the results.

1Get-MgIdentityGovernanceAccessReviewScheduleDefinition -AccessReviewScheduleDefinitionId "<DefinitionId>"
2Get-MgIdentityGovernanceAccessReviewScheduleDefinitionInstance -AccessReviewScheduleDefinitionId "<DefinitionId>"

Retain three artefacts as audit evidence: the exported decision CSV from the admin centre (Access Reviews > review instance > Download decisions), the change ticket showing sign-off, and a screenshot or Graph export of the schedule definition’s recurrence settings. Auditors want to see the control existed, ran, and produced a recorded outcome — not just that you configured it once.

#Failure Modes and Common Traps

#Rollback

If a pilot cycle causes unintended access removal, first restore the affected guest’s access manually — do not wait for the next review cycle to self-correct, because it will not. Re-add the guest to the target resource group directly.

New-MgGroupMember -GroupId "<ResourceGroupId>" -DirectoryObjectId "<GuestObjectId>"

To pause a runaway or misconfigured review definition without deleting the audit history, disable auto-apply and set the definition to manual decision handling rather than removing it entirely:

1Update-MgIdentityGovernanceAccessReviewScheduleDefinition -AccessReviewScheduleDefinitionId "<DefinitionId>" `
2 -Settings @{ AutoApplyDecisionsEnabled = $false; DefaultDecisionEnabled = $false }

To fully retire a pilot definition once validated and replaced by the production-scoped review, delete it cleanly rather than leaving duplicate stale definitions running in parallel:

Remove-MgIdentityGovernanceAccessReviewScheduleDefinition -AccessReviewScheduleDefinitionId "<DefinitionId>"

Log every rollback action against the same change ticket used for the original build, with a timestamp and the guest or reviewer affected. An access review control that silently removed access without a recorded rollback trail is worse for audit posture than having no control at all.

#Operational Summary

You have built a dynamic guest group, scoped a recurring quarterly access review against it through the Microsoft Graph Identity Governance API, assigned an accountable reviewer, configured a defensible non-response default, piloted it against a narrow population, and validated both the approve and deny paths including rollback. The deliverable for this assignment is the schedule definition GUID, the exported decision CSV from the pilot cycle, and the signed change ticket — keep all three together as a single evidence package. Before closing this task, confirm you can answer, without checking notes, what happens to a guest’s access if their reviewer takes no action for fourteen days, because that is the exact question your auditor or your manager will ask first.