Microsoft breidt gevoeligheidslabels (sensitivity labels) in preview uit naar Microsoft Entra-cloudbeveiligingsgroepen. Daardoor kunnen organisaties dezelfde classificatie en governance die zij al voor Microsoft 365-groepen gebruiken, ook toepassen op een beveiligingsgroep die bijvoorbeeld toegang tot een applicatie, een Conditional Access-bereik of een resource regelt. Microsoft noemt voor MC1508238 een gefaseerde start vanaf medio november 2026.
Deze preview is geen automatische herclassificatie van bestaande groepen en ook geen algemene voorziening voor ieder groepstype. De functionaliteit is uitsluitend bedoeld voor cloudbeveiligingsgroepen met toegewezen lidmaatschap. Gesynchroniseerde beveiligingsgroepen uit on-premises Active Directory, door Exchange beheerde beveiligingsgroepen, e-mailbeveiligingsgroepen, distributielijsten en groepen met dynamisch lidmaatschap vallen er niet onder. Behandel de uitrol daarom als een gerichte governancewijziging voor autorisatiegroepen, niet als een vervanging van het bestaande labelbeleid voor Teams, SharePoint of documenten.
Wat een label op een beveiligingsgroep wel en niet doet
Een Microsoft Entra-beveiligingsgroep is een beveiligingsobject (security principal): Microsoft Entra ID en aangesloten systemen gebruiken de groepslidmaatschappen bij toegangsbesluiten. Bij een gelabelde cloudbeveiligingsgroep kan een gevoeligheidslabel groeps- en site-instellingen toepassen, waaronder regels rond externe gasten. Het label is daarmee een extra beleidslaag om de samenstelling van een groep in lijn te houden met de beoogde gevoeligheid van de toegang die zij verleent.
Een label op de groep labelt niet automatisch de bestanden, mailboxinhoud of applicatiegegevens waartoe de leden toegang hebben. Het vervangt evenmin Conditional Access, rollen met minimale rechten, toegangsbeoordelingen of eigenaarschap. Zie het als een aanvullende controle op het groepsobject en de lidmaatschappen. De bestaande toegangsarchitectuur, levenscyclus en controles op de gekoppelde resources blijven dus nodig.
De reikwijdte van de preview is bewust beperkt
Microsoft maakt onderscheid tussen Microsoft 365-groepen en cloudbeveiligingsgroepen. Wie labels al voor Microsoft 365-groepen heeft geactiveerd, heeft de preview daarmee niet automatisch ook voor beveiligingsgroepen aangezet. Voor cloudbeveiligingsgroepen gebruikt Microsoft de afzonderlijke instellingensjabloon in Entra Group.Security; Microsoft 365-groepen gebruiken Group.Unified.
Ook de beheerinterface is anders dan sommige beheerders verwachten. Het toewijzen van een label aan een beveiligingsgroep wordt volgens Microsoft niet ondersteund in het Microsoft 365-beheercentrum of in My Groups. Gebruik hiervoor het Microsoft Entra-beheercentrum, de Azure-portal, PowerShell of Microsoft Graph. Zorg dat het gekozen proces aansluit op het bestaande wijzigings- en autorisatiemodel; een ad-hocwijziging van een groep kan directe gevolgen hebben voor de toegang tot applicaties of resources.
Voorwaarden vooraf controleren
- Controleer de licentievoorwaarde. Microsoft verlangt ten minste één actieve Microsoft Entra ID P1- of P2-licentie in de tenant; Microsoft 365 E3 of E5 voldoet eveneens aan die voorwaarde.
- Maak de juiste tenantinstelling expliciet. In de instellingen van
Group.SecuritymoetEnableMIPLabelsopTruestaan. Houd rekening met bestaande waarden, zoalsAllowToAddGuests; overschrijf geen waarden zonder eerst de actuele instelling vast te leggen. - Bereid passende containerlabels voor. De gevoeligheidslabels moeten in Microsoft Purview zijn gepubliceerd met het bereik Groups & Sites. Een label voor uitsluitend bestanden en e-mail verschijnt niet als keuze voor deze groepen.
- Synchroniseer labels naar Microsoft Entra ID. Microsoft noemt hiervoor
Execute-AzureADLabelSyncin Security & Compliance PowerShell. De cmdlet zit niet in de Microsoft Graph PowerShell SDK. Na synchronisatie kan het maximaal 24 uur duren voordat een label beschikbaar is. - Bepaal wie mag toewijzen. De persoon die een label toepast, moet voldoende groepsbevoegdheden hebben, bijvoorbeeld eigenaar of minimaal Groups Administrator, én binnen het bereik van het publicatiebeleid voor het label vallen.
Voer deze controles eerst uit in een afgebakende testtenant of met een niet-kritieke testgroep. De instelling is tenantbreed, terwijl de concrete gevolgen pas zichtbaar worden wanneer een label aan een groep wordt toegekend. Dat vraagt om een duidelijk onderscheid tussen het technisch beschikbaar maken van de functie en het feitelijk labelen van groepen die productietoegang sturen.
Een label is tijdens de preview niet terug te draaien
De belangrijkste operationele beperking is dat een label op een cloudbeveiligingsgroep in deze preview onveranderlijk is. Nadat een label is toegepast, kan het niet worden gewijzigd of verwijderd. Microsoft adviseert bij een verkeerde keuze een nieuwe beveiligingsgroep met het juiste label te maken en de leden daarna opnieuw toe te voegen. Dat is ingrijpender dan bij Microsoft 365-groepen en verdient een formele keuze vooraf.
Pas daarom niet blind een hoog label toe op een bestaande autorisatiegroep. Leg voor elke kandidaatgroep vast welke systemen de groep gebruiken, welke eigenaar de toegang goedkeurt, welke gasten of geneste groepen aanwezig zijn en welke labelinstellingen daarbij passen. Een migratie naar een nieuwe groep kan namelijk ook wijzigingen vragen in applicatieconfiguraties, Conditional Access-beleid, Azure RBAC-toewijzingen of resource-ACL’s die naar de groeps-id verwijzen.
Gasten en geneste groepen eerst inventariseren
Bij de eerste toewijzing valideert Microsoft de bestaande groepssamenstelling tegen het labelbeleid. Een groep met gastleden kan niet worden gelabeld met een label dat gasttoegang verbiedt; de opslagbewerking mislukt totdat de conflictende gastleden zijn verwijderd. Na labeling kan een gast ook niet worden toegevoegd als het label gasttoegang blokkeert.
Voor geneste beveiligingsgroepen gelden eveneens regels. Om een groep met onderliggende groepen te labelen, moeten die onderliggende groepen eerst worden verwijderd. Daarna kan het label worden toegepast en kunnen de onderliggende groepen weer worden toegevoegd. Een geneste groep moet dan minimaal even restrictief zijn gelabeld als de bovenliggende groep. Een ongelabelde of minder restrictief gelabelde onderliggende groep kan niet worden toegevoegd aan een strenger gelabelde bovenliggende groep.
Beleidwijzigingen in Purview maken bestaande leden niet automatisch compliant. Als een label later wordt gewijzigd van gasten toestaan naar gasten blokkeren, blijft een bestaande gast volgens Microsoft lid totdat een eigenaar of beheerder die persoon verwijdert. Nieuwe groepscontroles en nieuwe gasttoevoegingen volgen dan wel het nieuwe beleid. Plan daarom een gerichte review van de feitelijke lidmaatschappen naast het publiceren of wijzigen van een label.
Extra voorzichtigheid bij groepen met hoge privileges
Microsoft waarschuwt dat bepaalde ingebouwde beheerdersrollen en apps met specifieke machtigingen tijdens de preview labelhandhaving kunnen omzeilen. Dat gedrag kan vóór algemene beschikbaarheid veranderen. Gebruik deze preview daarom niet als enige borging voor groepen die zeer brede of gevoelige rechten verlenen, zoals noodtoegangs-, directorybeheer- of productietoegangsgroepen.
Voor dergelijke groepen blijven minimale rechten, afzonderlijke beheerdersaccounts, sterke authenticatie, PIM waar passend, onafhankelijke toegangsbeoordelingen en controle van auditlogs noodzakelijk. Kies bij voorkeur eerst groepen met duidelijke eigenaren, overzichtelijke ledenlijsten en beperkte afhankelijkheden. Een label kan daar helpen om een geschikt governancepatroon te testen zonder kritieke toegangsmechanismen onnodig te verstoren.
Praktische invoerroute voor beheerders
- Maak een groepinventaris. Splits cloudbeveiligingsgroepen met toegewezen lidmaatschap uit van dynamische, gesynchroniseerde, mail-enabled en Exchange-beheerde groepen. Neem ook de gekoppelde applicaties, resources en eigenaren op.
- Definieer enkele doelgroepen. Vertaal het huidige toegangsmodel naar een beperkt aantal labels met een heldere bedoeling, bijvoorbeeld intern, beperkt of zonder gasten. Vermijd labels die alleen qua naam verschillen maar inhoudelijk hetzelfde beleid voeren.
- Controleer lidmaatschapsconflicten. Breng gasten, indirecte leden en geneste groepen per kandidaat in kaart. Los een conflict vooraf op; vertrouw niet op een automatische opschoning tijdens het toekennen.
- Schakel de voorwaarde gecontroleerd in. Controleer bestaande
Group.Security-waarden, zetEnableMIPLabelsaan, synchroniseer de labels en wacht totdat ze beschikbaar zijn. Documenteer wie deze tenantwijziging heeft goedgekeurd. - Voer een pilot uit. Kies een niet-kritieke cloudgroep, wijs het label toe via Microsoft Entra en verifieer lidmaatschapswijzigingen, relevante toegang en beheerprocessen. Bedenk vooraf wat het herstelpad is als de verkeerde labelkeuze wordt gemaakt.
- Breid alleen na evaluatie uit. Leg voor elke volgende groep de gekozen labelklasse, eigenaar, testresultaat en afhankelijkheden vast. Neem de previewstatus mee in risicobeoordelingen totdat Microsoft algemene beschikbaarheid en het definitieve gedrag bevestigt.
Tijdlijn en besluit
Microsoft plant de start van de preview in MC1508238 vanaf medio november 2026. Omdat het om een preview gaat, kan het gedrag nog veranderen. Het verstandigste besluit is daarom niet “alle beveiligingsgroepen nu labelen”, maar eerst vaststellen waar een label aantoonbaar governance toevoegt, de groepssamenstelling daarop controleren en met een beperkte pilot ervaring opdoen. Gebruik de preview pas breder wanneer de techniek, de labeltaxonomie en de herstelprocedure samen zijn gevalideerd.