Entra stops updating MemberOf groups on November 3: What it means for SCIM provisioning

On November 3, 2026, Microsoft retires the memberOf rule operator in Microsoft Entra ID. If one of your enterprise customers assigns your app through a dynamic group that uses it, your provisioning integration does not break that day. It goes quiet. New hires stop arriving, people who move to another team keep their access, and nothing in Entra or in your app reports an error.

What changes on November 3

Microsoft announced the retirement in Message Center post MC1448379 on August 5, 2026, and repeated it in MC1488834 on October 5, 2026. The operator never left public preview. During that preview, Microsoft observed that using memberOf can slow dynamic membership processing for all groups in a tenant.

MC1488834 is specific about what happens:

Three kinds of configuration are affected: dynamic membership groups, dynamic administrative units, and entitlement management auto-assignment policies. For a B2B SaaS vendor, the groups are what matter. Microsoft's documentation describes the result as stale access and enforcement gaps, and names Teams, SharePoint, and other applications that depend on dynamic group membership as recipients of outdated membership information.

Nothing is deleted. The group still exists. It still has members. Query it over Graph and it answers fine. It just stops changing.

Why your app will not notice

Entra provisions users into your product by calling the SCIM 2.0 endpoint you expose. Which users it calls about comes from assignment. When the provisioning scope is set to Sync only assigned users and groups, the provisioning service provisions or deprovisions users based on whether they belong to a group assigned to the application. An admin makes that assignment under Entra ID > Enterprise apps > All applications > Users and groups > Add user/group. Only users in the assigned group get access, and the assignment does not cascade to nested groups. Group-based assignment requires Entra ID P1 or P2.

The provisioning service can read and provision users in dynamic membership groups, and Microsoft states that how fast a user is provisioned or deprovisioned in a SaaS app depends on how fast the dynamic group can evaluate membership changes. It also states that losing membership in a dynamic group counts as a deprovisioning event. Freeze the evaluation and you freeze both halves of that.

Here is what your endpoint sees. Each incremental cycle queries Entra for users and groups updated since the last watermark, then filters them through the configured assignments and scoping filters. Entra keeps running those cycles back to back, indefinitely. After November 3, the membership of a frozen group never changes, so the filtered set never changes, so your endpoint receives nothing for it. No POST /Users for the new hire. No removal for the person who changed teams.

What still gets through. Group membership is only one of the ways Entra decides to deprovision someone. Microsoft lists four triggers for a disable or delete: the user is soft-deleted or has accountEnabled set to false, the user is permanently deleted, the user is unassigned from the app, or the user falls out of scope. The first two don't depend on group membership. So a leaver whose Entra account is disabled or deleted is still deactivated in your app, frozen group or not. The people who slip through are the ones whose account stays enabled: someone who changes role, a contractor whose project ends but whose account lives on, anyone whose access was supposed to end by leaving a source group.

The table puts it in one place.

The removal gap may already be there. Microsoft's memberOf documentation has a note that applies today, not just after November 3: 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. Those users stay in the dynamic group until the rule is modified. If a customer has run a memberOf group for months, people who left a source group in that time may still be provisioned into your app. The audit below is worth doing even if they fix the rule on time.

There is no error state to catch either. A provisioning job goes into quarantine when most or all of its calls against the target system consistently fail, for example because of invalid admin credentials. A cycle with nothing to send isn't a failed cycle. The job stays green, the cycle history keeps ticking, and the directory looks like a company where nobody joined or changed teams.

How an Entra admin finds the affected groups

This is the part to forward to your customer's IT team, because every step happens in their tenant.

Microsoft's documented starting point is to export dynamic membership groups from the Microsoft Entra admin center and identify the rules that contain memberOf. A memberOf rule looks like this:

  
user.memberof -any (group.objectId -in ['groupId'])
  

The same sweep works through Microsoft Graph. A group has dynamic membership when its groupTypes collection includes DynamicMembership, and groupTypes supports $filter with eq. The membershipRule property holds the rule text and is returned by default, alongside membershipRuleProcessingState, which indicates whether processing is On or Paused:

  
GET https://graph.microsoft.com/v1.0/groups?$filter=groupTypes/any(c:c eq 'DynamicMembership')&$select=id,displayName,membershipRule,membershipRuleProcessingState
  

Microsoft documents $filter on membershipRule for eq, ne, not, ge, le and startsWith, so a rule with memberOf buried in the middle will not match a server-side filter. Pull the dynamic groups and search the membershipRule strings locally.

For each group that comes back with memberOf in its rule, the question is whether it is assigned to a provisioning-enabled app. Graph answers that from either direction. From the group:

  
GET https://graph.microsoft.com/v1.0/groups/{group-id}/appRoleAssignments
  

