M365 PlaybooksPurview · SharePoint · Teams · Exchange· Deploy · Sites, groups and Teams
Label sites, groups and Teams
Purpose
Make a workspace's settings match what it holds. A label on a team, Microsoft 365 group or SharePoint site sets its privacy, whether guests can join, how far content can be shared, and whether it can be reached from unmanaged devices, in one choice the owner understands. Without container labels, those settings are decided site by site, drift over time, and a site full of sensitive work can quietly allow sharing with anyone.
Overview
A short set of labels for sites, groups and Teams that set privacy, guest access, external sharing and device access in one choice.
- Effort
- About 15 to 20 person-days
- Duration
- 6 to 10 weeks
- Complexity
- Medium
- Who's in the room
- Purview admin, Entra admin, SharePoint and Teams admin, taxonomy owner, communications lead, owners of pilot sites and Teams
- Licensing
- Labels for groups and sites need at least one Microsoft Entra ID P1 licence in the organization; the unmanaged-device setting relies on Conditional Access, which also needs Entra ID P1. Using authentication contexts through labels needs Microsoft 365 E5, Microsoft 365 E5 Information Protection and Governance, or Office 365 E5.
Risk of not doing it
Without container labels, sensitive sites keep whatever sharing and guest settings they were created with, and nothing stops a confidential team from being shared with anyone.
Key activities
The plan in order: what must be true first, what to decide, then how to configure the pilot and production.
Prerequisites
Turn on labels for groups and sites
Container labels must be enabled in Microsoft Entra ID and then synchronized to Purview; Microsoft Learn has the PowerShell steps. It needs at least one active Entra ID P1 licence, and after synchronization it can take up to 24 hours for labels to be available to Entra ID. Do this well ahead of the pilot. Plan it as a change with its own window, since it touches Entra ID as well as Purview.
Understand what a container label does and doesn't do
A container label controls the container: privacy, external user access, external sharing, access from unmanaged devices, authentication contexts, discovery of private teams, shared channel invitations, the default sharing link, site sharing permissions, and the default label for channel meetings. It does not label the files inside: items don't inherit the label, so they get no markings or encryption from it. Make sure everyone, especially leadership, understands this before the pilot.
Check Conditional Access for device and context settings
The unmanaged-device and authentication-context settings work together with Microsoft Entra Conditional Access. The unmanaged-device setting has no effect if it is less restrictive than the tenant-level setting, and authentication contexts are supported only in some apps (for example, not in the Teams web app). Confirm with the Entra admin which of these you can use before putting them in a label.
Decisions
Decision: Separate container labels or the same labels as files?
One label can cover files and containers, but container settings and file protection answer different questions. A short set of labels scoped only to groups and sites keeps both pickers short. Microsoft also advises putting group and site labels before file labels in the priority order, which affects the sensitivity mismatch alerts described below.
Options
- Reuse every file label for containers
- A short set of labels scoped to groups and sites only
Recommended default: A short set of labels scoped to groups and sites only
Decision: What does each container label set?
Decide per label: privacy (public, private, or left to the owner), guest access, the external sharing level (anyone, new and existing guests, existing guests, or only people in the organization), unmanaged-device access, and shared channel invitations (internal only, same label only, or private team only). Be careful with delegation: once these settings are in a label, a site owner can change them by changing the label. Leave a setting out of the label if owners shouldn't control it.
Options
- Set every option in every label
- Set only the options that differ between labels, and leave tenant defaults for the rest
Recommended default: Set only the options that differ between labels, and leave tenant defaults for the rest
Decision: Require a label on new groups and sites?
The label policy can apply a default label to new groups and sites and require one when people create them. Requiring a label means every new team or site starts with settings that match its purpose. Combine it with a default so routine teams aren't held up. Note that people aren't asked for a justification when they lower a container label. Keep the list of container labels short enough that owners can choose without help; three or four is usually enough.
Options
- Optional labels with no default
- Required labels with a default for routine workspaces
Recommended default: Required labels with a default for routine workspaces
Pilot configuration
Label pilot sites and Teams
Labels can be chosen when a team, group or site is created, applied by owners afterwards, applied by admins in the SharePoint admin center, or set in bulk with PowerShell. Pick five to ten sites and Teams whose owners agree, including one that works with guests, and confirm sharing, guest access and device access behave as intended. Microsoft advises against changing a label's site and group settings once it's in use, so settle them now; when you must change a label, wait at least 24 hours before relying on the new settings.
Plan for sensitivity mismatches
When someone uploads a document whose label has a higher priority than the site's label, the upload isn't blocked, but an email goes to the uploader and to site owners and admins, and the event is audited. Decide who acts on these emails, and set the help link in the email to your own guidance so owners know what to do. Mismatch emails are a useful signal of sites holding more sensitive work than they were set up for.
Production configuration
Label existing workspaces in waves
Work through existing sites and Teams by risk: those known to hold sensitive work first, then the rest. Removing a guest setting from a label doesn't remove guests already in a site, so review guest membership as part of each wave. Teams apply the same label to the team, its group and its SharePoint site, and shared channels inherit the parent team's label. Before each wave, tell the owners what the label will change and when, and give them a way to raise a problem; a sudden change to guest or sharing settings on a busy team is the most common source of complaints.
Hand over and agree how labels change
Document every container label and its settings, who may change a site's label, and how to retire a label safely: remove it from policies and wait at least an hour before deleting it, or new team, group and site creation can fail. Deleting a label stops its settings being enforced, typically within 48 to 72 hours for SharePoint sites.
Make it enforceable
Container labels lock privacy and apply guest, sharing and device settings to every labelled site and team, and the label policy can require a label when a group or site is created, so new workspaces start with matching settings. Site owners can still change a site's label, so the monthly review checks label changes on sensitive sites.
Enforced by a mechanism.
Pilot to production
Rollout approachBy risk tier · Pilot size: 5 to 10 sites and Teams, including one with guests
Container labels change who can reach a workspace, so mistakes hurt most where content is most sensitive and where guests work. Starting with a few consenting owners, then labelling existing sites by risk, keeps each change visible and reversible.
Make your pilot representative
- Every major role, not only IT and enthusiasts
- More than one location or time zone
- Heavy users of the workload you are changing
- People who handle sensitive information
- At least one team you expect to be sceptical
Recruit pilot ownersChange: Inform
Explain what the label will change on their site and how to report a problem.
Move on when: Owners agree and know where to report
Label pilot workspacesChange: Explain
Apply labels and confirm sharing, guests and device access behave as intended.
Move on when: Owners confirm their workspaces still work for their members
Turn on required labels for new workspacesChange: Explain
Publish the default and required settings for groups and sites. Tell the people who create teams and sites most often, and the service desk, before the requirement goes live.
Move on when: New teams and sites are created with a label and no creation failures
Label existing workspaces by riskChange: Explain
Most sensitive sites first, reviewing guests in each wave. Start with sites known to hold sensitive work and those with the most guests, and agree each wave's list with the owners before applying labels.
Move on when: Each wave completes without unexpected loss of access
Make labels part of owner guidanceChange: Sustain
Add container labels to owner onboarding and to the labelling guide.
Move on when: Owners can explain what their site's label controls
Common challenges
If youAssume a site label protects the files inside
What tends to happenLeadership believes a confidential site is protected, but its files carry only the labels people gave them, or none.
A better approachExplain the difference early, and use library default labels or automatic labelling for the files.
If youPut every setting in every label
What tends to happenOwners change sharing and guest settings simply by switching labels, including settings you never meant them to control.
A better approachPut a setting in a label only when it should differ between labels.
If youChange a container label's settings once it's in use
What tends to happenSites labelled before and after the change behave differently, and existing groups don't pick up the new settings on their own.
A better approachSettle settings in the pilot; if they must change, plan it, wait 24 hours, and update existing groups deliberately.
If youDelete a container label straight away
What tends to happenNew teams, groups and sites fail to create, and sites lose the settings the label enforced.
A better approachRemove it from policies first, wait at least an hour, and move sites to another label before deleting it.
If youIgnore mismatch emails
What tends to happenOwners learn to delete them, and sensitive documents keep landing on sites set up for everyday work.
A better approachGive mismatch emails an owner and a help link that says what to do.
Checkpoints
Pilot
- Are container labels enabled and synchronized?
- Does everyone involved understand that files don't inherit the site's label?
- Do pilot workspaces share and admit guests as their labels intend?
- Have device and authentication context settings been confirmed with the Entra admin before use?
Production
- Are new groups and sites created with a label?
- Are existing sensitive workspaces labelled and their guests reviewed?
- Does someone own sensitivity mismatch emails?
- Is there a written, safe procedure for changing and retiring container labels?
Success measures
Capture a baseline before you start, or you won't be able to show the change.
| Measure | Where you see it | Good direction |
|---|---|---|
| Sites and Teams with a container label | Audit log (site label events) | Up |
| Sensitive sites allowing sharing with anyone | Site review in the SharePoint admin center | Down |
| Document sensitivity mismatches | Audit log | Down |
| Owner requests about site labels | Service desk | Steady |
Ready-to-use text
Container label settings table
Label | Privacy | Guests allowed | External sharing | Unmanaged devices | Shared channels | Default sharing link | Who may apply it | Meeting label for channel meetings
Message to site owners
Your site now has the label [label]. It sets who can be invited and how content can be shared: [summary]. It doesn't change the labels on your files. If someone uploads a document more sensitive than the site, you'll get an email; here's what to do: [link].
Owner checklist after a site is labelled
1. Can members still share files the way they need to? 2. Can your guests still get in, if the label allows guests? 3. Can people reach the site from the devices they use? 4. Do you know what to do if you receive a sensitivity mismatch email?
Additional reading
Plan
Configure
Monitor
Changelog
Changelog (1 version)
| Version | Date | Author | Change |
|---|---|---|---|
| 1 | Sev Derghazarian | First version. Facts checked against Microsoft Learn on 2026-10-15. |