Microsoft Entra ID is retiring the MemberOf rule for dynamic groups

Microsoft has announced that it will stop supporting the MemberOf preview feature for dynamic groups, administrative units, and automatic entitlement management policies.

If you are using MemberOf rules today, it is important to take action as soon as possible, because after specific dates, these items will either stop updating or be quarantined.

What is changing?

Microsoft is retiring MemberOf rule-based functionality in these areas:

• Dynamic groups in Microsoft Entra ID
• Dynamic administrative units
• Automatic entitlement management policies

This means that if a group or policy relies on a MemberOf rule, it will no longer function as before after the end dates.

Important dates

Date	Impact
October 27, 2026	Entitlement management automatic policies using MemberOf will be quarantined
November 3, 2026	All dynamic groups and dynamic administrative units using MemberOf will stop updating; membership freezes in its current state

What happens after November 3, 2026?

After November 3, 2026, groups using MemberOf will no longer recalculate their membership.

In practice, this means:

• Current members remain in the group
• New users are not automatically added
• Users who should be removed from the group will not be automatically removed
• The group membership will effectively be 'frozen'

This can have significant implications if you use these groups for:

• entitlement assignments
• access controls
• automatic system membership
• managing or assigning access packages

Impact on entitlement management

For entitlement management, this happens even sooner. From 27 October 2026 onwards, automatic assignment policies using MemberOf will be placed in quarantine.

When a policy enters quarantine, it means it is no longer running as expected and the automatic assignment it was meant to handle will no longer be reliable.

No exception or extension

Microsoft indicates that there will be:

• no exception
• no extension
• no way to opt out of the change

If you have MemberOf rules in use, you will therefore need to plan a migration to another solution.

How do you find which groups are affected?

Microsoft recommends that you find all groups and administrative units that use MemberOf rules. To do this, you can use PowerShell with the Microsoft Graph modules, specifically:

• Microsoft.Graph.Groups
• Microsoft.Graph.Identity.DirectoryManagement

The goal is to find:

• dynamic groups with a MemberOf rule
• dynamic administrative units with a MemberOf rule
• entitlement management policies based on MemberOf

This is the first step before any changes are made, so you know exactly where the risk lies.

What are the alternatives?

There are several options available, depending on how you use groups today.

1. Rewrite the rules using user attributes

If possible, it is best to replace MemberOf logic with rules based on user attributes, for example:

• department
• jobTitle
• companyName
• officeLocation
• custom attributes
• extensionAttribute

This is usually the best long-term solution, as it uses a supported dynamic group rule that Microsoft continues to support.

For example, if you were previously using MemberOf to place users into an entitlement group based on another group membership, it might be better to put the relevant value in department or extensionAttribute and base the dynamic group on that instead.

2. Change the group to a assigned group

If dynamic group membership is no longer feasible, you can switch to assigned membership, which is a manual or managed membership model.

This is more suitable when:

• membership rarely changes
• you want more control
• the group is small or well-defined
• automation is not necessary

The disadvantage is that you lose the dynamic behaviour and require either manual administration or other automation.

3. Automate synchronisation with PowerShell or Graph API

If the MemberOf rule reflected more complex business logic that is not easily reproducible with simple user attributes, it may be sensible to create custom automation.

For example, it is possible to:

• read the membership of one or more source groups
• calculate who should be in the target group
• automatically update the target group with PowerShell or Graph API

This offers the most flexibility, but also increases operational complexity. You then need to consider:

• run frequency
• error handling
• logging of changes
• application or service principal permissions
• monitoring and alerts

Solution for group-based licensing

The article specifically points out that if you use MemberOf for group-based licensing, it can often be solved by building groups based on attributes such as:

• user.department
• extensionAttribute

Instead of saying 'everyone in group X goes into group Y', it is better to define attributes that directly specify who should receive the license and then use those attributes in the dynamic rule.

This is both more stable and easier to maintain in the long term.

Are synchronised on-premises groups affected?

No, not directly.

If you have on-premises groups that are synchronised into Entra ID with Entra Connect, they are not the problem themselves.

What is affected is when you have an Entra dynamic group that refers to such groups with a MemberOf rule. In other words:

• the synchronised on-premises group is not the problem
• the dynamic Entra group that bases its membership on MemberOf is the problem

This is an important distinction for environments that rely heavily on hybrid setup.

How should you prepare for the migration?

The article recommends an organised approach.

1. Find all groups and policies that use MemberOf

Start by mapping everything that depends on this attribute. This includes:

• dynamic groups
• dynamic administrative units
• entitlement management assignment policies

2. Document how they are used

For each object, you need to understand:

• what it is used for
• which systems or processes depend on it
• whether it governs permissions, access, or assignments
• how often membership changes

3. Choose a replacement solution

For each group or policy, you need to make a decision:

• rewrite as a dynamic, attribute-based rule
• change to an assigned group
• build a custom sync automation

4. Test the outcome

Before you turn off the old solution, you should compare the old and new membership.

The article suggests to:

• export membership to CSV
• compare the results
• use, for example,  Compare-Object to see the differences

This way, you can verify that the new solution yields a comparable outcome before the change goes into production.

5. Update documentation and operational procedures

Once a new solution has been chosen and tested, you need to update:

• technical documentation
• operational guides
• group ownership registration
• change and incident management process

Why does this matter?

MemberOf was a convenient way to build groups based on membership of other groups, but it also became easy to hide complex and sometimes opaque logic within it.

When this functionality is removed, many teams will be forced to migrate to clearer and more maintainable solutions. Although this requires short-term effort, in the long term it can improve:

• visibility
• operational security
• incident management
• manageability

Recommendation

If you are using MemberOf rules, you should not wait until autumn 2026.

The most sensible approach is to:

• identify all affected groups and policies
• prioritise those related to permissions and access control
• choose a new membership model for each object
• test the results thoroughly
• complete the migration before the deadlines