When should you control access through a Microsoft 365 group, and when through an Entra ID security group – and why this works differently in Microsoft Teams than in SharePoint.
In TeamswareOne – built on Microsoft 365 – collaboration and document access run through different group types. Confusing the two produces a permission model that drifts apart in daily use. This article explains which group type serves which purpose, which pitfall hits most often in Teams, and how Teamsware structures permissions in SharePoint.
🎯 At a Glance
The Microsoft 365 group controls team membership. Entra security groups control roles and access, especially in SharePoint.
A security group added to a team is expanded only once – later changes do not flow into the team automatically.
At Teamsware: always place AD groups inside SharePoint groups – and set the group's permission level deliberately.
💡 The basic idea: three questions, three group types
Microsoft 365 group → "Who belongs to the team?"
Entra security group → "Who holds which role or which access?"
SharePoint group → "Which permission applies on this site or library?"
A Microsoft 365 group is not a pure permission group but the shared membership object of several services: Teams team, SharePoint team site, Planner, group mailbox, calendar and, depending on configuration, Loop, Forms or Viva.
Anyone added to the group typically gains access to all connected services – including the team and the team site. Every team is based on exactly one Microsoft 365 group; its owners and members determine team membership.
Technical background
For group-connected team sites, Microsoft recommends managing permissions through the associated Microsoft 365 group or through Teams. Additional permissions set directly in SharePoint are possible but quickly cause the permission logic to drift apart. Microsoft Learn: Sharing and permissions
Entra security groups are central access control groups without connected services of their own. Microsoft describes them as groups of user accounts that can be used, for example, to give the same users access to SharePoint Online or other resources. Typical use cases:
Microsoft Learn: Create and manage security groups
This is the most important difference between SharePoint and Teams permissions: when you add a security group to a team, it is not maintained as a nested group. Teams expands it once into the members it held at that moment and adds them as individual users. Whatever happens in the security group afterwards – manually or through a dynamic rule – never reaches the team.
Example
If you need a team with automatic membership, a dynamic Microsoft 365 group is the clean route – not a security group.
Dynamic groups in Entra ID add and remove users automatically based on attributes – for example department, location, job title, company or employee type. Microsoft supports dynamic membership for both security groups and Microsoft 365 groups. The difference: Microsoft 365 groups can contain users only, security groups users or devices.
Check before you start
Dynamic groups require a Microsoft Entra ID P1 or an Intune for Education licence – for each user who is a member of a dynamic group. Microsoft Learn: Dynamic membership
Microsoft 365 groups do not support nesting like classic AD groups: you can neither nest several Microsoft 365 groups inside one another nor bind several of them to one team. A team has exactly one Microsoft 365 group. For centralised permission models, Entra security groups are therefore the better fit.
⚠️ But take care with deep nesting
Entra security groups can be nested – but the Microsoft 365 workloads do not evaluate nested groups consistently. Assign permissions directly to the group that is meant to receive access, rather than relying on multi-level nesting.
A SharePoint group cannot contain another SharePoint group – Entra security groups and Microsoft 365 groups, however, can be added without issue. That is exactly what the Teamsware permission model uses. Microsoft Q&A: Group nesting
At Teamsware we never grant permissions to individual users or AD groups directly on sites, libraries or folders. Instead, we consistently work with SharePoint groups and place the Entra/AD groups inside them – so access is controlled in one single place.
The decisive factor is the permission level of the SharePoint group: it determines what all AD groups inside it are actually allowed to do. Which levels SharePoint provides, and how the Teamsware configuration turns them into five clear levels (Read, Write, Delete, Design, Admin), is covered in the separate article "SharePoint permission levels – standard and Teamsware configuration".
| Criterion | Microsoft 365 group | Entra security group | SharePoint group |
|---|---|---|---|
| Main purpose | Team and collaboration membership | Central role and access control | Permissions on a site or library |
| Controls Teams membership | Yes, natively | No – one-time expansion only | No |
| SharePoint access | Yes (Owners/Members) | Yes – very granular | Yes (Owners/Members/Visitors) |
| Dynamic membership | Yes – users only | Yes – users or devices | No |
| Nesting | No | Yes – but inconsistent across M365 workloads | No SharePoint groups within each other; Entra/M365 groups possible |
| Connected services | Teams, SharePoint, Planner, mailbox, calendar … | None – pure access group | SharePoint only |
🎯 Teamsware recommendation
For collaboration in Teams, use the Microsoft 365 group or team membership directly – for project teams, construction file teams, department teams as well as chat, channels, files and Planner.
Example from practice: the Microsoft 365 group of the construction file team controls the core members. The Entra security group Project Management is additionally added to the SharePoint group with the Read level and thus receives read access to the document library – without being a member of the team.
💡 Quick reminder
Teams membership = collaboration
SharePoint permissions = information and document access
Entra security groups = central role and access control
At Teamsware: AD group inside the SharePoint group – the group's permission level controls the right
Teamsware GmbH · Leopoldstraße 31 · 80802 München · www.teamsware.eu