That operation returns the apps and app roles assigned to the group. From the application:

  
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=displayName eq '{app-name}'
GET https://graph.microsoft.com/v1.0/servicePrincipals/{id}/appRoleAssignedTo
  

Or do the whole sweep in one go with Microsoft Graph PowerShell. This lists every memberOf dynamic group that is assigned to an app, with the app's name:

  
Connect-MgGraph -Scopes "Directory.Read.All"

$groups = Get-MgGroup -All `
  -Filter "groupTypes/any(c:c eq 'DynamicMembership')" `
  -Property Id,DisplayName,MembershipRule

$groups | Where-Object { $_.MembershipRule -match 'memberof' } | ForEach-Object {
  $group = $_
  Get-MgGroupAppRoleAssignment -GroupId $group.Id -All | ForEach-Object {
    [pscustomobject]@{
      Group = $group.DisplayName
      App   = $_.ResourceDisplayName
      Rule  = $group.MembershipRule
    }
  }
} | Format-Table -AutoSize
  

Any group that appears in both lists needs to be fixed before November 3.

What to replace memberOf with

Microsoft gives two options for dynamic membership groups, and no third:

1. Replace memberOf with supported rule operators where an equivalent rule exists.
2. Convert the group to assigned membership when no supported dynamic alternative is available.

Validate the resulting membership after the change, and pause or delete the group if it is no longer needed.

The first option is less work than it sounds, because memberOf groups were always flat. Only direct members of a source security group ever became members of the memberOf group, and the operator could not be combined with other rules or other operators at all. What's being replaced is a plain list of people defined by their membership in other groups, not a nested hierarchy.

Where those source groups correspond to something on the user object, Microsoft's guidance on efficient rules applies: use -eq when the full attribute value is known, -startsWith or -endsWith when only a prefix or suffix is known, and -in to collapse several values for the same property into one criterion instead of chaining -or.

The right swap depends on what the source group represented, so treat the shapes below as an illustration rather than a mapping Microsoft publishes. A group that stood in for a department converts cleanly. A group assembled by hand, from people with nothing in common on their user object, usually does not.

That second row carries a cost worth naming out loud. Converting to assigned membership moves the group from something the directory maintains to something a person maintains, and whoever inherits it has to remember to update it every time someone joins or leaves. For a group feeding app provisioning, a forgotten manual list is the same gap the retirement creates, just slower. An option that avoids the extra group entirely: assign the original source groups to the app directly, if they are security groups and there are only a few of them.

Microsoft says it is continuing to develop an alternative that meets the scenarios memberOf addressed with the right scalability and reliability. There is nothing to adopt today, so plan around the documented options.

A paragraph you can send your customers

Paste this into an email to the IT contacts at your enterprise accounts:

After November 3, what your team can check

Everything above happens in the customer's tenant. On your side, the useful work is catching someone who should have lost access and did not.

Spot-check access against the source groups. For a customer who provisions from Entra over SCIM, pick a few users whose role in your app came from group membership, and ask the customer's admin to confirm they are still in the right source group. A mismatch is a strong sign the assignment runs through a frozen group, and worth a look either way.

Compare quiet directories with busy ones. If a tenant that used to send a handful of SCIM writes a week has sent none since early November while comparable tenants have not changed, that is worth a conversation with the customer. If you use WorkOS Directory Sync, the Dashboard shows SCIM request logs for each directory, with full request and response payloads, retained for 30 days with sensitive values redacted, under the directory details of an organization.

Directory Sync receives what Entra sends, so this change affects apps on Directory Sync like any other SCIM integration, and the fix happens in the customer's Entra tenant. The Admin Portal is where a customer's IT admin sets up the Entra connection, which makes it the right place to send them if the connection itself needs rebuilding.

Some customers will not answer the email before November 3. Flag those accounts now and put them on a manual access review, because the alternative is finding out from a security questionnaire six months later. The calendar is the only reliable alert here.

Read more

• What Okta and Entra ID actually send to your SCIM endpoint
• Azure Entra nested groups and Directory Sync
• What are SCIM groups?
• Entra ID SCIM setup with WorkOS (docs)

Sources

• MC1448379: Microsoft Entra ID: Replace MemberOf rules by November 3, 2026 (August 5, 2026)
• MC1488834: Final reminder to replace MemberOf rule operator configurations by November 3, 2026 (October 5, 2026)
• Configure dynamic membership groups with the memberOf operator (Microsoft Learn)
• Create simpler, more efficient rules for dynamic membership groups (Microsoft Learn)
• How Application Provisioning works in Microsoft Entra ID (Microsoft Learn)
• group resource type, Microsoft Graph v1.0 (Microsoft Learn)
• Dashboard SCIM Logs (WorkOS changelog, September 4, 2026)