Here’s what you should do before November 3. 

What did memberOf actually do? 

The preview let a dynamic group rule pull in the members of other groups: 

user.memberOf -any (group.objectId -in ['<groupObjectId1>', '<groupObjectId2>']) 

It was the closest thing Entra ID had to nested groups that downstream services could read. Organisations used it to flatten a group hierarchy into something SharePoint, Teams, Conditional Access and group-based licensing could consume, because nesting has never worked cleanly for those consumers. 

Microsoft's stated reason for pulling it is scale. During the preview, memberOf was observed to slow dynamic membership processing across an entire tenant, not just for the groups using it. The alternative might be in development, but nothing is releasing yet. 

What will break, and where will you feel it first? 

Frozen membership propagates into everything downstream of the group: 

• SharePoint and Teams access. Leavers keep site and channel access. Joiners never get it. 

• Conditional Access targeting. New employees fall outside a policy scope they should be inside. Your MFA or device compliance policy silently stops covering people. 

• Group-based licensing. New starters go unlicensed. Departures keep consuming licences you pay for. 

• Access packages. Auto-assignment policies stop assigning and stop removing, so a time-bounded grant quietly becomes permanent. 

• Dynamic administrative units. Delegated admin scope drifts away from the org chart. 

For regulated organisations there is a second-order problem. If your access control procedure says membership is maintained automatically by an attribute-driven rule, and that rule has silently stopped evaluating, your documented process and your actual system state have diverged. That is an audit finding, and it is hard to bound afterwards. You have to prove who had access to what, and for how long. 

Which parts of the tenant do people forget to check? 

Almost everyone checks dynamic groups. Two other surfaces carry memberOf rules and almost nobody checks them: 

• Dynamic administrative units. Configured once by someone on the identity team, never touched again, and invisible during a normal access review. When one freezes, delegated admin scope stops tracking the org chart. 

• Entitlement management auto-assignment policies. The rule lives inside the policy's allowed-targets configuration rather than on a group object, so a group-focused export misses it entirely. 
  Both need Microsoft Graph to enumerate properly. Neither shows up if you search only the Groups blade in the admin center. 

The detail almost everyone misses: some of your memberships are already frozen 

Here is the finding that changes how you prioritise, and it comes straight from the preview's documented limitations. 

• memberOf never removed members when a source group was deleted, or when a member was removed from a source group. The documentation states it plainly: affected users remain members of the memberOf group until the rule is modified. 

Read that against the retirement notice. It means the 3 November freeze is not the start of your drift. If any source group referenced in one of your rules has been deleted, or has had members removed, some of your access is already stale today, and has been for as long as that source group has been gone. 
This is why a memberOf discovery exercise should resolve every source group ID in every rule and check whether it still exists. An unresolvable source group ID is not a data-quality annoyance, but a marker for access that stopped tracking reality some time in the past. That is exactly the kind of thing you would rather find yourself, than have found for you during an audit. 

How do you decide what to do with each rule? 

There are three honest outcomes, and a fourth that people avoid naming. 

Rewrite with supported operators. If the source groups correspond to a real attribute, such as department, job title, company name or an extension attribute, express the rule against that attribute directly. That could be considered the best outcome, and it usually forces an overdue conversation about HR data quality. 
Convert to assigned membership. Freeze the membership deliberately and manage it through your joiner/mover/leaver process. It is boring, auditable, and honest about who owns the list. 
Delete the rule. A meaningful share of preview-era groups turn out to serve nothing. 
Accept that some groups need a live union. This is the one people skip.This is the one people skip. If a group's membership only consists of all members in other groups, there is no attribute that expresses that. If it has to stay current, then assigned membership is not a migration.

How do you test a rewrite before you apply it? 

You want both your coverage and precision to be at 100%, but most migration plans only track coverage. 
Coverage is the share of current members the proposed rule still includes. Coverage below 100% means people lose access at cutover. You will hear about it the same morning. 
Precision is the share of the proposed rule's population that is a current member. Precision below 100% means people gain access at cutover. Nobody reports that, which is exactly why it is the dangerous one. 

A rule at 100% coverage and 80% precision looks like a clean migration on the day and is a silent over-grant forever after. When we built our own assessment tooling, we made precision the blocking threshold rather than coverage: the tool will not propose a rewrite that widens access, but it will happily propose one that leaves you a named list of eight people to add back by hand. A short manual task beats an invisible permission expansion. 

Whichever way you compute it, validate the candidate rule in the Entra portal before applying it, and compare membership before and after. 

