Sensitivity Labels in Microsoft Purview: Auto-Labeling, Encryption, Co-Authoring, and Container Inheritance

A sensitivity label is one classification object projected across files, emails, containers, schematized data, and Power BI — and it can also enforce encryption, content marking, and container controls. The skill is not picking three colors in the wizard. It is designing a taxonomy with sane priority, attaching encryption that survives offline use and co-authoring, choosing client-side versus service-side auto-labeling per workload, and flipping tenant-wide switches (co-authoring, container labels) you cannot cleanly reverse. Get the order wrong and you strand documents, break AutoSave, or lose label metadata. This guide builds the rollout end to end.

Everything works in the Microsoft Purview portal (purview.microsoft.com -> Information Protection), but the durable, reviewable surface is Security & Compliance PowerShell. Connect once:

Install-Module ExchangeOnlineManagement -Scope CurrentUser
Import-Module ExchangeOnlineManagement

# Security & Compliance endpoint — distinct from Connect-ExchangeOnline.
# New-Label / Set-Label / *-LabelPolicy / *-AutoSensitivityLabelPolicy live here.
Connect-IPPSSession -UserPrincipalName admin@kloudvin.com

1. Label architecture: scopes, sublabels, priority, and mandatory labeling

A label is created with New-Label and scoped by ContentType — this is the single most important design decision because it determines where the label can even appear. Valid values combine: File, Email, Site, UnifiedGroup, Teamwork, PurviewAssets, SchematizedData.

New-Label -Name "kv-confidential" -DisplayName "Confidential" `
  -Tooltip "Sensitive KloudVin business data; encrypted." `
  -ContentType "File, Email"

# A container label is a SEPARATE label scoped to Site + UnifiedGroup.
# A label scoped only to File/Email will NOT appear on Teams/Groups/Sites.
New-Label -Name "kv-conf-internal-container" -DisplayName "Confidential" `
  -Tooltip "Private group, no guests" -ContentType "Site, UnifiedGroup"

Container scope (Site/UnifiedGroup) and file scope (File/Email) are deliberately separate objects. Mixing encryption onto a container label is a frequent source of confusion — container labels govern privacy, guest access, and external sharing; they do not encrypt the files inside. Keep them separate.

Sublabels and priority. Labels render to users as an ordered list. Priority is ordering, where a higher priority number means more sensitive (it sits lower in the list — e.g. Highly Confidential above Confidential above Public). Sublabels group related variants (Confidential\Internal, Confidential\Anyone); a parent with sublabels is a header and cannot be applied directly — users must pick a sublabel.

# Make a label a sublabel of a parent.
Set-Label -Identity "kv-confidential-internal" -ParentId "kv-confidential"

# Reorder priority (0 = least sensitive, top of list).
Set-Label -Identity "kv-highly-confidential" -Priority 5

The mandatory-labeling decision. Mandatory labeling forces a label before saving a document or sending mail. It is a policy setting, not a label setting, and a genuine fork: it guarantees coverage but generates help-desk load and trains users to slap on the lowest label to dismiss the prompt. The defensible pattern is a default label first, then mandatory labeling only once auto-labeling carries most of the weight.

2. Encryption: permissions, user-defined rights, offline access, and DKE boundaries

For a label to encrypt, the Azure Rights Management service from Microsoft Purview Information Protection must be activated for the tenant (default in new tenants; older tenants may need manual activation). Encryption is driven by a family of parameters on New-Label/Set-Label. The pivot is EncryptionProtectionType, which accepts: Template, UserDefined, or RemoveProtection.

Admin-defined permissions (Template)

Admin-defined permissions hard-code who can do what. Rights are expressed with EncryptionRightsDefinitions using the syntax Identity:Right1,Right2;Identity2:Right3 — identities can be users, mail-enabled groups, or whole domains:

Set-Label -Identity "kv-confidential" `
  -EncryptionEnabled $true `
  -EncryptionProtectionType "Template" `
  -EncryptionRightsDefinitions "kv-staff@kloudvin.com:VIEW,VIEWRIGHTSDATA,DOCEDIT,EDIT,PRINT,EXTRACT,REPLY,REPLYALL,FORWARD,OBJMODEL;partners.example.com:VIEW,VIEWRIGHTSDATA,REPLY" `
  -EncryptionOfflineAccessDays 7 `
  -EncryptionContentExpiredOnDateInDaysOrNever "Never"

