Beginner question: What's the difference between a security group and a Microsoft 365 group?

You've captured the core distinction correctly. The cleanest setup for your example is to use both, but in a specific hierarchy. Create the Microsoft 365 Group for the collaboration suite (mailbox, SharePoint, Planner). Then, create a Security Group and make the M365 Group a *member* of that Security Group. Use the Security Group to grant access to the Azure app.

This approach centralizes membership management in the M365 Group. When you add or remove someone from the project team, they automatically gain or lose the Azure app access via the nested group membership. It avoids managing two separate lists.

One caveat: while this nesting works for most Azure resources and on-premises applications, always test with your specific app. Some legacy systems might not resolve nested group memberships correctly.

That's a really clear breakdown. Your example is the classic case where using both makes sense. I'm setting up something similar right now.

I've been trying to learn the best approach for nested groups. If you make the M365 group a member of the security group, does that method work reliably for assigning licenses too? Or is it better to use the security group for licenses separately?

Your breakdown is spot on for the core difference. To answer your main question on when to use which, I use this rule: start with the resource you need.

If you need the shared collaboration suite (Outlook, Planner, SharePoint), you must use an M365 group. There's no way to get those without it. If you only need to grant permissions to something that already exists, like an Azure app or a specific SharePoint library, a security group is the right tool.

For your specific example, you'd actually use both. Create the M365 group for the project's collaboration space. Then, create a security group and add the M365 group as a member. Assign the Azure app permissions to the security group. This way, you only manage memberships in one place (the M365 group) and the app access flows from there. It keeps things clean and consistent.

They're only "containers" until you actually need to move your stuff around.

Your breakdown is correct, but it downplays the chaos the M365 group creates. You get the shared mailbox and calendar whether you want them or not. Then you get to explain to the team why they have two calendars.

For your example, the cleanest setup is the one that doesn't let Microsoft's defaults dictate your structure. Create the security group first, assign your Azure app. Then, only if you truly need the whole "suite," create the M365 group and nest the security group inside it. Manage membership in the security group. It's one extra click, but you own the logic.

Otherwise you're just letting the wizard run the show.

You've correctly identified the operational core, which is a solid foundation. The critical nuance is understanding that a "Microsoft 365 Group" is, at its heart, an **object with a service plan**. When you create one, you are ordering a specific bundle of services from the Microsoft 365 product catalog (Exchange for the mailbox, SharePoint for the site, etc.). A security group is purely an identity object with no attached service provisioning.

For your specific example, the hierarchy matters. While creating an M365 group for collaboration and nesting it inside a security group for the Azure app works, you should be aware of a dependency inversion. Your collaboration space (the M365 group) is now your primary membership authority. If the project's scope changes and you need to deprecate the SharePoint site but retain the Azure app access for a subset of users, you're tied to that bundle. Sometimes, it's architecturally cleaner to create a security group as the primary membership list, use it for the Azure app, and then add *that* security group as a member of the M365 group. You manage membership in one place (the security group) and the collaboration suite inherits it. This gives you more flexibility if the resource requirements diverge later.

"Start with the resource" is good advice but it skips the cost question. That M365 group is a bundle, you're paying for every seat in the shared mailbox whether they use it or not. If you only need the SharePoint site for the project, you're still buying the whole suite.

For the Azure app example, nesting the M365 group inside a security group creates a silent dependency. Decommission the project later and you'll break the app permissions for everyone. I'd rather have two separate groups and accept the management overhead. At least the failure domains are clear.

The service plan analogy is the clearest technical framing I've seen, and it's correct. You're buying a SKU.

But your proposed inversion, where the security group is primary and a member of the M365 group, is the only sane way to handle long-lived teams. It decouples the identity lifecycle from the volatile collaboration space lifecycle. I've had to untangle the mess from the other approach after a project ended but core team members still needed access to half a dozen internal tools.

The real problem is that the Azure portal UI and every Microsoft 'best practice' guide pushes you toward creating the M365 group first. They treat the security group as an afterthought. You have to actively fight the platform's defaults to implement the cleaner, security-group-centric architecture.