A 3-step approach 

Step 1: find every use. Export dynamic groups and search the rules for memberOf. Do the same for dynamic administrative units and entitlement management auto-assignment policies via Graph. For each hit, record what consumes it: sites, teams, Conditional Access policies, licence assignments, access packages. The migration risk lives in the consumers, not the group object. If you need certainty and help, get in touch for a free assessment. 
Step 2: decide per group. Note the constraint that pushed people to memberOf in the first place: it could never be combined with other rules or operators. So a rewrite is rarely a like-for-like translation. It is a chance to express the intent properly. 
Step 3: validate and document. Compare membership before and after, confirm the downstream consumers still resolve, record the change. Under GxP, NIS2 or DORA the validation evidence is the deliverable. Leave buffer before 3 November. You do not want the last group migrated on the last day. 

Working with memberOf groups in a regulated environment?

We run a read-only assessment of your tenant and hand you the register, the per-group recommendation and the validation plan. Get In touch

Ulrich Bojko
Head of Development

The post The Entra MemberOf Retirement: Your Groups Won’t Break, They’ll Freeze  appeared first on Strator.

 The shift is that lifecycle, permissions and classification are becoming the conditions of entry for artificial intelligence, rather than optional refinements to be addressed later. For any organisation planning a Microsoft 365 Copilot rollout in the second half of the year, the changes below are not background detail. They are the new ground rules, and they all point in the same direction.

Grounding Copilot in Trusted Sources 

The most visible of the new capabilities is Authoritative Sites. It allows an administrator to designate specific SharePoint sites as trusted, so that Microsoft 365 Copilot prioritises their content when it answers questions in Copilot Chat and Copilot Search. The setting is applied per site, it requires a Copilot licence, and it is disabled by default. 

The intent is sound. In a large tenant, Copilot must ground its answers in something, and not all content deserves equal weight. The policy published last week and the abandoned draft from several years ago should not carry the same authority, and Authoritative Sites lets an organisation favour the sources that have earned trust. 

What the capability does not do is establish trust on your behalf. Marking a site as authoritative is only beneficial if the site is genuinely current, accurate and well managed. Directing Copilot towards a site filled with stale, duplicated or mislabelled material will, predictably, result in an assistant lacking in reliable information. It is an assistant that repeats your worst content with new confidence, now carrying your own stamp of authority. The feature assumes the organisation already knows which of its sites are trustworthy, but most organisations do not. That assumption is the common thread that runs through the other updates as well. 

External Sharing Becomes Governed by Default 

For years, sharing content with someone outside the organisation would rely on a one-time passcode sent by email. That mechanism is being retired. From July 2026, SharePoint's one-time passcode authentication begins to wind down, and external sharing transitions fully to Microsoft Entra B2B, with completion expected by the end of August. New external invitations already moved to this model earlier in the year. 

In practice, every external recipient now becomes a managed Entra B2B guest rather than the holder of a temporary code. This is a clear improvement in governance, because external access thus falls under the same controls as everything else: Conditional Access, identity protection and centralised guest management. It is also a deadline. External users who relied on the old method can lose access to previously shared content, and the administrative toggle that once governed this behaviour is being removed. 

The implication is straightforward. The guest estate that many organisations have never formally reviewed is about to become a governed surface, whether they are prepared for it or not. Reviewing who has external access, before the transition completes, is time well spent. 

Classification Becomes a Boundary, not a Suggestion 

Permissions describe what a user is allowed to open. They have never, on their own, described what an AI system should refrain from touching. That distinction is now being drawn. 

Through Microsoft Purview, sensitivity labels can exclude content from Copilot grounding, with enforcement rolling out to completion by the end of July. A document classified at a restricted level can be kept beyond Copilot's reach even for users who hold permission to open it directly. Classification stops being advisory metadata and becomes an enforceable boundary, preventing Copilot from gaining access simply because "the user had access", as was the inadequate justification prior to the update.   

For regulated industries this is not a convenience; it is the difference between a Copilot deployment that can be defended and one that surfaces controlled information into a generated answer because the permissions happened to allow it. As with Authoritative Sites, the protection only functions where the labels already exist. A boundary is held only where someone has formed it. 

Governance Becomes a Discipline You Can See 

The quieter theme across these changes is that governance itself is being treated as an operational discipline rather than an annual cleanup. Microsoft is consolidating the activity around site reviews, inactivity, ownership, and attestation into clearer surfaces for the people responsible, and it is improving the reporting that lets administrators locate oversharing and permission risk, so you no longer have to guess. 