• EncryptionRightsDefinitions is meaningful only when EncryptionProtectionType is Template. Rights map to the usage-rights catalog (VIEW, EDIT, PRINT, EXTRACT = copy/screenshot, REPLY, FORWARD, OWNER, EXPORT, etc.). Granting a domain VIEW only is how you give partners read-only access that travels with the file.
• EncryptionOfflineAccessDays controls how long a use license is cached for offline work — 0 forces re-auth on every open (high security, breaks airplane editing), -1 is unlimited, a value like 7 is the usual middle ground.
• EncryptionContentExpiredOnDateInDaysOrNever set to an integer expires access after N days. This is a co-authoring boundary (see step 4): any value other than Never disables co-authoring/AutoSave for that label.

User-defined permissions (UserDefined)

User-defined permissions let the author choose recipients at apply-time (the “Do Not Forward”/“Encrypt-Only” experiences, or an ad-hoc people picker in Word/Excel/PowerPoint):

Set-Label -Identity "kv-userdefined" `
  -EncryptionEnabled $true `
  -EncryptionProtectionType "UserDefined" `
  -EncryptionPromptUser $true `          # prompt to pick permissions in Office
  -EncryptionDoNotForward $true `        # offer Do Not Forward (Outlook)
  -EncryptionEncryptOnly $false

EncryptionPromptUser is only meaningful with EncryptionProtectionType UserDefined. This is the most collaboration-friendly encryption because users scope it themselves, but it has co-authoring caveats.

Double Key Encryption boundary

Double Key Encryption (DKE) holds one key in your control and one in Microsoft’s, so Microsoft can never decrypt the content. It is configured by pointing the label at your DKE endpoint and is reserved for your most regulated data:

Set-Label -Identity "kv-topsecret" -EncryptionEnabled $true `
  -EncryptionProtectionType "Template" `
  -EncryptionDoubleKeyEncryptionUrl "https://dke.kloudvin.com/KeyManagement"

DKE is a hard wall, by design. DKE-protected content cannot be co-authored, cannot be read by service-side processes (so service-side auto-labeling, DLP content inspection, and eDiscovery cannot see inside it), and is not viewable in Office for the web. Use DKE for the narrow tier that genuinely needs zero-Microsoft-trust — not as the house default.

3. Client-side vs service-side auto-labeling

These are two different engines with different reach, and conflating them is the classic mistake.

	Client-side (label policy setting)	Service-side (auto-labeling policy)
Where it runs	Office apps as the user edits/composes	SharePoint, OneDrive (data at rest) + Exchange (mail in transit)
Configured on	The label policy (Set-LabelPolicy)	A separate auto-labeling policy (New-AutoSensitivityLabelPolicy)
User interaction	Can recommend (prompt) or apply silently	Apply only — no recommend, no user in the loop
Coverage gate	Only where supported app versions exist	Tenant-wide, no client dependency; scale labeling
Min license	Office app + label policy	Service-side, validated via simulation

Client-side lives as advanced settings on the label policy and is ideal for high-sensitivity flows where a human should confirm:

# Recommend "Confidential" when content matches, with a justification prompt.
Set-LabelPolicy -Identity "KloudVin Global" -AdvancedSettings @{
  PolicyTip = "Detected sensitive data — apply Confidential."
}
# (The match conditions for client-side auto-labeling are configured on the
# label's LabelActions/Conditions, e.g. via the portal's auto-labeling tab.)

Service-side is its own policy object and works on content the user is not touching — dormant files in SharePoint/OneDrive and email in transit:

New-AutoSensitivityLabelPolicy -Name "Auto: Confidential SPO/ODB" `
  -ApplySensitivityLabel "kv-confidential" `
  -SharePointLocation "https://kloudvin.sharepoint.com/sites/finance" `
  -OneDriveLocation "All" `
  -Mode TestWithoutNotifications        # SIMULATION — never start in enforce

New-AutoSensitivityLabelRule -Name "Conf rule: financial IDs" `
  -Policy "Auto: Confidential SPO/ODB" `
  -ContentContainsSensitiveInformation @{ Name = "Credit Card Number"; minCount = "1" }

Mind the service-side limits: a tenant ceiling of roughly 100,000 auto-labeled files per day, a max of 100 auto-labeling policies, and up to 100 specific locations per policy when you scope with included/excluded sites or users. These are the constraints that force a wave-based rollout rather than one tenant-wide flip.

4. Co-authoring without metadata loss

By default, an encrypted document in SharePoint/OneDrive must be checked out to edit in desktop Office — no real-time co-authoring, no AutoSave. Enabling co-authoring changes the metadata format and location Office uses for Word/Excel/PowerPoint, and that change is the catch.

Turn it on in Purview portal -> Settings -> Information Protection -> Co-authoring for files with sensitivity labels. Critical preconditions before you flip it:

• Sensitivity labels must already be enabled for Office files in SharePoint/OneDrive (auto-enabled if not).
• Every app/service/script that reads or writes label metadata must support the new format — Microsoft 365 Apps (Windows min 2107 Current Channel), Information Protection client/scanner min 3.0, OneDrive sync min 19.002.0121.0008. A stale mail-flow rule or scanner that reads the old custom-property location will see labeled files as unlabeled or mislabel them.
• After enabling, labeling info for unencrypted files is no longer written to custom properties — so any tool keying off old custom properties breaks.

Two label configurations are incompatible with co-authoring/AutoSave — this is why step 2’s choices matter here:

• EncryptionContentExpiredOnDateInDaysOrNever set to anything other than Never (content expiry).
• Double Key Encryption.

Labels with those settings still appear, but selecting one warns the user that co-authoring/AutoSave is unavailable. You cannot disable co-authoring from the portal once enabled — only via PowerShell, and disabling loses the new-format metadata for unencrypted files:

# Reverse ONLY with full understanding of metadata loss.
Set-PolicyConfig -EnableLabelCoauth:$false

Allow 24 hours for the setting to replicate before relying on it.

5. Container labels for Teams/Groups/SharePoint

Container labels enforce privacy, guest access, and external-sharing posture at the workspace level. First enable label support for containers at the tenant, then synchronize labels to Entra ID:

# Connect-ExchangeOnline (org config lives on the Exchange endpoint)
Set-OrganizationConfig -EnableMIPLabels $true

# Then sync labels so Entra ID can apply them to groups/sites (up to 24h).
Execute-AzureAdLabelSync

Now configure the container behavior on a Site, UnifiedGroup-scoped label:

Set-Label -Identity "kv-conf-internal-container" `
  -SiteAndGroupProtectionEnabled $true `
  -SiteAndGroupProtectionPrivacy "Private" `            # Public | Private
  -SiteAndGroupProtectionAllowAccessToGuestUsers $false `
  -SiteAndGroupProtectionAllowEmailFromGuestUsers $false `
  -SiteExternalSharingControlType "ExternalUserAndGuestSharing"  # or ExistingExternalUserSharingOnly / Disabled

