Sensitivity label groups are replacing parent labels - what you need to do

Microsoft is replacing parent labels with label groups. If you have built a sensitivity label taxonomy, you will have used parent labels as containers - Confidential as the parent, with sublabels like Confidential - All Employees underneath.

Label groups do the same job but with one key difference: label groups cannot have protection settings. They only support a name, description, colour, and priority. All protection lives on the labels inside the group.

The old model caused confusion because parent labels could have their own encryption settings that conflicted with sublabel settings. Label groups remove that ambiguity. The group is a folder. Only the labels inside it do anything.

The other practical benefit: you can now move labels between groups without breaking anything. Previously, moving a sublabel to a different parent meant recreating it from scratch because GUIDs were tied to the parent-child relationship.

New tenants created from October 2025 onwards get the new model automatically.

Existing tenants are being migrated on a rolling basis. Check for a migration banner in Microsoft Purview portal - Solutions - Information Protection - Sensitivity labels. Tenants with complex setups get a 12-month opt-in window, with forced migration by December 2026.

The migration is irreversible. Test in a non-production tenant first.

Understand what happens to your labels. If your parent label is just a container (no encryption, no markings), it becomes a label group. Sublabels stay inside. Nothing changes. If your parent label has protection settings, the migration creates a new sublabel with the same name and moves the settings to it. The GUID is preserved so automation keeps working.

Before migrating:

1. Audit parent labels. Which ones have protection settings? Those will create new sublabels.

2. Simplify first. Remove protection settings from parents that nobody relies on. Fewer applicable parents means a cleaner migration.

3. Check naming conflicts. All sublabels need unique names. If your parent and sublabel share a name, resolve it first.

4. Test in a non-production tenant. Verify your label picker, auto-labelling policies, and DLP rules all still work.

5. Review GUID-dependent scripts. New sublabels inherit the parent GUID. New label groups get fresh GUIDs.

Label colours may change when labels move into groups. Priority order may shift, causing more justification prompts. Groups cannot be published - only labels can, so update policies that published parent labels directly. Third-party integrations may not support label groups yet.

If you are designing a new taxonomy, use label groups from the start:

Public (group) - one label: Public

Internal (group) - one label: Internal (set as default)

Confidential (group) - multiple labels: All Employees, Finance, Legal

Restricted (group) - multiple labels: Board Only, M&A

Groups set the sensitivity tier. Labels inside set the audience and protection. Keep it flat where you can.