Tools & Implementation • Identity Governance

Microsoft is retiring Entra memberOf dynamic rules: Check access, licensing and Conditional Access before November

After 3 November 2026, affected rules are expected to stop updating and remain in their last-known state. The result may be stale access or enforcement rather than an obvious failure—so organisations need to find dependencies, replace the rule and prove that the resulting membership is correct.

Who should review this? Microsoft Entra administrators using user.memberOf or device.memberOf in dynamic groups, dynamic administrative units or Entitlement Management auto-assignment policies.

Trends4You Editorial

Planned retirement

Why this needs action before 3 November 2026

Microsoft 365 Message Center notice MC1448379 and current Microsoft Learn guidance state that the public preview of the Entra memberOf dynamic-rule operator is ending. After the deadline, affected dynamic membership groups, dynamic administrative units and Entitlement Management auto-assignment policies stop updating and stay in their last-known state.

This is a difficult failure mode because the configuration can still exist and its previous membership can still be used. Someone removed from a source group may retain access, a new starter may not receive a licence, or an administrative or Conditional Access scope may become inaccurate without a clear outage drawing attention to the problem.

Confirm the notice in your own tenant

Review MC1448379 in the Microsoft 365 Message Center and recheck Microsoft Learn before making production changes. Record the deadline, affected services, owner and migration decision in the organisation's change or risk process.

Avoid a scope misunderstanding

The dynamic-rule operator is retiring—not every use of “memberOf”

Dynamic groups

User or device membership rules containing user.memberOf or device.memberOf are affected. Dependent access, applications and group-based licensing may therefore become stale.

Dynamic administrative units

Affected membership rules can leave administrative scope inaccurate. Validate both the resulting membership and which administrators can manage it.

Entitlement Management

Affected automatic assignment policies are expected to be quarantined: the policy remains, but assignment processing stops until the rule is rebuilt.

Not the same thing

Ordinary Entra or Active Directory group membership, Microsoft Graph membership APIs and the on-premises AD memberOf attribute are not the retiring dynamic-rule operator.

Map the consequence

A stale group can quietly affect several controls

Application and collaboration accessTeams, SharePoint, enterprise applications and other resources assigned to the affected group.
Conditional AccessPolicies that include or exclude the group may continue applying to an outdated population.
Group-based licensingUsers may retain licences they no longer need or fail to receive services required for their role.
Administrative scopeDynamic administrative-unit membership can alter the objects delegated administrators are authorised to manage.
Access packagesAutomatic assignments may no longer be added or removed when identity circumstances change.
Operational processesJoiner, mover and leaver workflows can appear complete while a dependent membership remains incorrect.

Start with dependencies, not only rules

For every affected object, record what consumes it, the business purpose, the accountable owner and the consequence of someone being incorrectly included or excluded.

Discovery

Find every affected configuration

1

Export dynamic membership groups

Use the Entra admin centre export and search membership-rule text for memberOf. Include both dynamic user and dynamic device groups.

2

Check dynamic administrative units

Use Microsoft Graph PowerShell or the administrative-unit inventory to identify dynamic rules containing the operator.

3

Check automatic access-package assignments

Review Entitlement Management policies and identify automatic assignment rules that depend on group membership.

4

Map downstream assignments

For each result, identify licences, applications, policies, access packages, administrative roles and collaboration resources that use it.

Do not search only by display name

The risk is in the rule text and its dependencies. A group name may not indicate that it uses memberOf, and the same group may drive several unrelated controls.

Replacement design

There is no single replacement for every scenario

Use authoritative attributes

Where data quality is dependable, build a supported rule from attributes such as job title, department, location, extension attributes or appropriate device properties.

Assign source groups directly

If the consuming service accepts several groups, direct assignment can remove the need for an aggregation group. Confirm whether nested membership is supported.

Use assigned membership

For a small, stable population, a governed assigned group may be proportionate if ownership and periodic review are clear.

Use controlled automation

If no supported rule expresses the requirement, automation may maintain membership—but it needs credentials, monitoring, error handling, ownership and recovery.

Choose the simplest option that represents the business requirement accurately. Replacing one opaque dependency with an unowned script or unreliable attribute does not reduce risk.

Anonymised operational example

Replacing group aggregation with reliable hybrid-directory data

A hybrid organisation used a dynamic group to combine Project Managers and Team Leaders who required Microsoft 365 Business Premium. The original rule depended on membership of two source groups:

user.memberof -any (group.objectId -in ['ID-OF-GROUP-A']) or
user.memberof -any (group.objectId -in ['ID-OF-GROUP-B'])

Because job-title data was accurately maintained in on-premises Active Directory and synchronised to Entra ID, the organisation could express the underlying business requirement directly:

(user.jobTitle -eq "Project Manager") or
(user.jobTitle -eq "Team Leader")

Why this is a stronger design

The replacement removes dependency on two intermediate groups and connects licensing to an authoritative role attribute. Its reliability still depends on accurate job-title maintenance, successful directory synchronisation and evidence that the new population receives the intended licence.

This example reflects a completed operational migration. Historical comparison figures were not retained, so it illustrates the replacement approach rather than quantified results.

Safe migration

Replace, compare and validate before removing the dependency

1

Capture the starting state

Export the existing rule, membership, processing status, assignments and known exceptions. Record the rollback point.

2

Build the replacement safely

Use a test group or non-production assignment where possible. Keep production dependencies unchanged while evaluating the new result.

3

Compare membership

Identify users or devices present only in the old result, only in the new result and in both. Investigate every unexplained difference.

4

Validate downstream behaviour

Check licences, Conditional Access evaluation, application access, administrative scope and access-package assignments—not membership alone.

5

Move dependencies in a controlled order

Avoid creating an access or licensing gap. For licence migrations, confirm the destination assignment before removing the original one.

6

Monitor and close

Test joiner, mover and leaver changes; monitor processing and assignment errors; document residual risk; then pause or remove the obsolete configuration.

Use the RACF-CC Safe Enforcement Pattern

Inventory → pilot → compare → validate → migrate → monitor → review

The technically correct replacement is not complete until access, licences and operational outcomes have been verified. Open the Safe Enforcement guide →

Evidence and residual risk

Prove the outcome—not just the rule change

CoverageAffected groups, administrative units and automatic assignment policies found, replaced and still unresolved.
Membership comparisonObjects added, removed, unchanged and awaiting investigation, with approval for intentional differences.
Downstream validationLicensing errors, Conditional Access outcomes, application access, administrative scope and access-package assignments.
Lifecycle testingEvidence that joiner, mover and leaver changes update the replacement population as expected.
Data qualityBlank, inconsistent or delayed attributes; synchronisation failures; ownership and correction process.
Residual riskUnmigrated dependencies, compensating controls, accountable owner, review date and escalation trigger.

Attribute-based rules transfer risk to data quality

If job title, department or another source attribute is incomplete or slow to update, access and licensing can still become inaccurate. Assign ownership for the source data and monitor exceptions after migration.

Sources and status

Recheck Microsoft guidance before migration

Last checked: 10 August 2026. Dates and product behaviour can change. Treat the notice in your organisation's Microsoft 365 Message Center and current Microsoft Learn documentation as authoritative.

Voluntary support

Found this useful? Support Trends4You

Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they've helped you or your organisation, you can support the time and hosting that keeps them freely available.

Support is optional, handled securely by Stripe and does not provide additional access.