Your group estate is not governed. It is just synced.

Group Source of Authority is often treated as a synchronisation or migration detail. In practice, it is one of the structural governance questions in a hybrid Microsoft Entra environment.

It determines whether ownership, lifecycle control, access review enforcement and accountability can actually be completed for a group, or whether the organisation is only assuming that those controls apply.

That distinction matters because many group estates still work operationally while remaining weak from a governance and auditability perspective.

The ownership question most tenants cannot answer cleanly

Ask a senior identity administrator where a specific group is managed. They will almost always give you a correct answer for the mechanics: “that one comes from AD” or “that one was created in Entra.” Ask a second question, and the answer starts to soften. “Who owns it?” A pause. “Who reviewed it last?” Longer pause. “What happens if it is deleted?” Silence, or a confident answer that turns out to be wrong.

This is not a knowledge gap. It is a governance gap, and it is common enough to be the starting assumption when entering any mature hybrid tenant for the first time.

Groups were created, synchronised, inherited, migrated in part, and left in states that nobody explicitly designed. The result is a group estate where governance is assumed rather than verified. Access reviews run and produce decisions that are not enforced. Owners are assigned on paper but cannot manage their groups with the tools Entra provides. Lifecycle policies apply to some objects and silently skip others. The estate functions. It delivers access. But it is not governed, and it cannot be audited with confidence.

The group estate is where governance assumptions meet governance reality. Most organisations have invested in the policies. Fewer have tested whether those policies can actually be enforced against the objects they are supposed to govern.

Group Source of Authority is the term Microsoft uses for which system holds authoritative write control over a group object. In practice, it determines something more consequential than where an administrator makes edits. It determines which governance workflows can actually complete, which review decisions get enforced, which lifecycle policies apply and which ownership model holds when something goes wrong.

Most organisations have never asked the SOA question systematically. They are not ready for what the answer reveals.

Terminology

Group Source of Authority, in the Microsoft Entra Connect context, refers to which directory holds authoritative write control over a group object. A group with onPremisesSyncEnabled: true is on-premises authoritative; membership and attribute changes must originate in Active Directory and flow through synchronisation. Shifting SOA removes that constraint and makes Entra the authoritative source for the object. This is mechanically distinct from Group Writeback, which projects cloud-native Microsoft 365 Groups back into on-premises AD for workloads that require it. The two operations are frequently conflated and are not interchangeable.

SOA determines which governance workflows can complete, not just where you click

The most common misunderstanding about Group Source of Authority is that it is a migration decision. It is not. It is a governance architecture decision, and the practical consequence is not where an administrator opens a window. It is which services, APIs and governance controls can interact with the group as a first-class citizen.

A synced group with onPremisesSyncEnabled: true is effectively read-only from Entra’s governance perspective for the properties that matter most. The Graph API can read it, but cannot write membership. Governance workflows such as access reviews, entitlement management and lifecycle processes therefore become more constrained, because the object is not being governed as a first-class cloud-managed construct. The governance toolchain is present. Its ability to complete remediation is not equivalent to that of a cloud-native group.

SOA determines whether a group becomes a governable identity object or remains an infrastructure artefact that governance workflows work around rather than govern directly. That is a governance design decision with operational consequences that most organisations discover too late.

The governance properties of a group are decided at creation. Most architects do not treat it that way.

Every group in a hybrid Entra estate carries implicit governance properties determined by its type and its source of authority. Those properties are not configurable after the fact. They are baked into the construct. The choice of group type at creation is, in effect, a governance design decision, and most organisations make it based on habit or availability rather than on what the group will need to support.

The practical consequence is a group estate that mixes constructs with materially different governance capabilities, applies the same lifecycle and review policies across all of them, and assumes the results are consistent. They are not.

The governing principle is direct: the group type determines the governance ceiling. A mail-enabled security group cannot be made to behave like an Entra security group from a governance perspective, regardless of what policies are applied on top of it. The ceiling is structural, and it was set at creation.

What mail-enabled groups actually do to your access review programme

Mail-enabled security groups and legacy distribution lists carry governance problems that are architectural rather than operational. Understanding them matters because the failure mode is silent. No error is raised. The governance control appears to work. The access does not change.

Access review completion should not be confused with enforced remediation. When an Entra ID Governance review targets a mail-enabled security group, reviewers can complete the review and record decisions. Because membership remains Exchange-managed rather than Entra-managed, remediation cannot be assumed to behave like it does for first-class Entra-managed group constructs. Organisations that rely on automatic remediation as their primary enforcement mechanism should treat these groups as an explicit exception and verify the operational follow-through.

The silent failure: access review enforcement by group type

End-user self-service does not extend here. The My Groups portal in Entra supports Entra security groups and Microsoft 365 Groups for end-user management. Mail-enabled security groups are administrator-managed only, or handled via the Exchange self-service portal, which does not integrate with Entra governance workflows. An owner assigned in Entra has no tooling to act on that ownership for a mail-enabled group.

Ownership accountability breaks at the operational level. Entra governance models assume a defined owner who can respond to access review requests, approve requests through entitlement management and be held accountable for membership changes. Where an Exchange-tied group has a named owner, that owner often cannot exercise meaningful control through the tools Entra provides. Accountability exists on paper and not in the workflow.

None of this means mail-enabled security groups should always be eliminated immediately. In environments with Exchange-driven requirements where both mail delivery and security assignment must genuinely coexist in the same object, they retain operational relevance. The issue is treating them as a standard design pattern rather than a governed exception. When they do remain, the governance shortfalls require explicit compensation: manual review processes, documented ownership, defined remediation steps and a migration path tracked against a target state.

