SharePoint Groups vs Microsoft 365 Groups vs Entra ID Security Groups

A SharePoint role assignment can point at three fundamentally different kinds of group, and each one answers "who is in it, who manages it, and where does its history live" differently. Confusing them is how permission reviews go wrong: a reviewer counts the members of a SharePoint group, finds two, and misses the Entra ID security group inside it that carries forty contractors.

The three group types at a glance

SharePoint groups

SharePoint groups are the oldest mechanism and still the one SharePoint evaluates first. Every site collection gets three by default, Owners, Members and Visitors, bound to Full Control, Edit and Read on the root web respectively. Site owners can create more.

Key properties:

• Site-scoped. A SharePoint group exists only inside its site collection. "Finance Visitors" on the Finance site and "Finance Visitors" on the HR site are unrelated objects with different integer ids.
• No nesting. A SharePoint group cannot contain another SharePoint group. It can contain Entra ID security groups and Microsoft 365 groups, which is where nesting sneaks in.
• Membership is a SharePoint operation. Adding or removing a member is a SharePoint event (AddedToGroup, RemovedFromGroup) attributed to the site owner or administrator who did it, and it appears in the Unified Audit Log under the SharePoint workload.
• Visible in the site. Site settings, People and groups, lists them with their members, but only the direct members. An Entra ID group inside shows as one row.

List a SharePoint group's direct members with PnP PowerShell:

Get-PnPGroupMember -Group "Finance Visitors" | Select-Object Title, LoginName, PrincipalType

PrincipalType 1 is a user; 4 is a directory group you need to expand separately.

Microsoft 365 groups

A Microsoft 365 group is an Entra ID object with attached services: a group mailbox, a SharePoint team site, optionally a Teams team and a Planner plan. When you create a team site or a team, SharePoint automatically adds the group's owners to the site's Owners SharePoint group and its members to the Members SharePoint group, using the group's two Entra ID roles (Owners and Members) as claims.

Key properties:

• Tenant-wide object, but one site. The group id is a GUID in Entra ID; the connected site is one site collection. A Microsoft 365 group can also be granted on other sites just like any directory group, which is the case that surprises people.
• No nesting. A Microsoft 365 group cannot contain groups. Its membership is flat, which makes it easy to expand but also means large groups get large.
• Owner-managed. Group owners add members from Outlook, Teams or Microsoft 365 Groups in Entra ID without touching SharePoint. The change is an Entra ID audit event (Add member to group) and, for Teams-connected groups, a Teams event too. It does not appear as a SharePoint operation.
• Guest membership follows the group. If guest access is enabled for the group, guests added to it get the connected site's Members permissions automatically.

In a SharePoint role assignment the login name looks like c:0o.c|federateddirectoryclaimprovider|<group id> for the members role, with _o appended for the owners role. Expand it with Graph:

GET https://graph.microsoft.com/v1.0/groups/{id}/members?$select=id,displayName,userPrincipalName,userType

Entra ID security groups

Security groups are the general-purpose directory group. They have no attached services, can be assigned to applications, roles, licenses and SharePoint sites, and, critically, can contain other security groups.

Key properties:

• Nesting is allowed and SharePoint honors it. If group A contains group B and group B contains Alex, and group A is a member of a SharePoint group with Read, Alex has Read. SharePoint does not show group B anywhere; you have to expand it in Entra ID.
• Dynamic membership. A security group can have a rule such as user.department -eq "Finance". Membership then changes whenever user attributes change, with no human actor on the membership event; the audit log attributes it to the directory service.
• Mail-enabled security groups are supported by SharePoint; plain distribution groups are not security principals and cannot be granted permissions.
• Management is wherever the group is managed. Entra ID admins, group owners, an HR-driven provisioning system, or a dynamic rule. Changes are Entra ID audit events, again never SharePoint operations.

Flatten a security group, including nesting, with transitiveMembers:

Get-MgGroupTransitiveMember -GroupId $groupId -All |
  ForEach-Object { $_.AdditionalProperties } |
  Where-Object { $_.'@odata.type' -eq '#microsoft.graph.user' } |
  Select-Object displayName, userPrincipalName, userType

To see the structure rather than the flattened result, list direct members and recurse into anything whose @odata.type is #microsoft.graph.group.

Why the distinction matters for reviews and audits

Different owners. A SharePoint group is controlled by site owners. A Microsoft 365 group is controlled by its group owners, who may know nothing about the sites it has been granted on. A security group is controlled by whoever manages the directory. A permission review that only asks the site owner covers one of three.

Different audit trails. SharePoint group changes are SharePoint events. Directory group changes are Entra ID events. A review of "who changed access to this site" that only looks at SharePoint operations misses every membership change in directory groups, which in most tenants is where the majority of changes happen.

Different retention. Entra ID's own audit log retains 30 days (with the right licensing; 7 days on Free). The Unified Audit Log retains 180 days on Audit (Standard) and one year on Audit (Premium). If you need more than that for group membership history, you need to be capturing it yourself.

Nesting hides scale. A SharePoint group with "two members" can be one user and one security group containing three nested groups and four hundred people. Reviewing counts is meaningless; reviewing transitive membership is the only honest number.

A practical review checklist

1. On the inheritance boundary, list every role assignment with $expand=Member,RoleDefinitionBindings.
2. Classify each principal by claim prefix: user, SharePoint group, Microsoft 365 group, security group, claim, sharing link.
3. For SharePoint groups, list direct members and classify those too.
4. For Microsoft 365 groups, list members (flat).
5. For security groups, list transitiveMembers and, if you need the route, walk members recursively.
6. Record userType for every user; Guest is the external population.
7. Repeat for every unique-permission object below the site, because each one is its own boundary.

FAQ

Can I nest a Microsoft 365 group inside a security group?

You can add a Microsoft 365 group as a member of a security group in Entra ID, but nested membership through a Microsoft 365 group is not evaluated the same way across workloads, and Microsoft 365 groups cannot themselves contain groups. Avoid relying on it for SharePoint access.

Why do group membership changes take time to affect SharePoint?

SharePoint Online evaluates directory group membership from cached claims rather than querying Entra ID on every request. Changes propagate, but not instantly, so removing someone from a group is not an immediate revocation.

Are distribution lists usable for SharePoint permissions?

No. Only mail-enabled security groups and security groups are security principals. A classic distribution group cannot be added to a role assignment.

Related reading

• How to Find Out Why a User Has Access to a SharePoint Site
• How to Review External User and Guest Access in SharePoint Online
• How to Investigate Who Changed SharePoint Permissions