Sensitivity Labels on Entra ID Security Groups: What the Documentation Doesn't Tell You

Microsoft has previewed an eagerly awaited extension to Purview sensitivity labels: the ability to apply them directly to Entra ID cloud security groups, not only to Microsoft 365 groups, Teams, or SharePoint sites as was previously the case.

The idea is compelling: security groups control access to sensitive resources such as Azure subscriptions, Power BI reports, and Conditional Access, yet they have not always benefited from consistent classification. A label can now prevent, for example, an external guest account from being added to a group that grants access to a critical Azure subscription.

I tested the feature end to end and pushed the validation further than originally planned. Here is what I found.

Three tenant settings, not one

The first lesson is that enabling this feature is not a single operation. Three separate settings must be configured across three different subsystems.

1. Group.Security — Microsoft Graph PowerShell, beta endpoint. This feature flag unlocks the Sensitivity label option for security groups. AllowToAddGuests is independent from labeling: it determines whether guests can generally be added to security groups in the tenant. Without it, no guest can ever be added, which would distort any label-specific blocking test.

2. Group.Unified — the same module, but a different template. This historical setting is required when the Groups and sites scope is enabled for a Purview label, even when the intended use is limited to security groups. The Purview checkbox is shared by both container families.

A trap I encountered: the -Search parameter of Get-MgBetaDirectorySetting is unreliable on this beta endpoint. It may return the wrong object without reporting an error. It is safer to list the settings and filter by the exact display name before making any update.

3. EnableAIPIntegration — SharePoint Online PowerShell. This third switch is inherited from the earlier SharePoint labeling feature. Without it, some protection options such as Control access remain disabled in the label creation wizard, even when the label scope only covers security groups.

Immutability: a real design difference

Unlike Microsoft 365 groups, where a label can be changed or removed at any time, a label applied to a security group is immutable after creation. It cannot be modified or removed. If it was applied incorrectly, the only option is to create a new group.

This is intentional. A Microsoft 365 group is a collaboration construct; a security group is an authorization object evaluated by downstream systems such as Conditional Access and application access controls. A label that could be changed freely would weaken the meaning of the protection.

Publishing and synchronizing the label

After creating the label in Purview with the Groups and sites scope and guest access blocked, and publishing it through a label policy, it must be explicitly synchronized to Entra ID. Synchronization is not automatic and must be triggered again after each label change.

Microsoft announces that synchronization can take up to 24 hours. In my case, the label became available in the group creation dropdown in less than an hour.

The block works, but not for everyone

This was the core of the test. I configured a label that prohibits guest accounts from being added to a group, then tried the operation with two different profiles.

With a Global Administrator account, the guest was added successfully through both the Entra portal and Microsoft Graph API. There was no block despite the label policy, making the label appear ineffective.

With a standard account that owned the group but had no administrative role, the addition failed. The interface displayed only Something went wrong, but the network response was explicit: Authorization_RequestDenied — Guests users are not allowed to join this Cloud Security Group due to policy setting.

The contrast is clear and reproducible. Microsoft documents this behavior among the known limitations of the preview: several highly privileged roles, including Global Administrator, Groups Administrator, and Exchange Administrator, may currently bypass label enforcement. This is not a bug; it is an acknowledged preview behavior. However, it fundamentally changes how the feature must be tested and validated before deployment.

A user-experience issue worth reporting

The generic Something went wrong message is a practical problem. Microsoft Graph returns a structured and meaningful error, but the My Groups interface does not yet appear to interpret this specific response and falls back to a default message.

An employee without technical expertise will not understand that the block is an intentional security policy. They may retry or contact IT without anyone immediately understanding the cause. This is a common pattern with preview features: the backend is functional, while each client interface still needs to be updated to display the new behavior correctly.

What this means for IT departments

Three points should be kept in mind before considering even a pilot deployment:

• The deployment involves several teams. Three tenant settings spread across Entra, Purview, and SharePoint often mean three different areas of responsibility.

• Validation must be performed with a non-privileged account. Testing with an administrator can create the false impression that the protection does not work.

• The user experience is not yet at the level of the backend. A production rollout will probably require internal communication explaining the block until the interface provides a clear message.

The feature addresses a genuine governance blind spot and the protection mechanism does work, but only for the accounts that most need to be monitored—not for highly privileged accounts, which represent the greatest risk if compromised. This is an important point to remember before communicating that the protection is fully active.