A group that is reviewed but not remediated is not governed. It is audited. Those two things are not the same.

Common mistake

Organisations frequently retain legacy group constructs because they “still work.” Operational availability is not governance adequacy. A group that requires manual remediation, that cannot give an assigned owner meaningful tooling, or that sits outside the scope of lifecycle policies carries governance risk regardless of whether it continues to deliver access correctly today.

The same logic applies to Zero Trust. A Conditional Access policy that grants access based on group membership is only as reliable as the process by which that membership is controlled, reviewed and adjusted. Where enforcement cannot complete automatically, the policy provides weaker assurance than its configuration suggests.

Four questions that expose whether your group estate is actually designed

The path to a governed group estate is not a migration project. It is the application of a consistent decision framework at the point where group design choices are made, and retrospectively during estate rationalisation. Four questions, answered honestly and in sequence, expose most of the structural problems.

1. What is this group actually for?
   Security boundary, collaboration workspace, mail distribution and legacy application dependency are distinct requirements. A group that controls access to a resource has different governance requirements than one that coordinates a project team. The answer to this question constrains the appropriate construct before any other consideration applies. Many group estates contain groups that were created for one purpose and are now used for another, with no change to the construct or the governance controls applied to them.
2. Which governance properties does this group need to support?
   Cloud-native ownership, lifecycle management including expiration and review, access reviewability with auto-apply enforcement, end-user self-service, delegated administration, Graph API management, entitlement management integration. Not every group needs all of these, but the group type must structurally support the ones it does need. Note that native lifecycle governance currently differs meaningfully between group types: Microsoft 365 Groups support group expiration natively, while Entra security groups require Lifecycle Workflows or an externally managed process as an alternative.
3. Is a legacy or Exchange-tied construct genuinely still justified?
   This question should only be reached after the first two. Where a legacy construct does remain, the justification must be explicit: a documented dependency, a named owner, defined compensating controls, and a review date. That converts an unmanaged default into a governed exception. In regulated environments, the difference between those two states is the difference between a defensible governance posture and an audit finding.
4. Where does write authority sit, and does the operating model reflect that?
   Every group in scope needs an explicit answer to this question. Groups intended for cloud-native governance should have SOA shifted accordingly. Groups that remain on-premises authoritative for justified reasons should be documented as such. Hybrid estates that mix write authority models without explicit design accumulate the fragmented governance posture this article is arguing against. The mixing itself is not the problem. The absence of design is.

Current gaps architects must plan around

A credible architecture recommendation requires acknowledging what the platform does not yet deliver. These are publicly documented gaps, not speculation. They should be factored into migration sequencing and communicated clearly to stakeholders before reviews and lifecycle programmes are scoped.

On soft delete and synced groups

The soft-delete asymmetry is worth understanding precisely. It is not that synced groups are excluded from a feature that could otherwise apply to them. It is that the on-premises AD object remains the source of truth, and deletion behaviour follows AD semantics, not Entra semantics. Shifting SOA is what makes Entra soft-delete available for a group. In environments where accidental group deletion has caused permission loss in the past, this is one of the most concrete technical arguments for the shift.

Why these gaps strengthen the migration case, not weaken it

These gaps do not undermine the case for cloud-native group design. Legacy-managed and Exchange-tied constructs share all of them and add their own. The comparative governance position of Entra security groups remains stronger across the access-control and cloud-governance dimensions that matter most for modern identity governance. The gaps need to be planned around and communicated honestly, not used as a reason to defer the design work.

Where to start if the ownership question was unclear

• Inventory the estate by type and governance status, not directory location. Most environments can produce a group count. Far fewer can show, for each construct type, what proportion can be subjected to enforced access reviews, have an active owner with appropriate tooling, and sit within a lifecycle policy. That breakdown is the starting point. Without it, governance investment goes to policies that apply inconsistently and reviews that complete without enforcement.
• Define a target architecture and record it. Decide which use cases belong on Entra security groups, which belong on Microsoft 365 Groups and which legacy patterns require explicit, time-bounded exception handling with documented compensating controls. Target architectures that exist only as informal understanding cannot be enforced, cannot be audited and do not survive staff changes.
• Validate governance controls against actual group type distribution. For each governance control in operation, confirm that it reaches the group types it is supposed to reach. Access review scope, Lifecycle Workflows applicability, entitlement management integration and delegated administration boundaries all depend on group type. Where a governance control cannot reach an object type, that is an architectural gap requiring a design response, not a configuration task.
• Reframe the SOA conversation internally. Group Source of Authority is routinely communicated as a migration capability or a synchronisation feature. Neither framing captures its governance significance. The organisations that reframe it as a governance pivot, and communicate it that way to the teams responsible for access management and compliance, make sequencing decisions that compound correctly over time.

Final thought

Most governance programmes in hybrid Entra environments have policies in place. Fewer have verified that those policies can actually be enforced against the objects they depend on. Group Source of Authority is the mechanism that determines which side of that gap a group sits on. Answering that question systematically, across the full estate, is not a migration programme. It is the foundational audit that most organisations have deferred until an access review produces a result they cannot explain.

Related Microsoft identity and security insights

• Entra Administrative Boundary Design: Administrative Units, PIM Scoping and a Five-Layer Segmentation Model
• Entra Tenant Governance and Multi-Tenant Drift Detection
• SaaS Identity Governance, Offboarding Failures and NIS2: Where the Gaps Actually Live
• Microsoft Learn: Embrace cloud-first posture and convert Group Source of Authority to the cloud
• Microsoft Learn: Create an access review of groups and applications in Microsoft Entra ID Governance