Control & Sovereignty Archives - Strator

The Entra MemberOf Retirement: Your Groups Won’t Break, They’ll Freeze

Ulrich Bojko — Thu, 13 Aug 2026 09:46:36 +0000

The memberOf rule operator in Microsoft Entra ID stops evaluating after 3 November 2026, and the failure mode is silence. Dynamic membership groups, dynamic administrative units and entitlement management auto-assignment policies that use it will not throw an error or disappear. They will simply hold their 3 November membership forever, so leavers keep access and joiners never get it. An outage gets noticed in minutes. A frozen access model gets noticed at an audit.

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 ['', ''])

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.

Digital Sovereignty Is Not a Licence. It Is a Capability.

Ulrich Bojko — Thu, 02 Jul 2026 13:29:57 +0000

Digital sovereignty has become one of the most frequently used phrases in technology strategy, despite being one of the least examined concepts. It is increasingly attached to products, as though it were a feature that could be switched on, or a property of the brand printed on the contract: choose this platform and you are sovereign; choose that one and you are captured. The reality is almost the opposite. Digital sovereignty is not a quality of the software you buy; it is a quality of the organisation that runs it.

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.

What is Digital Sovereignty – When We Talk About Documents?

Vibeke — Wed, 04 Mar 2026 12:23:33 +0000

In recent years, digital sovereignty has become a central concept in discussions about technology, geopolitics and digital infrastructure. In its publication on the topic, the Danish IT Industry Association describes digital sovereignty as the access and ability to develop, use, protect and maintain critical technologies necessary for economic, security and political independence.

Behind this definition lies the recognition that modern societies are deeply dependent on digital infrastructures and global technology providers. When data, systems and digital services operate within infrastructures that organisations or states do not themselves control, a strategic dependency arises.

Managing technological dependencies is not in itself a new challenge. Organisations have always had to deal with risks such as system failures, supplier dependencies or technological obsolescence. What has changed is the degree of dependency, which today gives the issue a different character.

A large share of organisations’ digital environments is now based on service-based platforms delivered by a small number of global providers. These platforms are often deeply integrated into daily operations and work processes, making them difficult both to replace and to move. Technological dependency therefore becomes both more pronounced and more extensive. It is no longer sufficient to view such dependencies as local IT risks. Instead, they increasingly represent strategic risks. Their management consequently moves into executive management and boardrooms under the heading of digital sovereignty.

The question, then, is what this means in relation to organisations’ documents and information assets.

Digital Sovereignty in Document and Information Management

In this article we explore what digital sovereignty may mean in the context of document and information management. The concept is still relatively new in this context, but it is reasonable to ask whether well-established professional disciplines already contain many of the tools needed to address it.

As described above, the concept of digital sovereignty arises from the recognition of technological dependencies. When organisations depend on technologies and infrastructures they do not control themselves, the question arises of how much influence they actually have over the frameworks within which their digital activities take place.

Ultimately, digital sovereignty therefore becomes a question of control. The central issue is not necessarily whether an organisation can eliminate its technological dependencies, but rather to what extent it can retain control – and freedom of action – over the technologies and infrastructures on which its digital activities depend.

For professionals working with document and information management, the idea of control immediately sounds familiar. In this field, control over information has always been a central concern.

A closer look quickly points to several fundamental elements of what control over organisational documents actually consists of.

The first is overvew.

Overview of Information Assets

In practice, organisations store documents in many different places. They may be located in collaboration platforms, case management systems, quality management systems and other specialised applications. They may also be stored in shared drives or in document libraries connected to projects and work processes. In addition, older systems and archives often hold historical documentation.

Having control over documents therefore begins with the ability to form a coherent overview of this information landscape. The organisation must know where its documents are located and which systems and technologies they depend on.

In practice, such an overview also requires the organisation to define the types of documents it actually holds. Without an understanding of what the information consists of, it becomes difficult both to map and manage it.

Which Documents Are Important?

However, an overview of documents is not sufficient in itself. Organisations produce large quantities of documents, but not all of them have the same significance.

Some documents serve primarily a temporary role in work processes – for example drafts or working notes. Other documents have far greater importance for the organisation. These may include contracts, regulatory documentation, quality system documentation, project decisions or technical documentation related to products and intellectual property.

When documents serve such functions, they act as documentation of the organisation’s activities and decisions. It is therefore essential that they remain usable in that capacity. Control over information assets therefore also involves knowing which documents have this status.

The Context of Documentation

In information science, such documents are referred to as records, and their continued value as documentation depends on proper handling.

Records management standards, including ISO 15489, describe this through concepts such as authenticity, integrity, reliability and usability.

The credibility of documentation depends to a large extent on the context in which it exists and the processes it has undergone. This context may include information about who created the document, when it was approved, what role it played in a process, or which versions existed along the way. Classification, metadata and version history can therefore be crucial to how a document is understood and used as evidence.

Documentation must be preserved in a way that makes it possible to understand what the document is, where it originated, and what role it played in the organisation’s activities.

When dealing with records, control therefore concerns not only the document files themselves but also the context that makes the documentation meaningful.

Technological Embedding

In practice, this context is often closely embedded in the systems where documents are managed.

Metadata capturing the document’s context is often stored within the system. Version histories are maintained within system functionality. Classification structures and access rights are governed by system logic and data models. A large portion of the information that gives documentation its meaning therefore does not exist independently of the technological environments where documents are processed.

This also means that the value of documentation becomes dependent on these technologies. If a system changes, is phased out or replaced, the organisation’s ability to preserve the structure and coherence of its documentation may be affected.

When analysing what it means to have control over information assets, this adds a technological dimension. Organisations must understand and manage the metadata and processing traces that are essential for their records to retain their documentary value.

What Does Control Over Documents Mean?

Bringing these perspectives together suggests that control over documents in a digital sovereignty context consists of several elements.

Organisations must have an overview of their information assets and know where documents are located. They must be able to distinguish between documents that merely support work processes and those that function as documentation of organisational activities. They must understand the context and metadata that make documentation trustworthy. And they must understand the technological environments on which this documentation depends.

Seen in this light, digital sovereignty in document and information management is not primarily a technological question. It is a question of an organisation’s ability to maintain control over its information assets and their documentary value – even when they are embedded in digital systems and platforms.

At the same time, the analysis points to something else: much of what is described here as responses to digital sovereignty challenges already exists within established professional disciplines. Information specialists, records managers and others who work professionally with information management already deal with overview of information assets, assessment of document significance, understanding of documentary context and management of technological dependencies.

Digital sovereignty in document and information management is therefore not necessarily a new discipline that must be invented from scratch. Rather, it represents a new perspective on a familiar professional domain, where classical disciplines within information management acquire a clear strategic significance.

The post What is Digital Sovereignty – When We Talk About Documents? appeared first on Strator.