• SiteAndGroupProtectionPrivacy forces a Team/Group to Private or Public regardless of what the creator chose.
• SiteAndGroupProtectionAllowAccessToGuestUsers $false blocks guests on labeled containers — a clean way to keep “Confidential\Internal” workspaces internal.
• SiteExternalSharingControlType maps to the SharePoint site sharing slider: Disabled (only org), ExistingExternalUserSharingOnly, or ExternalUserAndGuestSharing. Unmanaged-device conditional access for the site is also expressed via container-label advanced settings tied to a Conditional Access policy.

Order matters: enable EnableMIPLabels and run Execute-AzureAdLabelSync before you expect container labels in the Teams/SharePoint/Entra creation UI. Skipping the sync is why “my label isn’t showing up on new Teams” tickets appear.

6. Extending labels to SharePoint files, PDF, and Power BI

• SharePoint/OneDrive files: enabling sensitivity labels for Office files in SPO/ODB lets the service read labels, apply them at rest (service-side auto-labeling), edit labeled-encrypted files in Office for the web, and search/eDiscovery them. As of 2025 you can also extend label permissions to downloaded documents — a SharePoint site label can keep encryption attached to files when they leave the site, closing the “download then it’s plaintext” gap.
• PDF: Office apps apply labels (and encryption) to PDFs they generate, and Microsoft Edge opens labeled/encrypted PDFs natively — no separate viewer for read access on managed endpoints.
• Power BI / Fabric: labels flow in once turned on in the Fabric/Power BI admin portal. A label on a dataset/report carries its encryption into exports (Excel, PowerPoint, PDF), so a “Highly Confidential” report stays protected on export — labeling at the data tier, not just the document tier.

7. Staged rollout: simulation, policy scoping, default labels

A label does nothing until a label policy publishes it to users (New-LabelPolicy). The rollout sequence that avoids self-inflicted outages:

# 1) Publish to a pilot ring only, with a low-friction default + justification.
New-LabelPolicy -Name "KV Pilot" `
  -Labels "kv-public","kv-confidential","kv-confidential-internal","kv-highly-confidential" `
  -ExchangeLocation "pilot-users@kloudvin.com"

Set-LabelPolicy -Identity "KV Pilot" -AdvancedSettings @{
  DefaultLabelId = "<GUID-of-kv-public>"   # safe default
  RequiredDowngradeJustification = "True"  # force a reason on downgrade
}

# 2) Auto-labeling stays in simulation until the match quality is proven.
Set-AutoSensitivityLabelPolicy -Identity "Auto: Confidential SPO/ODB" -Mode TestWithoutNotifications

