What’s happening
Microsoft announced in Message Center post MC1448379 that the memberOf rule operator for dynamic membership groups, dynamic administrative units, and entitlement management auto-assignment policies is being retired. From November 3, 2026, any configuration still using memberOf stops processing and stays frozen at its last calculated membership. It never left preview, and Microsoft hasn’t shipped a replacement yet, just a statement that something is in the works. If you’re using memberOf anywhere in your tenant, this is worth putting on your task list now rather than later.
What is the memberOf rule operator
Introduced in preview back in June 2022, memberOf let admins build a dynamic group, administrative unit, or entitlement management auto-assignment policy from the direct members of up to 50 source groups: security groups, Microsoft 365 groups, or groups synced from on-premises Active Directory. It was, in practice, the closest thing Entra ID had to real nested group support. A lot of organizations put it into production despite the preview label, simply because it solved a real gap. Apps and features that can’t traverse nested group membership natively, such as licensing, Conditional Access targeting, or access packages, could finally work off a flattened membership list.
A rule using it looks roughly like this:
(user.memberOf -any (group.objectId -in ['<group-object-id-1>', '<group-object-id-2>']))A few limitations are worth keeping in mind. Only direct members of the source groups get pulled in, so nested members of a nested group won’t show up. A memberOf group can’t be used as a source for another memberOf group, the operator can’t be combined with other rule clauses, and each tenant is capped at 500 memberOf dynamic groups, which count toward the overall 15,000 dynamic group limit.
Timeline
| Date | What happens |
|---|---|
| October 27, 2026 | Entitlement management auto-assignment policies using memberOf get quarantined. Processing for these stops from this date, according to the entitlement management documentation. |
| November 3, 2026 | Dynamic membership groups and dynamic administrative units using memberOf stop updating tenant-wide and stay frozen in their last known state. |
Microsoft’s own documentation isn’t fully consistent between these two dates across different Learn pages. If you use entitlement management, plan around the earlier date (October 27, 2026) rather than assuming you have until November 3.
Why Microsoft is retiring it
Microsoft’s stated reason is that the operator is too resource-intensive for the dynamic group processing pipeline. A single memberOf group in a tenant could slow down dynamic group evaluation tenant-wide, not just for that one group. That’s also why the preview documentation always recommended keeping it to test environments only. Microsoft says it recognizes that the scenarios memberOf addresses are legitimate and that a more scalable alternative is being developed, but nothing concrete has shipped alongside this retirement announcement.
Impact if you do nothing
This isn’t a clean feature removal. The object stays, the rule stays, only the background processing stops. In practice, for any group, AU, or policy that still references memberOf after the cut-off:
- New members of a source group aren’t propagated. They won’t get the Teams/SharePoint access, licenses, or Conditional Access treatment the dynamic group was supposed to grant.
- Removed members keep their access. If someone leaves a source group, say during offboarding or a role change, they stay in the frozen dynamic group and keep whatever access, license, or CA exemption it granted.
- Conditional Access targeting drifts from actual group membership, silently, with no error or warning shown in the CA policy itself.
- Group-based licensing stops reflecting reality, which can mean active users without a licence or wasted licences on people who should have lost access.
- Access package auto-assignment policies in entitlement management stop granting or revoking packages based on source group changes.
Audit: find every memberOf usage in your tenant
Before anything else, get a full inventory. The script below uses the Microsoft Graph PowerShell SDK and checks both dynamic groups and dynamic administrative units. Connect with at least Group.Read.All and AdministrativeUnit.Read.All.
Connect-MgGraph -Scopes "Group.Read.All","AdministrativeUnit.Read.All" -NoWelcome
# Dynamic groups using memberOf
$dynamicGroups = Get-MgGroup -All -Property "id,displayName,membershipRule,membershipRuleProcessingState" |
Where-Object { $_.MembershipRule -match "memberOf" }
$dynamicGroups | Select-Object DisplayName, Id, MembershipRuleProcessingState, MembershipRule |
Format-Table -AutoSize
# Dynamic administrative units using memberOf
$dynamicAUs = Get-MgDirectoryAdministrativeUnit -All -Property "id,displayName,membershipRule,membershipType" |
Where-Object { $_.MembershipType -eq "Dynamic" -and $_.MembershipRule -match "memberOf" }
$dynamicAUs | Select-Object DisplayName, Id, MembershipRule | Format-Table -AutoSize
# Export both for tracking
$dynamicGroups | Export-Csv -Path ".\memberOf-dynamic-groups.csv" -NoTypeInformation
$dynamicAUs | Export-Csv -Path ".\memberOf-dynamic-aus.csv" -NoTypeInformationEntitlement management auto-assignment policies aren’t exposed the same way through Get-MgGroup. Check them via the Entra admin center under Identity Governance > Entitlement management > Access packages, reviewing each policy’s automatic assignment rule for memberOf references, or query accessPackageAssignmentPolicy resources through Graph directly if you’re scripting this at scale.
Migration options
For each affected object, there are three realistic paths:
- Replace it with a supported attribute-based rule. If the source groups exist because of a shared attribute (department, extension attribute, on-prem OU, job title), rebuild the rule directly against that attribute instead of the group membership. Use
-in/-notInwith bracket syntax when comparing against multiple values. It’s more efficient than chaining-eq/-orclauses and avoids-match/-contains, which Microsoft recommends minimizing for processing performance anyway. - Convert it to an assigned (static) group. If the source group’s membership is small or doesn’t change often, drop dynamic membership entirely and manage it manually or through a scripted sync (Azure Automation, Logic Apps, or whatever IAM tooling you already run). You trade automation for predictability, which is often the right trade for security-sensitive groups anyway.
- Pause or delete the group if it’s no longer needed. A fair number of these configurations are leftovers from testing during the preview and were never cleaned up. The audit above is a good moment to get rid of that dead weight.
Whichever path you pick, validate the resulting membership against the previous memberOf-derived membership before cutting over, and let whoever owns the downstream consumer know about the change, whether that’s a Conditional Access policy owner, a licensing admin, or a Teams/SharePoint site owner. The access boundary can shift even when the intent stays the same.
Recommendation
Run the audit now, not in October. If you manage multiple tenants, which is increasingly common with Microsoft365DSC or similar configuration-as-code setups, add a memberOf check as a standing drift-detection rule so it doesn’t quietly reappear the next time someone builds a group from an old template or a documentation snippet. Microsoft hasn’t committed to a concrete replacement timeline, so don’t wait for one. Migrate to attribute-based rules or assigned membership now, and treat any future replacement as a bonus rather than a dependency.
Doudisblog 
Leave a comment