Assign Sensitivity Labels to Microsoft Entra Security Groups: Public Preview Governance Guide

Release timing and current status

The feature Assign sensitivity labels to Microsoft Entra security groups entered public preview on 28 May 2026 and appeared in the May 2026 Microsoft Entra announcements.

As of now it remains preview, with active documentation updates continuing through June 2026. That matters because several behaviors are explicitly called out as subject to change before GA.

Microsoft Inside Track also published a Microsoft Digital implementation story in the same period, showing this was driven by real access-control pain around guest inclusion in high-sensitivity security groups, not only feature parity goals.

Why this is a governance shift

Before this preview, classification policy had strong coverage for collaboration containers. Access-control groups were usually governed by naming conventions, owner hygiene, and periodic review.

This feature starts closing that gap by attaching enforceable classification policy directly to cloud security groups that grant real access to apps, roles, and resources.

Important: You do not create a second label catalog for Microsoft Entra. The same Purview labels used for Groups and Sites are reused.

Current enforcement model

In preview, the most visible policy control is guest membership restriction, plus compatibility checks in nested-group scenarios.

From an operations perspective, think of enforcement in three checkpoints:

Label assignment time: group state is validated against selected label policy.
Membership change time: new additions are checked against effective policy.
Nesting operations: parent-child compatibility must satisfy label restrictions.

This is why a group name like SG-Finance-Production-Admins is no longer enough. The policy has to live on the object.

Label policy versus directory settings

There are two policy mechanisms now in play for cloud security groups:

Purview label path: configure guest control in container labels and assign via assignedLabels.
Directory settings path: use Group.Security and Group.Security.Policies settings to control guest behavior.

Independent field analysis from the community shows these controls can coexist and create confusing outcomes if both are configured without a strict ownership model. Operationally, pick one primary enforcement model per group family and document exceptions.

Supported versus unsupported group types

Status	Group type	Notes
Supported	Cloud security groups with assigned membership	Primary preview scope
Not supported	Dynamic membership security groups	Known edge cases exist, policy is not reliably enforced
Not supported	On-premises synced security groups	Hybrid objects are outside current support
Not supported	Exchange-managed groups, mail-enabled security groups, distribution lists	Explicitly excluded in preview

Group.Security template requirement

A key implementation detail is the separate directory template for cloud security groups:

Group.Security

Microsoft 365 group labeling still uses:

Group.Unified

Even mature Purview tenants miss this and wonder why sensitivity labels do not appear for security groups.

Two template IDs observed in Graph tooling and community validation are:

d209f6fa-3839-4d70-b83f-60b1c64d0e8f for Group.Security (tenant-wide)
7e0abea2-5c20-405f-9658-bfc9a523fd49 for Group.Security.Policies (group-scoped)

Prerequisites checklist

At least one active Microsoft Entra ID P1 or P2 license, or qualifying Microsoft 365 E3 or E5 entitlement
Purview label publication with Groups and Sites scope enabled
EnableMIPLabels=True in Group.Security directory settings
Label sync executed with Execute-AzureADLabelSync
Up to 24 hours for synchronized labels to appear in assignment surfaces

PowerShell enablement flow

Typical enablement in a pilot tenant uses Graph beta directory settings:

$params = @{
    templateId = "d209f6fa-3839-4d70-b83f-60b1c64d0e8f"
    values = @(
        @{ name = "AllowToAddGuests"; value = "True" },
        @{ name = "EnableMIPLabels"; value = "True" }
    )
}
New-MgBetaDirectorySetting -BodyParameter $params

Then synchronize labels from Security and Compliance PowerShell:

Execute-AzureADLabelSync

Assignment surfaces and API behavior

You can assign labels from Microsoft Entra admin center, Azure portal, Microsoft Graph, and Graph PowerShell.

Current assignment is persisted in assignedLabels. A minimal API shape looks like:

PATCH /v1.0/groups/{group-id}
Content-Type: application/json

{
  "assignedLabels": [
    {
      "labelId": "<sensitivity-label-id>"
    }
  ]
}

For admin design, remember these two constraints during preview:

Delegated permission models are the practical route for many update workflows.
High-privilege roles or broad app permissions may bypass enforcement in specific operations.

Also note a known preview issue: some PowerShell flows do not return assignedLabels unless explicitly requested. Use ?$select=assignedLabels in Graph queries to verify actual state.

Known preview limitations that impact rollout

Label immutability: labels can be effectively non-editable after assignment.
Nesting workflow constraints: you cannot label a parent that currently contains child groups.
Membership conflict failures: label assignment fails when existing membership violates label policy.
Group-type gaps: dynamic and hybrid group scenarios remain outside reliable enforcement.
Tooling gaps: some portals and automation paths are not yet feature-complete.

Two common error patterns you should expect in pilots:

Label protection policy enforces no guest users allowed in the group when labeling a group that already has guests.
Label policy enforces no nested group members must exist when labeling a parent group that still contains child groups.

Warning: Treat label selection as a design-time decision. In preview, rollback can mean creating replacement groups and migrating membership.

Nested group procedure that avoids failed assignments

Remove child groups from the future labeled parent group.
Apply label to parent group.
Label each child group with equal or stricter policy.
Re-add child groups to parent.
Test guest and nested-member add operations with audit logging enabled.

This order reduces failed writes and keeps your change window predictable.

Practical governance model

Label	Typical security-group usage	Guest policy
Public	Low-sensitivity shared app access	Allowed
Internal	Employee-only internal services	Blocked
Confidential	Business-critical application access	Blocked
Highly Confidential	Privileged admin and production break-glass scopes	Blocked

Pilot plan I would run

Choose 10-20 cloud-assigned security groups with clear business owners.
Enable Group.Security and synchronize labels.
Apply labels to non-production groups first and run membership conflict tests.
Document immutable-label fallback process before production assignment.
Add monitoring for failed membership writes and role-based bypass scenarios.

Operations runbook for incident and drift control

Query target groups with $select=assignedLabels and export baseline.
Enumerate current guests and nested groups before any label assignment.
Apply labels in controlled batches by business-criticality tier.
Capture failed add-member events and correlate with role used for operation.
Review tenant-level and group-level directory settings for conflicting controls.
For immutable-label mistakes, execute replacement-group migration with owner sign-off.

My assessment

This feature is a real governance step forward because it attaches classification policy to authorization primitives, not only collaboration containers.

The value is immediate for high-risk groups. The operational risk is preview immutability and uneven automation paths. Use a controlled pilot first, then scale by label tier.