What's really happening on November 3, 2026
On November 3, 2026, Microsoft Entra ID will stop evaluating dynamic membership rules based on the memberOf operator. This isn't a bug. It's a planned retirement — and its silent nature makes it one of the hardest regressions to detect in production.
No alert in the portal. No automated email to administrators. The affected groups continue to display members, enforce access, and appear perfectly healthy. They are simply frozen in the state they were in at the moment of the switch.
Why Microsoft is retiring the memberOf operator
The memberOf operator has been in Public Preview since 2022. It has never reached general availability (GA). The official reason cited by Microsoft: a single memberOf rule can slow down the processing of all dynamic groups in a tenant — including those that don't use this operator.
Rather than solving the scalability problem, Microsoft chose to retire the feature.
Feature being retired
The memberOf operator in Microsoft Entra ID dynamic group rules is officially retired on November 3, 2026. Its use in production was never recommended by Microsoft, which flags it as having known bugs and limitations.
How the memberOf rule works today
Concretely, memberOf allows you to create a dynamic group whose membership rule is based on membership in other groups. Typical example: an All Fee Earners group that dynamically aggregates members from three groups — Corporate, Real Estate, and Litigation — via their respective objectIds:
1user.memberOf -any (group.objectId -in ['<objectId1>', '<objectId2>', '<objectId3>'])This syntax simulates nesting of dynamic groups, which Entra ID doesn't support natively. It's often used as an application point for conditional access policies or SharePoint permissions.
It's precisely because it's convenient that it has become widespread — and for the same reason that its disappearance can go unnoticed.
Behavior after November 3, 2026
After the retirement date, Entra stops re-evaluating memberOf rules. The group is not deleted. It is not disabled. It is frozen.
Here's what this concretely implies:
- An employee who joins the Litigation department after the freeze never joins the All Fee Earners group.
- An employee who leaves the company after the freeze retains access indefinitely.
- The group continues to enforce all attached policies — conditional access, SharePoint site permissions, assigned licenses.
Silent security risk
Former employees who retain access report nothing. No one complains on their behalf. The group appears operational. The only visible sign is a progressive and unidirectional drift: too many members, never too few.
Audit your tenant with PowerShell
Before any remediation, you need to identify exposed groups. The PowerShell script below queries Microsoft Graph to list all dynamic groups whose membership rule contains the memberOf operator.
1Connect-MgGraph -Scopes "Group.Read.All"2 3Get-MgGroup -All -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `4 -Property DisplayName, MembershipRule, Id |5 Where-Object { $_.MembershipRule -like "*memberOf*" } |6 Select-Object DisplayName, Id, MembershipRuleThis script:
- Connects to Microsoft Graph with the
Group.Read.Allscope. - Filters only groups of type DynamicMembership.
- Retains those whose rule contains the
memberOfstring. - Returns the name, identifier, and complete rule of each affected group.
Multi-tenant tip
To audit multiple customer tenants (MSP), run this script in each context after a dedicated Connect-MgGraph, or automate via a multi-tenant application registered in Microsoft Entra ID with delegated admin consent.
Replacement strategies
There is no direct, native replacement for memberOf in Entra ID dynamic groups. Alternatives depend on the use case:
| Use case | Recommended alternative | Note |
|---|---|---|
| Group users from multiple departments | Rule based on a common attribute (e.g. jobTitle, department, extensionAttribute) | Requires a consistent attribute convention in the directory |
| Multi-group conditional access | Target multiple groups directly in the policy | Limitation: some policies accept only a single group as target |
| Aggregated SharePoint permissions | Assign multiple groups to a SharePoint site | More groups to maintain, but predictable behavior |
| Complex membership logic | Dynamic groups based on custom attributes via extensionAttributes | Requires an attribute feeding process (HR, HRIS, provisioning) |
| Automation | Logic Apps or Azure Functions with Microsoft Graph API | Programmatic approach, outside the native rules engine |
Prepare for migration before the deadline
Inventory exposed groups
Run the PowerShell script provided above on each tenant concerned. Record the results: group name, current rule, attached conditional access policies, and resources.
Assess business impact
For each group identified, map dependencies: which conditional access policies reference it? Which SharePoint sites? Which licenses are assigned via this group?
Design the replacement rule
Identify the user attribute that would allow expressing the same membership logic. Validate that this attribute is reliably fed into Microsoft Entra ID — via Microsoft Entra Connect, HR provisioning, or another source.
Test in non-production environment
Create the replacement group with the new rule. Compare the members obtained with those of the existing memberOf group. Correct any discrepancies before any switch.
Migrate dependencies and archive the old group
Update conditional access policies, site permissions, and license assignments to point to the new group. Archive or delete the old group after validation.
Key points to remember
- The
memberOfoperator in Microsoft Entra ID dynamic group rules is retired on November 3, 2026. - After this date, affected groups are no longer re-evaluated: they freeze in their current state.
- The drift is silent and unidirectional — accumulation of irrevocable access, exclusion of newcomers.
- The PowerShell script based on Microsoft Graph allows you to quickly identify all exposed groups in a tenant.
- Migration requires designing alternative rules based on reliable and maintained user attributes.
The window before November 2026 is sufficient to act smoothly — as long as you start the audit now rather than in October.