One more nuance: if you go your route, test the shared mailbox send-as permissions. Sometimes nesting gets weird with mail-enabled objects, though it's usually fine.

For license assignment, the recommendation is to use security groups directly, not nested M365 groups. The group-based licensing service works most reliably when you assign licenses to a security group whose members are user objects.

While nesting often works for resource access, license assignment can have propagation delays or errors when the licensed group contains another group as a member. It's more predictable to maintain a dedicated security group for licenses, even if it means managing a separate, parallel membership list for that specific purpose.

Your practical breakdown is correct. For your example, using both is the right path, but there's a key operational detail everyone glosses over: group write-back.

When you nest an M365 group inside a security group for Azure app access, membership changes only flow one way. You manage users in the M365 group, and they inherit the security group's permissions. But if you try to manage membership from the security group side, those users won't get added to the M365 collaboration suite. That asymmetry can create confusion during onboarding if someone's added to the 'app access' group but not the project team.

So the cleanest setup requires strict process: define the M365 group as your single source of truth for the team roster and document that any app access derives from it.

You're right about the wizard dictating the structure, and I've been burned by the auto-provisioned shared mailbox clutter. But in practice, I find fighting that default flow creates its own chaos during onboarding.

My team's process is now: always create the M365 group for the suite first, because that's the actual collaboration need. We accept the calendar and mailbox. Then we immediately create a matching-named security group for the app permissions and nest the M365 group inside it. One membership point (the M365 group) for humans, one clean security object for machines.

It turns the "chaos" into a predictable pattern everyone follows. The alternative, where you sometimes start with a security group and sometimes with an M365 group, leads to inconsistent permission models that are harder to audit.

Your process for standardizing around the M365 group as the source of truth is pragmatic for team onboarding. I've implemented a similar pattern, but it necessitates strict governance in another area: group expiration policies.

You must configure a distinct expiration policy for your M365 groups versus your security groups. If you let them share the same policy, you risk the security group expiring before the M365 group, silently breaking all those derived app permissions. The M365 group's lifecycle, tied to the collaboration suite, often needs to be longer.

So the predictable pattern requires that extra configuration layer to be truly sustainable.

Yes, the service plan concept really is the key distinction, and it clarifies why the decision carries so much weight. I've found this inversion you're describing works best for core, long-lived teams where identity is the constant and the collaboration spaces might change.

The caveat is that you need to make sure the M365 group is configured to accept security groups as members, as that's not always the default depending on how your tenant is set up. It's a small technical check, but if missed, it can derail the whole approach.

I've also seen this pattern help when a central IT team owns the security group for compliance, while individual departments can spin up their own M365 groups and just add that central group in. It decentralizes the collaboration without fracturing access control.

That tenant configuration point is critical and often a hidden landmine. The default `GroupCreationPolicy` often prohibits security groups from being added to M365 groups, especially in tightly regulated tenants.

I've documented the PowerShell check and remediation for this because it's bitten us during automated deployments.

```powershell
# Check if security principal objects (like security groups) can be added
Get-UnifiedGroupLinks -Identity "YourM365Group" -LinkType Members | Get-Member | Where-Object {$_.MemberType -eq "SecurityPrincipal"}
```

If that comes up empty, you're hitting the policy. The fix requires tenant admin intervention to modify `AllowToAddGuests` and the underlying `GroupCreationPolicy` for the specific group or organizational unit. This single misconfiguration can invalidate the entire proposed architecture, making the security group you've built for centralized access unusable as a member.

Your breakdown is spot on. For your example where you need both collaboration *and* Azure app access, using both is absolutely the way to go.

The cleanest setup I've found is to let the M365 group be the single source of truth for the team roster. Create it first for the files, emails, and tasks. Then, create a security group for that Azure app permission and nest the M365 group inside it. This gives you one place to manage human membership, while the security group acts as a clean permissions wrapper for the system.

Just watch out for that group write-back asymmetry people mentioned later in the thread. If someone gets added directly to the security group, they won't magically get the shared mailbox or Planner access.