Entra's MemberOf rule retires today. Your groups won't break, they'll just stop moving

Microsoft's deadline for the MemberOf rule in Entra ID dynamic groups is today, 3 November 2026. Nothing will be deleted and nothing will error. Groups that use it will simply stop updating. That quiet failure is the problem.

What MemberOf did

Dynamic groups in Entra ID add and remove members automatically based on a rule. Most rules look at attributes, such as user.department -eq "Sales". The MemberOf operator was different: it let a dynamic group take its members from other groups, with rules beginning user.memberOf or device.memberOf. It was handy for building one group out of several others, and it also worked in dynamic administrative units and entitlement management auto-assignment policies.

It never left preview. Microsoft's message centre post said it was not recommended for production use and would be retired. Plenty of tenants used it anyway, because it solved a real problem.

What happens after today

Microsoft's final reminder (MC1529463) says dynamic groups using MemberOf will stop processing membership changes after 3 November 2026, and existing members will stay in their last known state. The same applies to dynamic administrative units and auto-assignment policies.

So the group still exists and still looks fine. But from now on:

a new starter who should land in the group won't, so they may miss licences, apps or Teams;
a leaver or someone who changes role stays in the group and keeps that access;
Conditional Access policies that target the group work from an out-of-date list.

The second point is the one that worries me most. Missing access gets reported within a day, because users ring up. Extra access rarely gets reported by anyone.

Entra News and Microsoft 365 for IT Pros both report a later deadline, 31 March 2027, for tenants licensed for Entra ID Governance. The final reminder itself doesn't mention that extension, so don't rely on it unless you know the tenant has those licences.

Where to look

Most tenants won't have many of these, which is exactly why they get forgotten. In my experience the usual suspects are:

"All staff" groups built from department or site groups;
licensing groups, where group-based licensing hangs off a combined group;
Intune device groups made from other device groups, for example to target a policy at "all corporate laptops";
Conditional Access include or exclude groups.

The quickest way to find them across a tenant is a short Microsoft Graph PowerShell check. I've written that up step by step in today's tutorial, including dynamic administrative units.

What to replace it with

There's no single like-for-like replacement. Pick per group:

Rewrite the rule on attributes. If the source groups were themselves based on department, office or job title, combine those conditions into one rule. This only works if the attributes are kept accurate, so check a sample of users first.
Use extension attributes for devices. A naming convention or an extension attribute set in Intune or Graph can stand in for "member of these device groups".
Switch to assigned membership. For small groups that rarely change, this is the simplest answer. Someone then has to own the membership, so put it in the joiner and leaver process.
Script it. A scheduled script can copy members from source groups into an assigned group. It won't be instant, and it is one more thing to monitor.

Whatever you choose, export the current member list first, so you can compare before and after. After saving a new rule, open the group's Overview page and wait for Dynamic rule processing status to show Update complete before you trust it.

The wider lesson

Preview features are useful, but they come with a shorter shelf life. When you build something important on a preview feature, write it down somewhere you'll see it again. A simple list of "things in this tenant that rely on preview features" would have made today's job a five-minute check instead of a hunt.

Sources

← All posts