Entra ID retires memberOf on 3 November: after that date, membership stops being recalculated

On 5 August, Microsoft published message centre post MC1448379, titled "Replace MemberOf rules by November 3, 2026". It got filed as what it looks like: an administrative deadline that was then almost three months away. Fifty-three days are left today, and read the other way round it says something rather worse: if you have a live memberOf rule in production, the problem the notice describes does not start in November. You already have it. The preview documentation says so itself, in a paragraph that has been sitting there since January.

What memberOf is and why it ended up everywhere

Entra ID has never been good at what old-school Active Directory did trivially: put a group inside another group and have the application underneath understand it. The memberOf operator was the patch for that. It lets you build a dynamic membership group whose rule does not talk about user attributes but about other groups: user.memberof -any (group.objectId -in ['<id>']). You drop the source group IDs in, and the dynamic group fills up with their members. And since it is an ordinary group for every purpose, it works for licence assignment, for application access and as the target of a Conditional Access policy.

That explains its success. It also explains why the inventory almost everyone will run this week is going to come up short: the operator does not live in one place, it lives in three. Dynamic membership groups, dynamic administrative units and entitlement management auto-assignment policies (access packages). All three are being retired at once, and neither of the other two shows up on the same screen as the groups.

What happens on 3 November is not an error

This is the sentence to read slowly, because it is the one that sets the risk. Microsoft says that after 3 November, configurations still using memberOf stop updating and remain "in their last known state". It does not say they fail. It does not say they empty out. There is no error, no alert, no group flagged red in any console. Whatever membership your group holds on the day it stops is the membership it will hold in December and in February. Read the calendar carefully too: the notice describes retirement "beginning in early November 2026", so the exact day your tenant stops recalculating is not guaranteed — only the date by which it has to be sorted.

The notice lists where it shows up: access to Teams and SharePoint sites, Conditional Access policy targeting, group-based licensing, access package assignments and administrative unit scoping. Translated into the week of 4 November: the person who joins that day gets neither their licence nor the policies that should apply to them; the one who leaves on the 5th keeps their Teams membership, documents included, and still counts inside whatever scope they had. And there is a third case, the most common one and the one nobody looks at: the person who changes department and accumulates both.

The paragraph that has been in the small print since 27 January

We went to the preview page on Microsoft Learn looking for the operator's limits, and in the limitations list sits this, with no callout around it: "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." The public history of the documentation dates that paragraph: it landed on 27 January 2026, in a change titled "Add important note about memberOf behavior when source group is deleted". Six months before the retirement announcement.

Read it again. The "remove" direction does not work. Adding does: put somebody in the source group and they appear. Taking them out does not, until a human edits the rule. The frozen state the notice announces for 3 November has been documented since January, and it does not happen intermittently: it happens every time, in the only direction that matters for security. The retirement does not introduce the failure. It makes it permanent and extends it to joiners as well.

The check costs nothing and you can run it today: take a memberOf group, take somebody who was removed from the source group months ago — a team change, a reorganisation, a project that ended — and see whether they are still in the dynamic group. Mind the case that proves nothing: anyone whose account was deleted drops out anyway, because they are no longer a member of anything. The ones you want are the people still working at the company. If they are still in, you know what you have: people consuming a licence you pay for and holding access somebody considered revoked. It is the same pattern we wrote about when a directory field turns out to work as a credential, in the post on the phone number on the SSPR record: the real permission is not the one in the role matrix, it is the one that falls out of how membership gets computed.

Why it is being retired: everyone paid the toll

The reason Microsoft gives is unusually concrete, and worth quoting: during the preview they observed that using memberOf can slow dynamic membership processing for all groups in the tenant, not only the group that uses it. The message centre post finishes the thought: having one rule with the operator is enough.

This is our reading, not the document's: we think it is the most honest reason anybody can give for killing a feature. They are not killing it because nobody uses it, they are killing it because whoever uses it charges the toll to the rest of their own tenant. If you have ever watched a dynamic group take its time to populate and filed it mentally under "Azure being Azure", here is a candidate explanation. We are not saying it is yours; we are saying there is now somewhere to look. Microsoft adds that it is still building an alternative covering the same scenario with the right scalability, and gives no date. Planning November around that would repeat precisely the mistake that got us here.

"Preview" never meant "a beta that works"

The very page documenting the operator opens its limitations list like this: "This preview should only be used in test environments as it can affect dynamic group processing in the tenant. These limitations are being addressed, and updates will be provided when they're available." That second sentence, the promise, is precisely what the retirement cancels. And it continues: a maximum of 500 memberOf groups per tenant, which also count against the overall quota of 15,000 dynamic groups; up to 50 member groups per group; only direct members of the source group are included, so real nesting still does not work; you cannot chain one memberOf group inside another; you cannot combine it with other rules or other operators; it does not appear in the rule builder, you have to write it in advanced syntax; and it is public cloud only.