Governance is acquiring its own instrumentation, which means it can be measured, assigned and acted upon as ongoing work. 

The Common Premise: Governance Is the Price of Admission 

Step back from the individual features, and the shared premise of these updates is impossible to overlook. Each new capability reads information that is expected to already exist on the site, and acts upon it. Authoritative Sites depend on knowing which sites merit trust. Purview's protection relies on labels having been assigned. Ownership and attestation reviews depend on there being a valid owner to contact. None of these controls create the underlying information; they all consume it. 

Which raises the question: where does that information come from? 

The Half of the Lifecycle Nobody Governs 

Microsoft governs the middle of a site's life and its end. Inactivity detection, ownership reviews, attestation and archiving are all steady-state and end-of-life controls. They assume that a site already exists, already has an owner, already carries a classification and a sensible permission model. They operate on metadata that someone, at some earlier point, was expected to put in place. 

Almost nothing governs the beginning, and the beginning is where the outcome is decided. A site created without a clear owner leaves the attestation policy with no one to notify. A site created without a sensitivity label gives the Purview boundary nothing to enforce. A site created with broad, inherited permissions becomes exactly what the oversharing report will report on later down the line. The costly remediation that fills most governance programs is, almost entirely, the accumulated price of sites that were never established correctly in the first place. This is the gap that experts at Strator are trained to close.

Microsoft's tools are only ever as reliable as the information already recorded on the site. The work of ensuring that information exists from the first moment, and of repairing it where it is missing, is a separate discipline from the controls that later depend on it. 

Two Halves of the Same Lifecycle 

Strator's approach and Microsoft's native lifecycle management are not alternatives to one another. They govern different halves of the same lifecycle, and the provisioning half is the precondition for the steady-state half to function. 

The relationship is direct at every point. Authoritative Sites becomes trustworthy when sites are already classified by tier, because that classification is the natural shortlist of sources that have earned Copilot priority. Purview's classification boundary becomes legitimate when labels are applied at creation rather than retrofitted under pressure. Ownership and attestation reviews become meaningful when valid owners exist from the outset, leaving no orphaned sites for the review to stall on. And oversharing reports have less to find when sites are provisioned with least-privilege access by default. In each case, the native control inherits a foundation it did not have to build. 

Where a Copilot Rollout Actually Begins 

The lesson of this summer's changes is that a Copilot rollout does not begin with a licence. It begins in the content estate beneath it, in the unglamorous discipline of ownership, lifecycle and classification on which every one of these new features quietly depends. The organisations that will adopt Copilot with confidence are the ones that did this work first, and treated it as a foundation rather than a cleanup. 

Microsoft governs the middle and the end of a site's life. Strator governs the beginning. And the beginning is what decides whether everything that follows can be trusted. 

The post Govern First, Then Turn On the AI appeared first on Strator.

This distinction matters more now than ever before, because the strategic stakes are real and the marketing around them is loud. Two recent and substantial pieces of work help cut through the noise: the Danish Agency for Digital Government's December 2025 report on open source in the public sector, and an international survey of sixteen digitally mature countries it commissioned the year before. Read together, they point to the same uncomfortable but useful conclusion. Digital sovereignty is a capability, and capabilities have to be built.

Sovereignty Is Not a Product You Can Buy 

It is tempting to believe that a particular kind of platform settles the question. It does not. You can be genuinely independent on a proprietary stack if you are well governed, and completely trapped on open source if you are not. The brand on the box decides very little. The organisation around it decides almost everything.

The major providers themselves demonstrate the point. Over the past year Microsoft has completed its EU Data Boundary, and introduced sovereign options such as customer-held encryption keys, Europe-based access controls and on-premises deployment of core workloads, all aimed squarely at sovereignty concerns. These are serious investments, and they make sovereignty achievable on a hyperscale commercial cloud in a way that was not possible a few years ago. At the same time, residual questions remain, such as the reach of foreign legislation over data physically stored in Europe, which no purchasing decision fully removes on its own. The lesson is not that one provider is safe and another is not. The lesson is that whatever you choose, the responsibility to understand what you hold, where it sits, and how you would abandon it if needed, does not transfer to the vendor. It stays with you.

So, the real question is never "which platform makes us digitally sovereign." It is "do we understand our configuration, own our data, know our contracts, and have a funded way to change course." Those are organisational properties, not product ones.

Control and Responsibility Are the Same Decision 

