A security group manages access: you link applications, licences, rights and policies to it. A Microsoft 365 group manages collaboration: upon creation, the group automatically receives a shared mailbox, a SharePoint site, a Planner and optionally a team in Microsoft Teams. The rule of thumb is simple: if it is about who has access to something, choose a security group. If it is about working together in a shared environment, choose a Microsoft 365 group.

In practice, this often goes wrong because both types are created in the same screen and look identical at first glance. Choosing the wrong type means exporting, rebuilding and linking again later, as converting between the two types is not possible.

Quick facts

Two group types, two worlds

The difference is not in the members but in what happens around the group. A security group is a bare access object: a list of identities to which you attach rights. This is precisely why it is the default choice for everything related to role access: app assignment via enterprise applications, group-based licensing, Conditional Access policies, Intune profiles and SharePoint permissions. Security groups can also be synchronised from on-premises AD, although you must then manage them on the on-premises side.

A Microsoft 365 group is a collaboration object. At the moment of creation, Microsoft automatically provisions a package of resources with it: a group mailbox with calendar in Exchange Online, a SharePoint team site, a Planner board and a OneNote notebook, plus optionally a team in Teams. That package is not configurable: you cannot choose to have the mailbox without the site. Every team that someone creates in Teams is a Microsoft 365 group under the hood. For those wondering where all those groups in the tenant come from: that is where.

The limitations you need to know

The main limitation of Microsoft 365 groups: only users can be members. No devices, no service principals and no nested groups. If you want to reuse a department group as a member of a team, you can only do so indirectly, and the memberOf construct that partially solves this has been in preview for years.

Security groups have their own pitfall with nesting: a nested group works fine for SharePoint permissions, for example, but for licence allocation and app assignment only direct members count. And the mail-enabled security group, the hybrid in-between, can only be created via the Exchange admin center and does not support dynamic membership or devices. In practice, that type is mainly a legacy; it is better to choose a regular security group plus a shared mailbox or distribution list where needed.

When to choose what

Choose a security group for everything structural and administrative: role access per function, licence issuance, Conditional Access, device policies and data permissions. Choose a Microsoft 365 group for everything organic and collaborative: a project team, a department that needs a shared workspace, a committee with its own mailbox.

The two are not mutually exclusive. A healthy model uses security groups as the foundation for access and Microsoft 365 groups as workspaces on top. What you want to avoid is the reverse: Microsoft 365 groups being misused as access groups because they happened to be there already. Then a team owner, without knowing it, determines who has access to company data.

Why you want to manage this in Joinly

The distinction between the two types is easy to explain; maintaining it consistently is the real problem. Everyone who creates a team creates a Microsoft 365 group. Admins under time pressure create groups without naming conventions. After two years, you have hundreds of groups without owners, without a description of their purpose, and without certainty of what those groups grant access to.

Joinly keeps the foundation in order: the security groups carrying role access are created, populated and cleaned up based on your HR data, with naming conventions and audit trails. Memberships automatically follow department and job roles, both in Entra ID and in on-premises AD. The Microsoft 365 groups remain the domain of collaboration, but access to applications, licences and data is locked down in a self-maintaining model. This ensures the difference between the two types is not a matter of discipline but of architecture.

Want to know how many groups in your tenant are floating around without an owner or purpose? Run the free scan at scan.joinly.app.

Installation guide

Step 1: Determine the type with three questions

1. Do devices, service principals or other groups need to be members? Then choose security group.

2. Is a shared mailbox, site or team the goal? Then choose Microsoft 365 group.

3. In doubt? Choose the security group. Expanding to a collaborative environment is always possible later; decoupling resources from a Microsoft 365 group is not.

Step 2: Create a security group

1. Go to entra.microsoft.com and sign in as at least a Groups Administrator.

2. Navigate to Entra ID → Groups → All groups → New group.

3. Choose Group type: Security.

4. Enter a name (according to your convention) and a description stating the purpose.

5. Choose Membership type: Assigned or Dynamic User/Dynamic Device.

6. Assign an owner and click Create.

Step 3: Create a Microsoft 365 group

1. Same path: Entra ID → Groups → All groups → New group.

2. Choose Group type: Microsoft 365.

3. Enter name and description; this defines the group's email address.

4. Choose membership type, assign owners and click Create.

5. The mailbox, SharePoint site and Planner are automatically provisioned; you can link a team afterwards in Teams via Get started with an existing group if desired.

Step 4: Via PowerShell/Graph

powershell

Connect-MgGraph -Scopes "Group.ReadWrite.All"

# Security group
New-MgGroup -DisplayName "APP-Exact-Gebruiker" `
  -MailEnabled:$false -MailNickname "app-exact-gebruiker" `
  -SecurityEnabled:$true

# Microsoft 365 group
New-MgGroup -DisplayName "Project Phoenix" `
  -MailEnabled:$true -MailNickname "project-phoenix" `
  -SecurityEnabled:$false -GroupTypes @("Unified")

Connect-MgGraph -Scopes "Group.ReadWrite.All"

# Security group
New-MgGroup -DisplayName "APP-Exact-Gebruiker" `
  -MailEnabled:$false -MailNickname "app-exact-gebruiker" `
  -SecurityEnabled:$true

# Microsoft 365 group
New-MgGroup -DisplayName "Project Phoenix" `
  -MailEnabled:$true -MailNickname "project-phoenix" `
  -SecurityEnabled:$false -GroupTypes @("Unified")

The difference lies in GroupTypes @("Unified"): that turns it into a Microsoft 365 group.

Step 5: Set up the guardrails

1. Naming policy: Entra ID → Groups → All groups → Naming policy. Enforce a prefix so that the type and purpose are clear from the name.

2. Expiration policy for Microsoft 365 groups: Entra ID → Groups → All groups → Expiration. Inactive groups automatically expire; owners receive a renewal request beforehand.

3. Limit who can create Microsoft 365 groups if sprawl is already an issue; assign creation rights to a managed group of users.

How you do this in Joinly

In Joinly, you define per role which security groups belong to it; the groups themselves are created and populated from the HR system according to your naming conventions. A new department in HR automatically results in the correct access groups in Entra and on-premises AD, with owner and description pre-filled. Joinly deliberately leaves Microsoft 365 groups to the business, as the underlying access foundation is already secured.