A note on inspiration: This series grew out of field experience across dozens of M365 environments, but the governance framing was sharpened by an episode of the M365 FM podcast hosted by Mirko Peters — "The Governance Illusion: Why Your Tenant Is Beyond Control." The concepts here are original and practitioner-driven, but Mirko's framing of governance as an operating discipline rather than a deployment project is worth an hour of your time in its own right.
If you ask most M365 admins what controls access in their tenant, they'll point to Conditional Access policies. That's the right answer for the authentication layer. But CA policies tell you who can get through the door under what conditions. They don't tell you what the person can do once they're inside, and they don't tell you who else is already inside the room.
Groups answer those questions. Every permission boundary in M365 is ultimately grounded in group membership. SharePoint sites scope access through them. Teams workspaces are built on them. CA policy exclusions are managed through them. Guest identities persist inside them. Dynamic group rules silently re-scope them overnight.
And here's the thing that catches most organizations off guard: the M365 group object isn't just a membership list. It's a connected set of resources. When a group gets created, a stack of dependent workloads comes with it, each with its own permission model, its own lifecycle, and its own way of quietly accumulating exposure over time.
This is the mental model most governance conversations miss. When someone creates a Microsoft 365 group, they're not adding a row to a directory. They're creating a connected set of resources that spans the entire workload stack. Everything grounded in that group inherits its membership, its permissions, and its access state. Including its guests.
This is why the question "who owns this group?" is not a metadata question. It's an operational question with a direct line to your risk posture. Every enforcement action, every access review, every expiration decision requires a human to root it to. No owner means no one to attest. No one to attest means the system can only report the problem, never resolve it.
Ownership isn't a binary. It doesn't just exist or not exist. It degrades through predictable patterns that every organization with real adoption will eventually encounter. Naming them makes them preventable.
The dynamic vs. assigned debate is often framed as a preference. It isn't. The choice between them has direct implications for what breaks when the underlying data changes, and for what CA policies targeting that group actually enforce.
- Membership managed automatically by attribute rules
- Scales without manual intervention for large populations
- Correct when identity attributes are accurate and stable
- Right choice for department-wide or role-wide policies
- Requires audit of the rule itself, not just the members
- Rule drift happens when HR attributes change schema or convention
- Explicit control over who is in scope
- Required for exception-based or project-scoped groups
- Correct for CA policy exclusions (break-glass, service accounts)
- Scales poorly without lifecycle enforcement
- Stale members accumulate if access reviews don't run
- Guest members especially prone to indefinite persistence
Dynamic groups in CA exclusions aren't automatically wrong, but they need to be intentional and tightly controlled. There are legitimate use cases. A dynamic query scoped to Teams-certified devices is a common and reasonable way to handle device code flow exclusions without manually maintaining a membership list. The rule is specific, the scope is narrow, and the attribute driving it is controlled.
The risk is when exclusion groups use dynamic rules tied to attributes that users or attackers can influence. If someone can add the right attribute to an account, a department field, a job title, an extension attribute, they can dynamically qualify for an exclusion from an otherwise intentional control without anyone approving it. That's not a theoretical risk. It's a bypass vector that bypasses the entire point of the exclusion group model.
The rule of thumb: dynamic queries in CA exclusions are fine when the qualifying attribute is controlled by IT and not writable by the user or an attacker with partial access. Assigned groups are the safer default for anything where that condition isn't clearly met. And either way, exclusion groups need a quarterly review and documented justification for every member or rule in them.
Entra ID Governance access reviews get deployed in most organizations as a compliance checkbox. Run the review quarterly, export the results, close the ticket. That's not governance. It's a scheduled reporting event. The value of access reviews isn't the report they produce. It's the consequence that fires when the owner doesn't respond.
A review with no enforced outcome is a survey. A review where no response means removal is an access control. That's the difference, and most environments are running the first one while thinking they're running the second.
Review fatigue produces the same outcome as no review. When owners are assigned too many groups to review, when the review interface provides no context about what the group actually controls, when approving is one click and investigating is thirty minutes of work, reviewers approve. Every time. The organization converts uncertainty into permanent access, quarter after quarter, until nobody can distinguish a deliberate decision from something that just never got questioned.
Microsoft's recommendation to require a minimum of two owners per group is correct but routinely misunderstood. Two owners is a minimum threshold against the departing-owner failure mode. It is not a governance model. Two nominal owners who inherited the group when the original owner left, and who both approve everything in every review, don't provide meaningful oversight. They provide audit cover.
Ownership governance requires three things that "two owners" doesn't guarantee on its own:
| Requirement | What It Means | How It Fails Without Enforcement |
|---|---|---|
| Verified owners | Owners are active employees who actually know the group's purpose and can make informed access decisions | Inherited owners approve everything in reviews because they don't have context. Departed owners leave stale ownership records that block automated enforcement. |
| Enforced minimum | minimumOwners: 2 enforced with automated detection and escalation when ownership drops below threshold | Without enforcement, groups naturally drift to single owner or no owner as people leave. Nobody gets an alert until a review fails. |
| Documented purpose | Each group has a description that tells a reviewer what it's for, who should be in it, and what it controls access to | Reviewers can't make informed decisions about membership they don't understand. Everything gets approved by default. |
| Enforced reassignment | When an owner leaves, a defined process reassigns ownership before the account is disabled, not after the next review cycle | Offboarding processes handle user accounts. They almost never handle group ownership dependencies. The gap is where ownerless groups come from. |
Groups are where identity governance stops being an identity problem and starts being a data governance problem. The CA policies from your last project define the conditions for access. The groups underneath them define the scope. And the ownership model for those groups determines whether any of it stays aligned with intent once the project is over.
The pattern that kills M365 governance isn't a bad configuration decision. It's the gap between where policies are written and where work actually happens. Settings live in admin centers. People create Teams from Planner, share files from OneDrive, add guests because the project needs it today. Groups accumulate without owners. Dynamic rules drift without audits. Guests persist without sponsors. The tenant keeps running, generating no errors, no alarms, quietly becoming a record of every access decision that was ever made minus the ones someone chose to clean up.
In the next post, we examine why this happens even in tenants that think they've done governance right: the difference between configuration and control, and what it looks like when the place where work happens grows faster than the place where settings are managed.
Want More?
Follow along for more writing on M365 security, identity, and the real-world thinking behind modern cyber defense.
Read More on Medium