Entra dynamic groups: memberOf retires November 3

On November 3, 2026 the public preview of the memberOf rule operator in Microsoft Entra ID ends. If you use it, the thing to understand first is what the ending looks like from the inside: nothing errors, nothing breaks loudly, and nothing appears in a report.

Microsoft's own words, from its documentation:

“After November 3, 2026, dynamic membership groups, dynamic administrative units, and entitlement management auto-assignment policies that use the memberOf operator stop updating and remain in their last known state.”

Remain in their last known state. The group is still there. It still has the members it had on November 2. A permissions review will find a group that exists, has members, and looks correct. What it will not find is that the group stopped being maintained.

What Microsoft announced, and what its own documentation still does not say

The retirement was announced in Microsoft’s Entra “what’s new” communication of September 1, 2026, attributed to Yina Arenas, Corporate Vice President for Identity and Network Access. The operative sentences:

“Organizations using the MemberOf rule operator in dynamic groups, dynamic administrative units (AUs), or entitlement management auto-assignment policies must replace these configurations by November 3, 2026.”

“Configurations using this rule operator will stop updating after November 3, 2026.”

Here is the part worth acting on. Microsoft’s own reference page for dynamic membership rules still says nothing about any of this. That page — Dynamic membership rules for groups, whose ms.date and updated_at both still read August 13, 2026 — continues to list memberOf as an available property and describes it this way:

“The memberOf operator is in preview and has some limitations, so use it with caution.”

We re-read that page on September 10, 2026. The words November 3, retire and stop updating do not appear on it anywhere. So the reference documentation says preview, use with caution, while the announcement says replace it by November 3. Those are not contradictory — the page predates the announcement by nineteen days — but the practical consequence is sharp: an engineer who checks the documentation instead of the announcement finds nothing wrong. Nine days after Microsoft announced the retirement, its own reference page has still not been updated. If you are delegating this check to someone, delegate the date along with it, because the page will not surface it for them.

Why anyone used it, and how to tell if that is you

memberOf existed to solve one specific gap. Active Directory resolves nested groups — put Group B inside Group A and the members of B are effectively members of A. Entra ID does not do that. A cloud group containing another group does not grant its members anything, and applications reading membership see the nested group as a single opaque object rather than the people inside it.

The memberOf operator was the closest available workaround: a dynamic rule of the form user.memberof -any (group.objectId -in ['groupId-1', 'groupId-2']), which flattens the direct members of the named groups into one dynamic group that apps and licensing can actually read.

So the population most affected is a specific one: organisations that migrated from Active Directory and rebuilt a nested group structure in the cloud. If your group design assumes nesting works, you either used memberOf or you hit the wall and did something manual. Both are worth checking. Note also that it only ever flattened direct members — a group inside a group inside a group was never resolved, so any structure deeper than one level was already incomplete.

Microsoft names the consequences, so we will use its list

The same guidance says the frozen state “can lead to stale access and enforcement gaps, including outdated Teams and SharePoint access, Conditional Access targeting, group-based licensing, and access package assignments.” Those are four distinct problems and only one of them is about people keeping access too long:

• Outdated Teams and SharePoint access. A leaver stays in the group and therefore stays in the site.
• Conditional Access targeting. This is the one worth stopping on. If a Conditional Access policy is scoped to a dynamic group, then a new joiner who never gets added is a person the policy never applies to. The control shows as enabled. It simply does not cover them.
• Group-based licensing. Licences stop following people, in both directions — unlicensed new starters and licences still attached to accounts that should have released them.
• Access package assignments. Entitlement management assigns and revokes against a rule that has stopped evaluating.

For a regulated firm, the second one is the expensive one. A control narrative that says “MFA is enforced for all finance staff via Conditional Access” can be true on the day it was written and quietly false four months later, without a single configuration change and without anyone touching the policy.

Entitlement management is worded differently, and the word matters

For access packages, Microsoft uses a different verb: “Starting November 3, 2026, automatic assignment policies whose membership rule uses memberOf are quarantined. The policies remain, but assignment processing stops, and no assignments are added or removed until you remove memberOf from the rule.”