The Danish 2025 report is blunt about the trade nobody likes to name. When you take more control of your technology, you also take on more responsibility: licence terms, security updates, support, maintenance, and simply knowing what you are running. Control is not a prize you collect. It is a workload you accept. The report is careful never to claim that more openness is always better; it says the opposite. Make choices based on the value they bring, and be honest about whether you can carry out what you have chosen.

Denmark built a dedicated Open Source Office for its health sector. Although, it was technically well regarded, it withered anyway. Not because of the quality of the code, but because of a lack of organisational and financial backing. Technical excellence does not provide the capability to sustain operational backing. Funding, ownership and leadership do. Especially leadership. The same pattern appears in reverse wherever sovereignty succeeds. It is sustained by an organisation with leadership that decided to allocate resources to it, not by a licence that happened to permit it.

This is why the smallest organisations struggle the most, and why the answer is rarely a heroic in-house rebuild. Acquiring a capability is demanding precisely because it is real work, and pretending a platform removes that work is how dependence quietly accumulates.

The Preconditions Are Where Sovereignty Is Actually Built 

If digital sovereignty is a capability, the practical question becomes what that capability is made of. The Danish report, drawing on the experience of public authorities at home and abroad, sets out a clear and, helpfully, vendor-neutral list of preconditions. These preconditions apply just as much to proprietary software as to open source.

The first precondition is organisation and leadership. Someone has to back the decision, articulate why it is being made, and invest in the competence to carry it, whether that competence is built internally or bought in. The second is a deliberate decision about support and maintenance. It is needed whether the software is open source or not. All software needs support and maintenance, and leaving it unowned would be a mistake. The third is the ability to assess security and maturity, to judge whether there is an active community or a competent supplier behind a component, rather than assuming a license fee guarantees it. The fourth is genuine command of licences, contracts and data, knowing what terms bind you, where your information lives, and what your agreements actually say. The fifth is open standards and integration building, so that systems can talk to one another and, crucially, so that you could change a supplier later without dismantling everything. The last is honest lifetime economics, comparing the full cost of a solution over its life rather than its sticker price, because the value of being able to move never appears on an invoice.

None of these are technical tricks. Every one of them is a discipline. Together, they are what digital sovereignty actually consists of, and the encouraging part is that they can be deliberately developed.

No Organisation Stands Alone 

Organisations do not have to acquire the capability to posses digital sovereignty by themselves, and the most mature countries have understood this. The recurring pattern in the international survey is the rise of shared stewardship: neutral organisations that posses this capability on behalf of many. In Denmark, the OS2 community lets municipalities pool funding and competence around shared solutions, on the principle that those who rely on something help sustain it and keep the ability to change suppliers. Estonia and Finland went as far as founding a joint institution, with staff and a budget, simply to steward software they share. Italy has built a state office to guide and support adoption of open source, Germany has established both a public body to develop shared solutions and an agency to fund the maintenance of critical open source, and the European Union is assembling common building blocks several countries can draw on.

What matters is not which model wins, but that every one of them treats capability as something to be funded, staffed and shared, rather than assumed. Digital sovereignty, at scale, is a collective discipline as much as an individual one.

Digital Sovereignty Is a Leadership Posture 

Leadership, specifically the CIO and/or CTO, are the ones who need to make decisions on digital sovereignty. It is important they do so, during the procurement process itself. Data location, exit-readiness, open standards and clarity over contracts should not be afterthoughts raised once a platform is already chosen. They belong to the requirements, as standard, applied to every vendor regardless of who they are. Treated that way, digital sovereignty becomes the decision to take responsibility for your own infrastructure, to know what you run and why, and to keep your options open on purpose.

The most durable examples are governed, not improvised. Aarhus, for instance, did not become more digitally independent through a single product switch. It set a direction over many years, from a requirement to consider alternatives, to an action plan, to a digital strategy, to budgeted money set aside to widen its choice of suppliers. The throughline is not a technology. It is sustained, value-driven governance, and a refusal to let someone else set the cadence by default. The longstanding principle behind it is worth remembering: choose the best and most economical option regardless of software type.  These options need to be chosen by an organisation that understands what it is choosing.

That capability is what we build at Strator. The platform is yours either way, commercial or open, cloud or on-premises. The real question is whether you can steer it, and whether you could leave it if you ever had to. Digital sovereignty is not simply a phrase on the contract; it is the knowledge that the organisation knows its situation and has the ability to migrate if it chose so.

The post Digital Sovereignty Is Not a Licence. It Is a Capability. appeared first on Strator.