With that list in front of you, the interesting question is not why they are retiring it, but why it got into so many places in production, and the answer is not that nobody read: it solved a real pain Entra ID still does not solve. The small print of a preview was never "this may have bugs": it is "this may disappear, and the plan B is yours". We are not outside that sentence, and the rule we apply is the one we recommend: if a preview feature holds up a permission, a licence or an access path, either it has a written way out or it does not go into production. Especially here, which is where your identity lives and not just another application.

What we would do this week

1. Inventory all three places, not just the groups. Export dynamic membership groups from the Entra admin centre and look for memberOf inside the membership rule. Then, with Microsoft Graph PowerShell, go through dynamic administrative units and access package auto-assignment policies. That is Microsoft's own literal recommendation, and it is where half the work gets lost: anyone who only looks at the groups screen will miss two whole families.
2. Do the reverse mapping, which is the real work. For every rule you find, write down what hangs off it: which licence, which Conditional Access policy and whether it goes in as an include or an exclude, which Teams team with its SharePoint behind it, which access package. No export gives you that map; you build it by hand and it is the slowest part. It is also the only thing that turns "we have 40 groups" into "we have 40 groups and three of them switch MFA off".
3. Measure the debt before touching anything. Compare each dynamic group's current membership against the source group's. The surplus is whoever got stuck through the limitation that already exists. That number — how many people hold access somebody considered revoked, and how many licences are being paid for them — is what you show the board, and it is the difference between "a technical chore" and "an approved budget".
4. Choose the replacement with your eyes open. The two ways out are a supported operator over a real attribute (department, jobTitle, an extensionAttribute) or converting the group to assigned membership fed by automation. The first is better, but it moves the problem elsewhere: if the rule depends on department, you now depend on HR writing that field correctly the day somebody changes roles. You trade a membership problem for a data quality problem. It is a good trade; say it out loud and give it an owner.
5. When you change the rule, look at who LEAVES. The natural validation is checking that the usual people are still in, and that finds nothing. The list of departures when the new rule applies is where both the long-stuck members and the mistakes you just introduced show up together, and it needs reviewing person by person. If you can, validate membership with the group disconnected from licences and policies, then reconnect.
6. Set your own date ahead of Microsoft's. 3 November falls on a Tuesday. A membership migration validated on the same day the feature expires is not validated: it is crossed fingers. We would cut over in mid-October, leaving two weeks to watch a full joiner-and-leaver cycle run on the new rule. And with that picture in front of you, take the chance to review what else points at those groups, which is the conversation that actually matters: which controls Entra counts and which it does not.

What we are not claiming

We do not know how many tenants use memberOf and we are not estimating it: Microsoft does not publish that figure. Nor does this affect dynamic groups in general — attribute-based ones carry on unchanged — only configurations using that operator in the three places named. We have not verified the limits in any customer tenant: they come from the vendor's documentation, as do the quotations. We are not saying Microsoft is wrong to retire it; with the reason they give, retiring it is the right call, and the disclaimer was written. And this is not licensing advice: we do not sell Microsoft licences or anyone else's, so what we recommend here does not change our invoice.

Note on sources

Everything this post asserts about the retirement comes from three public sources, consulted on 11 September 2026. The first is Microsoft 365 message centre post MC1448379, "Microsoft Entra ID: Replace MemberOf rules by November 3, 2026", published on 5 August 2026, which is the source of the date, the classification as a major change affecting both user and admin operations, the statement that a single rule with the operator is enough to affect tenant-wide processing, the list of impacted scenarios and the rollout schedule, which reads literally "Retirement (Worldwide): Beginning in early November 2026". The second is the Microsoft Learn page "Configure dynamic membership groups with the memberOf operator in the Entra Admin Center (preview)", with a document date of 4 August 2026 and last update of 5 August 2026, which is where the direct quotations come from — the retirement notice, the limitations paragraph about members removed from a child group, the warning to use the preview only in test environments and the "Migrate before the preview ends" text — along with the rule syntax, the P1 or P2 licence and User Administrator role requirements, and every numeric limit: 500 memberOf groups per tenant, an overall quota of 15,000 dynamic groups, 50 member groups per group, direct members only, no chaining, no combining with other rules or operators, no rule builder and public cloud only. The third is the public history of the documentation in the MicrosoftDocs/entra-docs repository on GitHub, which dates the limitations paragraph: the change titled "Add important note about memberOf behavior when source group is deleted" is dated 27 January 2026, and the one adding the test-environments warning, 14 November 2025. The following is OUR reading, not the document's: that the frozen state is already happening today for people removed from the source group; that in Conditional Access neither direction warns you and that the exclusion carries the larger blast radius; that the tenant-wide toll is the most honest reason available; the reading of what "preview" means; and the six points in the list, including the mid-October cut-over date. We give no adoption, cost or affected-tenant figures, because we do not have them. The cover photograph is "Office Desk Computer", published on rawpixel under a Creative Commons CC0 1.0 licence and cropped for this use.