Een security group regelt toegang: je koppelt er applicaties, licenties, rechten en beleid aan. Een Microsoft 365 group regelt samenwerking: bij het aanmaken krijgt de groep automatisch een gedeelde mailbox, een SharePoint site, een Planner en optioneel een team in Microsoft Teams. De vuistregel is simpel: gaat het om wíé ergens bij mag, kies een security group. Gaat het om sámen werken in een gedeelde omgeving, kies een Microsoft 365 group.

In de praktijk gaat dit vaak mis omdat beide typen in hetzelfde scherm worden aangemaakt en op het eerste gezicht hetzelfde lijken. Het verkeerde type kiezen betekent later exporteren, opnieuw opbouwen en opnieuw koppelen, want converteren tussen de twee typen kan niet.

Quick facts

Twee groepstypen, twee werelden

Het verschil zit niet in de leden maar in wat er om de groep heen gebeurt. Een security group is een kaal toegangsobject: een lijst van identiteiten waar je rechten aan hangt. Precies daarom is het de standaardkeuze voor alles wat met roltoegang te maken heeft: app assignment via enterprise applications, group-based licensing, Conditional Access policies, Intune profielen en SharePoint rechten. Security groups kunnen bovendien gesynchroniseerd worden vanuit on-premises AD, al beheer je ze dan verplicht aan de on-premises kant.

Een Microsoft 365 group is een samenwerkingsobject. Op het moment van aanmaken provisiont Microsoft er automatisch een pakket resources bij: een groepsmailbox met agenda in Exchange Online, een SharePoint teamsite, een Planner bord en een OneNote notitieblok, plus optioneel een team in Teams. Dat pakket is niet configureerbaar: je kunt niet kiezen voor alleen de mailbox zonder de site. Elk team dat iemand in Teams aanmaakt, is onder water een Microsoft 365 group. Wie zich afvraagt waar al die groepen in de tenant vandaan komen: daar dus.

De beperkingen die je moet kennen

De belangrijkste beperking van Microsoft 365 groups: alleen gebruikers kunnen lid zijn. Geen devices, geen service principals en geen geneste groepen. Wil je een afdelingsgroep hergebruiken als lid van een team, dan kan dat alleen indirect, en de memberOf constructie die dit deels oplost zit al jaren in preview.

Security groups kennen hun eigen valkuil bij nesting: een geneste groep werkt prima voor bijvoorbeeld SharePoint rechten, maar bij licentietoewijzing en app assignment tellen alleen directe leden mee. En de mail-enabled security group, het hybride tussending, maak je alleen aan via het Exchange admin center en ondersteunt geen dynamisch lidmaatschap en geen devices. In de praktijk is dat type vooral een erfenis; kies liever een gewone security group plus een gedeelde mailbox of distributielijst waar nodig.

Wanneer kies je wat

Kies een security group voor alles wat structureel en beheersmatig is: roltoegang per functie, licentie-uitgifte, Conditional Access, device beleid en rechten op data. Kies een Microsoft 365 group voor alles wat organisch en samenwerkingsgericht is: een projectteam, een afdeling die een gezamenlijke werkruimte nodig heeft, een commissie met een eigen mailbox.

De twee sluiten elkaar niet uit. Een gezond model gebruikt security groups als fundament voor toegang en Microsoft 365 groups als werkruimtes daarbovenop. Wat je wilt voorkomen is het omgekeerde: Microsoft 365 groups die als toegangsgroep worden misbruikt omdat ze er toevallig al waren. Dan bepaalt een teameigenaar, zonder het te weten, wie toegang heeft tot bedrijfsdata.

Waarom je dit in Joinly wilt regelen

Het onderscheid tussen de twee typen is goed uit te leggen; het consequent volhouden is het echte probleem. Iedereen die een team aanmaakt, maakt een Microsoft 365 group aan. Beheerders maken onder tijdsdruk een groep aan zonder conventie. Na twee jaar heb je honderden groepen zonder eigenaar, zonder doel in de beschrijving en zonder zekerheid welke groepen toegang geven tot wat.

Joinly houdt het fundament op orde: de security groups die roltoegang dragen worden aangemaakt, gevuld en opgeruimd op basis van je HR gegevens, met naamconventie en audit trail. Lidmaatschappen volgen automatisch uit afdeling en functie, in Entra ID én in on-premises AD. De Microsoft 365 groups blijven het domein van samenwerking, maar de toegang tot applicaties, licenties en data ligt vast in een model dat zichzelf onderhoudt. Zo blijft het verschil tussen de twee typen geen kwestie van discipline maar van architectuur.

Weten hoeveel groepen in jouw tenant zonder eigenaar of doel rondzweven? Doe de gratis scan op scan.joinly.app.

Installation guide

Stap 1: Bepaal het type met drie vragen

1. Moeten devices, service principals of andere groepen lid kunnen zijn? Dan security group.

2. Is een gedeelde mailbox, site of team het doel? Dan Microsoft 365 group.

3. Twijfel? Kies de security group. Uitbreiden naar een samenwerkingsomgeving kan later altijd; resources weer loskoppelen van een Microsoft 365 group niet.

Stap 2: Maak een security group aan

1. Ga naar entra.microsoft.com en meld je aan als minimaal Groups Administrator.

2. Navigeer naar Entra ID → Groups → All groups → New group.

3. Kies Group type: Security.

4. Vul naam (volgens je conventie) en beschrijving met het doel in.

5. Kies Membership type: Assigned of Dynamic User/Dynamic Device.

6. Wijs een eigenaar toe en klik Create.

Stap 3: Maak een Microsoft 365 group aan

1. Zelfde pad: Entra ID → Groups → All groups → New group.

2. Kies Group type: Microsoft 365.

3. Vul naam en beschrijving in; het e-mailadres van de groep wordt hier bepaald.

4. Kies membership type, wijs eigenaren toe en klik Create.

5. De mailbox, SharePoint site en Planner worden automatisch geprovisiond; een team koppel je desgewenst achteraf in Teams via Aan de slag met een bestaande groep.

Stap 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")

Het verschil zit in GroupTypes @("Unified"): dat maakt er een Microsoft 365 group van.

Stap 5: Richt de vangrails in

1. Naming policy: Entra ID → Groups → All groups → Naming policy. Dwing een prefix af zodat het type en doel uit de naam blijkt.

2. Expiration policy voor Microsoft 365 groups: Entra ID → Groups → All groups → Expiration. Inactieve groepen verlopen automatisch; eigenaren krijgen vooraf een verlengverzoek.

3. Beperk wie Microsoft 365 groups mag aanmaken als de wildgroei nu al een feit is; leg aanmaak bij een beheerde groep gebruikers.

Zo doe je dit in Joinly

In Joinly leg je per rol vast welke security groups erbij horen; de groepen zelf worden volgens jouw naamconventie aangemaakt en gevuld vanuit het HR systeem. Een nieuwe afdeling in HR betekent automatisch de juiste toegangsgroepen in Entra en on-premises AD, met eigenaar en beschrijving vooraf ingevuld. Microsoft 365 groups laat Joinly bewust bij de business liggen; het toegangsfundament eronder is dan al geregeld.