M365 Entra ID | Disabling the memberOf Operator

On November 3, 2026, Entra ID will stop processing membership rules using the memberOf operator. Microsoft will not delete the affected objects. They will remain in place with exactly the membership status they had on that day.

That’s what makes the deprecation so unpleasant: There’s no error message, no red status in the portal, no entry in monitoring. The group still appears healthy while new employees can no longer be added and former ones aren’t removed.

The announcement is in MC1448379 dated August 5, 2026, classified as a major change with admin and user impact. Dynamic membership groups, dynamic administrative units, and auto-assignment policies in Entitlement Management are affected. The public preview of the operator is ending, and no GA date will follow.

A dynamic group typically populates based on user attributes, such as user.department -eq "Sales". The memberOf operator reversed this logic: Instead of evaluating attributes, Entra ID collected the direct members of other groups and added them to the target group. The corresponding rule looks like this:

This made it possible to replicate what Entra ID still cannot do today: nested groups that are properly resolved by all workloads. Applications that do not support nested groups, Power Platform environments, group-based licensing, and access packages thus received a flat group containing all members of the source groups. The operator was never more than a preview, but it solved a real problem—and that’s why it ended up being used in production in many tenants.

Important for migration planning: Only the direct members of the source group were migrated. Nested structures within the source group were not included, and a memberOf group could not itself serve as a source.

The objects remain intact, while background processing ceases. Membership and assignment data persist in their last calculated state. Microsoft outlines five scopes of impact in MC1448379, each affecting operations at a different level.

In Microsoft 365 groups, Teams and SharePoint permissions spiral out of control because new members don’t gain access while removed members retain theirs. Conditional Access policies targeting such a group continue to apply to a frozen set of users, meaning a new employee might end up working without the required MFA enforcement.

Group-based licensing no longer distributes licenses to new users or revokes them from departing ones, directly resulting in over- and under-licensing. Auto-assignment policies in Entitlement Management no longer grant or revoke access packages. In dynamic administrative units, not only the member list but also the administrative scope in which delegated roles take effect becomes outdated.

The last point is the quietest and the most dangerous. When the scope of an administrative unit is no longer maintained, delegated administrators retain rights to objects that have long since moved elsewhere.

The reasoning is unusually candid: A single memberOf rule can slow down the processing of dynamic memberships across the entire tenant—even for groups that don’t use the operator at all. The evaluation doesn’t scale, and the preview limits reflect that accordingly.

Additionally, there is a behavior that regularly causes incorrect member lists in practice: If a source group is deleted or loses members, the memberOf group does not update automatically. The affected users and devices remain in it until someone modifies the rule. Tony Redmond documented in his analysis that a rule with three referenced groups continued to run even though two of them no longer existed—without any indication in the portal.

Microsoft is hinting at a scalable alternative but isn’t specifying either feature scope or timeline. For planning purposes, this means: you migrate to what exists today, not to an announcement.

The first step is a robust list. For dynamic groups, you retrieve all objects with dynamic membership and filter the rule client-side:

MC1448379 suggests a variant using startsWith(membershipRule,'user.memberOf'). This is faster but only finds rules that start with the operator. If someone has enclosed the rule in parentheses or indented it with a space, it will slip through the filter. The client-side check using -match takes a few seconds longer but returns all matches.

The same logic applies to dynamic administrative units:

Further information can be found in the German-language article.