Services
Entra Assessment: MemberOf FunctionalityThe memberOf preview stops evaluating after 3 November 2026. No error, no alert, no red banner. Every membership list built on it becomes a permanent snapshot of that date, so leavers keep access and joiners never get it.
We find every use in your tenant, tell you what depends on it, and give you a decision per group with the evidence behind it.
The Problem
An outage gets noticed in minutes. A frozen access model gets noticed at an audit.
When a MemberOf rule stops evaluating, the damage spreads to everything downstream of the group:
- SharePoint and Teams. Leavers keep site and channel access.
- Conditional Access. New employees fall outside the policy scope they should be inside.
- Group-based licensing. New starters go unlicensed while departures keep consuming licences.
- Access packages. Time-bounded grants quietly become permanent.
- Dynamic administrative units. Delegated admin scope drifts from the org chart.
If your access control procedure says membership is maintained automatically, and the rule maintaining it has silently stopped, your documented process and your actual system state have diverged. Proving who had access to what, and for how long, is a great deal harder after the fact.

MemberOf Assessment
1. What We Do
Three surfaces, not one
Most reviews check dynamic groups and stop. Two other places carry memberOf rules and are routinely missed:
Dynamic administrative units. Configured once, never reviewed, invisible in a normal access review.
Entitlement management auto-assignment policies. The rule lives inside the policy rather than on a group object, so a group export never sees it.
We map the consumers, not just the groups
The migration risk is not in the group object. It is in what depends on it. For every finding we resolve the Conditional Access policies that target it, the licences assigned through it, the site or team behind it, the access packages that grant it, and any PIM eligibility attached to it. Each finding is ranked Critical to Low on that basis, so you fix the security controls before you fix the mailing lists.
We tell you what each rule was trying to say
For each rule we read the current membership and test whether a supported attribute rule expresses the same population. Where one does, you get the proposed rule and the exact delta in both directions: who would lose access, and who would gain it.
That second number is the one that matters. A rule that drops three people gets reported to your service desk by lunchtime. A rule that quietly adds thirty never gets reported at all. We will not propose a rewrite that widens access.
We flag the groups that need more than a rewrite
Some memberships genuinely are "everyone in these other groups", with no attribute that expresses them, and they have to stay current. For those, converting to assigned membership is not a migration. It is a decision to let the list go stale slowly instead of instantly. We name those groups explicitly rather than closing the ticket.

2. What You Get
| Deliverable | What it is for |
| Assessment report | The register, ranked by risk, with the rationale and evidence for every recommendation. Written to be read by an auditor. |
| Migration tracker (CSV) | One row per object, with owner, target date and status columns ready to run the project from. |
| Intent model (JSON) | A declarative record of what every rule was trying to express. Survives the migration, and re-points at whatever Microsoft ships next. |
| Validation plan | Before-and-after comparison method and the evidence trail your quality system needs. |
3. How It Works
Read-only, and provably so. The tool requests read scopes only. It issues HTTP GET to Microsoft Graph and nothing else. That is not a promise in a slide, it is an automated test that runs on every build and fails it otherwise.
Nothing is installed in your tenant. No app registration to create, no infrastructure to deploy, no agent, no service account left behind. Your administrator grants delegated read consent at run time and revokes it when we are done.
Nothing is written to your tenant. Output lands on our assessor's workstation and is handed to you.
Your membership data stays yours. Membership is personal data, so reports are pseudonymised by default: counts and object IDs, not names. Named individuals appear only where you ask for them.
Why Now?
3 November 2026 is the date the rules stop evaluating. Working back from it, a tenant of any size needs discovery, a decision per group, then validation and documentation with buffer before the deadline. Starting in October means migrating your last group on the last day.
Microsoft's current guidance already goes further than the retirement notice. On dynamic group processing, the documentation states plainly: "The recommendation is to delete existing memberOf groups in your tenant." If your auditor reads that page, the question arrives before the deadline does.
Beyond the deadline
Flattening nested groups so SharePoint, Teams and Microsoft 365 group membership can read them is not a problem memberOf invented, and it is not one its retirement solves. It is a standing gap in the platform, and memberOf was only ever a partial workaround for it.
For clients who need a group's membership to stay a live union of other groups, we are building a governed membership sync that does the job properly: provenance-tracked so it only ever removes members it added itself, restricted to an explicit list of enrolled groups, blocked from writing to role-assignable groups, and auditable end to end. The assessment is the first step towards it, and its intent model is the input.

Ready to Get an Entra Assessment?
Book a Free Meeting or send us an email!
Meeting with Strator is free, no strings attached, and doesn't come with any obligations or expectations. It is simply a way to familiarise yourself with our services and processes.
FAQ
How long does it take?
Discovery runs in hours. The engagement is two weeks end to end, including the walkthrough and the written recommendations.
What access do you need?
Delegated read-only consent for the duration of the assessment: Group.Read.All, Directory.Read.All, Policy.Read.All, AdministrativeUnit.Read.All, EntitlementManagement.Read.All, RoleManagement.Read.Directory and Sites.Read.All. Your administrator grants it at run time and can revoke it immediately afterwards.
What if we find nothing?
That is a good result and still worth having in writing. "Do we use this?" becomes a dated, sourced answer instead of an assumption, which is exactly what you want on file when the question comes up in an audit.
What if Microsoft ships a replacement?
Then the register tells you what to migrate onto it, and the intent model tells you what each rule was for. Neither becomes obsolete. The only thing a replacement changes is which option you pick per group.
Do you do the migration too?
Yes. The assessment is deliberately separable, so you can take the report and run the work in-house if you prefer.