# 3) Only then enable enforcement, by wave.
Set-AutoSensitivityLabelPolicy -Identity "Auto: Confidential SPO/ODB" -Mode Enable

The disciplined progression: default label (coverage with zero training) -> client-side recommend (users learn the taxonomy) -> service-side simulation (validate match quality and conflicts on a tiny scope) -> enforce by wave -> mandatory labeling only after auto-labeling carries the load. Never start auto-labeling in Enable — TestWithoutNotifications first, every time.

Enterprise scenario

A regulated financial-services platform team rolled “Highly Confidential” with admin-defined encryption and, to satisfy an offline-revocation control, set content expiry to 30 days (EncryptionContentExpiredOnDateInDaysOrNever 30) so stale copies would lock themselves out. Weeks later they enabled tenant-wide co-authoring to fix AutoSave complaints from the finance team. Suddenly every “Highly Confidential” document threw “co-authoring and AutoSave aren’t available” in desktop Office, and shared deal models could not be edited concurrently — exactly the workflow they had enabled co-authoring for.

Root cause was the documented incompatibility: any content-expiry value other than Never disables co-authoring/AutoSave for that label. The control and the collaboration requirement were mutually exclusive on the same label.

The fix was to separate the concerns instead of overloading one label. They reverted the collaborative tier to non-expiring encryption (offline access controls the revocation window via short cached licenses), and moved the strict expiry requirement to a distinct, non-co-authored “Highly Confidential\Time-Bound” sublabel for the genuinely short-lived artifacts:

# Collaborative tier: no expiry -> co-authoring works; revocation via short offline window.
Set-Label -Identity "kv-highly-confidential" `
  -EncryptionContentExpiredOnDateInDaysOrNever "Never" `
  -EncryptionOfflineAccessDays 1

# Strict, short-lived tier kept separate (and knowingly NOT co-authorable).
Set-Label -Identity "kv-highly-confidential-timebound" `
  -ParentId "kv-highly-confidential" `
  -EncryptionEnabled $true -EncryptionProtectionType "Template" `
  -EncryptionContentExpiredOnDateInDaysOrNever 30

The lesson: encryption settings, co-authoring, and DKE interact. Decide co-authoring support before you commit content-expiry or DKE to a label that users collaborate on, and use sublabels to isolate the strict tier.

Verify

# Confirm a label's encryption + scope as deployed.
Get-Label -Identity "kv-confidential" |
  Format-List Name,ContentType,Priority,ParentId,EncryptionEnabled,
              EncryptionProtectionType,EncryptionRightsDefinitions,
              EncryptionOfflineAccessDays,EncryptionContentExpiredOnDateInDaysOrNever

# List label policies and what they publish.
Get-LabelPolicy | Format-Table Name,Labels,Mode

# Check auto-labeling mode (must be Enable to enforce; Test* = simulation).
Get-AutoSensitivityLabelPolicy | Format-Table Name,Mode,Workload

# Container labeling enabled at the org level?
Get-OrganizationConfig | Select-Object -ExpandProperty EnableMIPLabels

• Container labels missing in Teams/SPO? Confirm EnableMIPLabels $true, then Execute-AzureAdLabelSync, then wait up to 24h.
• Auto-labeling “not labeling”? Verify Mode -eq 'Enable' (simulation labels nothing) and that you are under the 100k/day ceiling.
• Use Activity Explorer (Purview -> Information Protection -> Activity Explorer) to watch Label applied, Label changed, and Label removed events. Filter for downgrades and justifications — RequiredDowngradeJustification surfaces the user’s reason in the activity record, which is your audit trail for “why did Confidential become Public.”

Rollout checklist

• Label taxonomy designed with sane ContentType scoping (file/email vs container as separate labels) and priority order.
• Azure Rights Management activated; encryption rights expressed with explicit EncryptionRightsDefinitions.
• Offline access (EncryptionOfflineAccessDays) and content expiry (...DaysOrNever) chosen against the co-authoring decision.
• Co-authoring prerequisites validated (app/scanner/sync versions; no tools on old metadata) before enabling.
• Client-side recommend vs service-side auto-labeling chosen per workload; service-side policies start in TestWithoutNotifications.
• EnableMIPLabels $true + Execute-AzureAdLabelSync run for container labels; privacy/guest/sharing set per tier.
• Default label and RequiredDowngradeJustification set on the pilot label policy.
• SharePoint files / PDF / Power BI extension turned on where in scope; extend-permissions-on-download considered.
• Rollout staged: default -> recommend -> simulation -> enforce by wave -> mandatory labeling last.
• Activity Explorer monitored for downgrades, justifications, and auto-labeling volume against the 100k/day ceiling.