Quarantined, not deleted. The policy is still listed, still looks configured, and does nothing. Microsoft also states the reassuring half plainly — “Automatic assignment policies that don't use memberOf aren't affected” — so this is a targeted change, not a platform-wide one.

The part that should change how urgently you look: it is already happening

Buried in the preview limitations is a sentence describing behaviour that exists today, not in November:

“Membership of a memberOf dynamic group doesn't automatically update when a child group is deleted or when members are removed from a child group. The affected users or devices remain members of the memberOf dynamic group until the rule is modified.”

Read that against the failure it describes in November and they are the same failure, differing only in scope. If you are running memberOf groups in production right now, removals may already not be propagating. The November date does not introduce stale membership. It generalises it.

Which leads to the sentence most likely to be uncomfortable, and it is Microsoft's, not ours: “This is a preview feature that isn't intended for production use.” That is worth knowing before an audit conversation, not during one.

Three object types, three different ways to find them

There is no single pane that lists everything using memberOf. Microsoft's guidance splits into three, and they are usually owned by different people:

• Dynamic membership groups. Export dynamic membership groups from the Microsoft Entra admin center and identify rules containing memberOf. A tenant can hold up to 500 of them, each with up to 50 member groups, so do not assume this is a short list you can eyeball.
• Dynamic administrative units. Microsoft Graph PowerShell. These are the ones people forget, because an administrative unit is a scoping construct rather than an access construct — and a dynamic AU that stops updating means delegated admin scope silently drifts.
• Entitlement management auto-assignment policies. Microsoft publishes a read-only PowerShell script in its own documentation that walks every assignment policy in the tenant, filters to automatic ones, checks each membership rule for memberOf, and writes the result to CSV. ⭐ It writes the file even when nothing matches, so you get a dated record that you looked — which is the artefact an auditor actually wants.

What replaces it

Nothing, yet. Microsoft is explicit: “We recognize the importance of the customer scenarios that memberOf addresses, and we're continuing to develop an alternative solution that meets these needs with the right level of scalability and reliability.”

The interim options are the two you would expect: rebuild the rule with supported operators, or convert the group to assigned membership and maintain it deliberately. If memberOf was doing something the other operators cannot express — and it often was, because it was the only way to approximate nested groups in Entra — then there is no rule that replaces it and the decision is an operational one about who maintains that membership instead.

Microsoft also gives the reason it is going, which is useful context for anyone deciding how hard to fight it: “During preview, we observed that using memberOf can slow dynamic membership processing for all groups in a tenant.” The feature was costing every other dynamic group in the tenant, not only its own.

What we would do this week

• Run the three inventories. Groups, administrative units, access packages. An hour, and you either have a list or you have a dated record that you have none.
• Check Conditional Access first, not licensing. If any CA policy is scoped to a memberOf-derived group, that is the finding that matters most, because its failure mode is a control that silently under-covers rather than a cost that shows on an invoice.
• Check whether removals are already broken. Delete a test member from a child group and see whether the parent updates. Per Microsoft's own limitations, it will not.
• Decide per group, not in bulk. Some become assigned groups, some get rebuilt on supported operators, and some should simply be deleted because they were built for a preview that was never meant for production.
• Write down the date you checked. The whole risk of this change is that it produces no evidence, so the evidence has to be manufactured deliberately.

Sources

Quotations are from two Microsoft Learn pages, both read in full: Configure dynamic membership groups with the memberOf operator (ms.date 2026-08-04) and Configure an automatic assignment policy for an access package (ms.date 2026-08-05), which is where the quarantine wording and the discovery script live.

One correction, because we checked it and it did not hold. Some coverage of this change reports that entitlement management auto-assignment policies are quarantined from October 27, 2026, a week earlier than the headline date, and presents it as a contradiction inside Microsoft's own documentation. We read both pages directly on September 5, 2026. Both say November 3, 2026. There is no seven-day discrepancy on either page today. If Microsoft changes either date, this post will say so.

If you would rather have the three inventories, the Conditional Access impact assessment and a per-group decision handled as a bounded piece of work, scope it with us.