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 assets, and Power BI / Fabric items — and unlike a tag, it can enforce: encryption with usage rights, content marking (headers, footers, watermarks), and container controls (privacy, guest access, external sharing). The skill is not picking three colours in the wizard. It is designing a taxonomy with sane priority, attaching encryption that survives offline use and real-time co-authoring, choosing client-side versus service-side auto-labeling per workload, wiring labels into DLP and trainable classifiers, and flipping tenant-wide switches — co-authoring, container labels, the Entra ID label sync — that you cannot cleanly reverse. Get the order wrong and you strand documents behind a key nobody can use, break AutoSave for the exact team you enabled co-authoring for, or lose label metadata that a stale scanner can no longer read.

Everything in this article works in the Microsoft Purview portal (purview.microsoft.com → Information Protection), but the durable, reviewable, diff-able surface is Security & Compliance PowerShell (the IPPS session). Labels, label policies, and auto-labeling policies are all cmdlet-driven there; the portal is a view over the same objects. Connect once and keep this session open — every command in this guide runs against it unless noted:

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

By the end you will treat Information Protection as a system, not a wizard: a taxonomy you can defend at an audit, encryption choices made against the co-authoring decision instead of in spite of it, auto-labeling rolled out in waves behind simulation, and a troubleshooting reflex for the day a labeled-and-encrypted document refuses to open. This is the rollout, end to end, with the commands you keep open during it.

What problem this solves

Data classification on paper is worthless. A policy that says “mark confidential data confidential” with no enforcement, no automation, and no telemetry protects nothing — the moment a file leaves SharePoint as an email attachment, copies to a USB stick, or lands in a personal OneDrive, the “classification” is a colour in a header that a determined or careless user ignores. What organisations actually need is protection that travels with the data: encryption and usage rights baked into the file so that a “View only, no print, no forward” decision is enforced on a recipient’s laptop in another company, offline, three months later. That is what a sensitivity label with encryption delivers, and nothing short of it does.

The pain without this is concrete and expensive. A regulated firm fails an audit because it cannot prove that “Highly Confidential” documents are actually encrypted at rest and in transit — only that a label exists. A breach review finds that the leaked deal model had a “Confidential” footer and zero cryptographic protection. A legal hold pulls thousands of documents that nobody classified, so eDiscovery cannot scope by sensitivity. Meanwhile the attempts to fix this manually fail differently: a team turns on encryption for a tier, then discovers six weeks later that the same tier can no longer be co-authored, so the finance team has reverted to emailing Q3-model-FINAL-v7.xlsx around — the exact behaviour the label was meant to stop.

Who hits this: every organisation with regulatory exposure (financial services, healthcare, public sector, anyone touching PII/PHI/PCI), every team that shares sensitive documents externally, and anyone who has tried to bolt classification onto Microsoft 365 and discovered that the order of operations is unforgiving. The defaults are wrong for protection (no encryption, no mandatory labeling, auto-labeling off), the irreversible switches are unmarked, and the encryption/co-authoring/DKE interactions are documented in three different places. This article is the single map.

To frame the whole field before the deep dive, here is every surface a sensitivity label can reach, what “protection” means there, and the engine that applies it:

Learning objectives

By the end of this article you can:

• Design a sensitivity-label taxonomy with correct ContentType scoping (file/email vs container as deliberately separate objects), sane priority ordering, and sublabels — and explain why a parent-with-sublabels cannot be applied directly.
• Configure label encryption every way it ships: admin-defined permissions (Template), user-defined permissions (UserDefined), RemoveProtection, offline-access windows, content expiry, and Double Key Encryption (DKE) — and name the exact boundary each imposes.
• Decide client-side vs service-side auto-labeling per workload, author auto-labeling policies and rules, and run them through simulation before enforce — respecting the real service-side limits.
• Wire labels into DLP (label as a condition and as an action) and drive detection with sensitive information types (SITs), exact data match (EDM), and trainable classifiers.
• Enable co-authoring for labeled files safely — validate every prerequisite, and avoid the two label configurations that silently disable co-authoring/AutoSave.
• Enforce container labels for Teams/Groups/SharePoint (privacy, guest, external sharing, unmanaged-device CA) after the EnableMIPLabels + Execute-AzureAdLabelSync ritual.
• Configure super-user / decryption for break-glass and tooling, and run the troubleshooting playbook for labeled-and-encrypted documents that won’t open, won’t co-author, or won’t auto-label.

Prerequisites & where this fits

You should be comfortable in Security & Compliance PowerShell (Connect-IPPSSession), reading and writing -AdvancedSettings hashtables, and the difference between that endpoint and Connect-ExchangeOnline (org-config and some container settings live on the Exchange endpoint, not IPPS). You should know your tenant’s licensing posture: sensitivity labels and manual labeling are broadly available, but automatic (client-side and service-side) labeling, DKE, and trainable classifiers require Microsoft 365 E5 / E5 Compliance / E5 Information Protection & Governance (or the standalone Information Protection add-on). Container labeling additionally depends on Microsoft 365 Groups and the relevant SharePoint/Teams plumbing.

This sits at the centre of the Microsoft Purview data-security stack. It is the classification spine that the other Purview disciplines hang off: Purview DLP across Endpoint, Exchange & SharePoint: Policy Authoring and Rollout consumes labels as conditions and applies them as actions; Microsoft Purview Retention Labels & Records Management is the retention twin (different object, complementary lifecycle); Purview eDiscovery (Premium): Legal Hold & Review Sets scopes by label and must be able to decrypt what you protect; and Purview Insider Risk Management reads label-downgrade and exfiltration signals you generate here. Container labels tie into Teams Governance: Lifecycle, Naming, Expiration & Sensitivity Labels and SharePoint & OneDrive External Sharing Governance with Sensitivity Labels.

A quick map of who owns what during a rollout, so you escalate to the right person fast:

Core concepts

Six mental models make every later decision obvious. Internalise these before touching a cmdlet.

A label is one object with many projections — but scope decides where it can appear. New-Label creates the object; its ContentType (file/email/site/group/teamwork/data) determines the surfaces it can even render on. A label scoped only to File, Email will never appear on a Team or a SharePoint site, no matter what else you configure. Container scope and file scope are deliberately separate objects because they do different jobs — file labels classify and encrypt bytes; container labels govern a workspace’s privacy and sharing.

Encryption is an attribute of a label, applied by Azure Rights Management. When a label encrypts, the Azure Rights Management service (from Microsoft Purview Information Protection, the modern name for what was “Azure Information Protection”) wraps the content with a policy: who can do what, for how long, online or off. The encryption is enforced by the consuming application (Office, Edge, the unified labeling client) reading the embedded use-license. This is why protection “travels” — the rights live in the file, not in SharePoint’s ACL.

Priority is sensitivity order, and order is everything. Labels render as an ordered list. A higher priority number means more sensitive and sits lower in the user’s list (Public at the top, Highly Confidential at the bottom). Priority drives the “you can only upgrade silently / downgrade needs justification” logic and the order auto-labeling evaluates. Sublabels group variants under a header; a parent that has sublabels cannot be applied directly — the user must choose a sublabel.

Client-side and service-side auto-labeling are two different engines. Client-side runs in Office as the user edits or composes and can recommend (prompt) or apply silently; it is configured as conditions on the label and policy. Service-side runs in the service on content the user is not touching — files at rest in SharePoint/OneDrive and mail in transit through Exchange — is its own policy object, and can only apply (never recommend; there is no user in the loop). Conflating them is the classic mistake.

Co-authoring changes where and how Office stores label metadata. By default an encrypted document must be checked out to edit in desktop Office — no real-time co-authoring, no AutoSave. Turning on co-authoring for files with sensitivity labels changes the metadata format and storage location Office uses, so every tool that reads or writes that metadata (scanners, mail-flow rules, third-party DLP) must understand the new format, or it will see labeled files as unlabeled. Two label configurations — content expiry and DKE — are fundamentally incompatible with co-authoring.

Decryption is a deliberate capability, not an accident. Once you encrypt with usage rights, the platform also locks out anyone without rights — including your own eDiscovery, search indexing, and (eventually) an admin trying to recover a file whose owner left. Super-user is the controlled escape hatch: identities you explicitly grant the ability to decrypt any protected content. You design break-glass before you encrypt, not after a file is stranded.

The vocabulary in one table

The glossary at the end repeats these for lookup; this table is the mental model side by side:

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

A label is created with New-Label and scoped by ContentType — the single most important design decision, because it determines where the label can even appear. Valid scope tokens combine: File, Email, Site, UnifiedGroup, Teamwork, PurviewAssets (schematized data assets in the Data Map), and SchematizedData. The portal exposes these as the “Items / Files & emails”, “Groups & sites”, and “Schematized data assets” scope checkboxes.

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, and accept that a tier like “Confidential” may legitimately be two labels with the same display name (one for files, one for containers).

The full scope reference — every token, where it surfaces, and the gotcha:

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 in sensitivity, below them visually). 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

A worked taxonomy — the four-tier default that fits most enterprises, with scope, encryption posture, and marking. Build fewer labels than you think you need; every label is a decision a user has to make:

The priority interaction you must get right — how priority drives behaviour:

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.

# Mandatory labeling is a label-policy advanced setting, not a label property.
Set-LabelPolicy -Identity "KloudVin Global" -AdvancedSettings @{
  Mandatory = "True"
}

The coverage-vs-friction trade-off, laid out so you can pick deliberately:

2. Encryption: permissions, usage rights, offline access, and content expiry

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 via the AIPService module). Encryption is driven by a family of parameters on New-Label/Set-Label. The pivot is EncryptionProtectionType, which accepts: Template, UserDefined, or RemoveProtection.

Check activation first — encrypting labels do nothing if the service is off:

# Confirm Azure RMS / Information Protection is activated for the tenant.
Install-Module AIPService -Scope CurrentUser
Connect-AipService
Get-AipService            # ServiceStatus should be 'Enabled'
# If Disabled:
# Enable-AipService

The three protection types — the first fork in every encryption decision:

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-internal" `
  -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 catalogue. 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 §6): any value other than Never disables co-authoring/AutoSave for that label.

The usage-rights catalogue — every right, its code, and what it actually permits. This is the table you keep open when writing EncryptionRightsDefinitions:

The encryption parameter reference — every Set-Label encryption knob, default, and the trade-off:

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 (real-time co-authoring with user-defined permissions has historically required the co-authoring feature and current Office builds; validate before promising it to a team).

The two email-encryption experiences that ride on UserDefined, and how they differ:

Double Key Encryption (DKE)

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 (a service you host that holds your half of the key) 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.

The encryption-strategy comparison — pick the least restrictive option that meets the control, because every step up costs collaboration:

3. Content marking, default labels, and policy behaviour settings

Encryption is the heavy lever, but most of what users see is content marking — headers, footers, and watermarks — and policy behaviour (defaults, justification, mandatory). Marking is configured per label and stamped by the Office client at apply time.

# Visual marking on a label: header, footer, and a diagonal watermark.
Set-Label -Identity "kv-confidential-internal" `
  -ApplyContentMarkingHeaderEnabled $true `
  -ApplyContentMarkingHeaderText "Confidential — KloudVin Internal" `
  -ApplyContentMarkingHeaderFontSize 10 `
  -ApplyContentMarkingHeaderColor "#FF0000" `
  -ApplyContentMarkingFooterEnabled $true `
  -ApplyContentMarkingFooterText "Do not distribute. Classification: Confidential" `
  -ApplyWaterMarkingEnabled $true `
  -ApplyWaterMarkingText "CONFIDENTIAL"

The content-marking parameter set — what to stamp and where:

The label-policy behaviour settings — these live on the policy, not the label, and shape the whole experience:

Set-LabelPolicy -Identity "KloudVin Global" -AdvancedSettings @{
  DefaultLabelId               = "<GUID-of-General>"   # what's pre-selected
  RequiredDowngradeJustification = "True"              # reason on downgrade
  Mandatory                    = "False"               # not yet
  HideBarByDefault             = "False"               # show the sensitivity bar
  DisableMandatoryInOutlook    = "False"               # mandatory applies to mail too
  OutlookDefaultLabel          = "<GUID>"              # separate default for email
  EnableCustomPermissions      = "True"                # allow user-defined permissions UI
  EnableContainerSupport       = "True"                # let policy publish container labels
}

4. Detection: sensitive information types, EDM, and trainable classifiers

Auto-labeling and DLP are only as good as what they can detect. The detection layer has three tools of increasing sophistication: sensitive information types (SITs), exact data match (EDM), and trainable classifiers. You wire these into auto-labeling rules and DLP conditions; getting them right is the difference between accurate labeling and a flood of false positives that trains users to ignore the system.

Sensitive information types (SITs) are pattern detectors — a regex (or keyword/dictionary/function) plus corroborating evidence and a confidence level. Microsoft ships 300+ built-in (Credit Card Number, India PAN, Aadhaar, US SSN, IBAN, etc.); you can build custom ones.

# A custom SIT: KloudVin employee ID (KV- followed by 6 digits) with keyword corroboration.
New-DlpSensitiveInformationType -Name "KloudVin Employee ID" `
  -Description "Internal employee identifier" `
  -Regex "KV-\d{6}" `
  -Keywords "employee","emp id","staff id" `
  -ConfidenceLevel "High"

The detection-method comparison — match the tool to the data:

Confidence and instance count are the two dials that control noise. A rule that fires on “1 credit card at Low confidence” floods; “10 credit cards at High confidence” finds the spreadsheet of card numbers:

Exact Data Match (EDM) matches against a hashed copy of your actual data (e.g. your real customer account numbers), so it has effectively zero false positives — only a real value in your table triggers it. The cost is operational: define a schema, hash and upload the sensitive table, and refresh it on a schedule.

Trainable classifiers recognise a category of content by meaning, not pattern — “this reads like a contract / source code / a resume”. Microsoft ships pre-trained classifiers (Resumes, Source Code, Harassment, Profanity, Threat, etc.); you train custom ones with 50–500 seed documents.

# List available trainable classifiers (built-in + custom).
Get-Classifier | Format-Table Name, Type, Publishable

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

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

Client-side auto-labeling is configured as conditions on the label itself (auto-labeling for files and emails), surfaced through the label policy, and is ideal for high-sensitivity flows where a human should confirm. In the portal it’s the label’s “Auto-labeling for files and emails” tab; the label can either apply silently or recommend with a policy tip and require justification.

# Client-side auto-labeling conditions live on the LABEL (LabelActions/Conditions).
# Recommend "Confidential\Internal" when content matches a financial SIT, with a tip.
Set-Label -Identity "kv-confidential-internal" -AdvancedSettings @{
  # The match conditions for client-side auto-labeling are configured on the
  # label's auto-labeling tab; the policy tip text is set on the policy.
}
Set-LabelPolicy -Identity "KloudVin Global" -AdvancedSettings @{
  PolicyTip = "Detected sensitive data — apply Confidential\Internal."
}

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. This is how you label the back catalogue and mail flow at scale:

New-AutoSensitivityLabelPolicy -Name "Auto: Confidential SPO/ODB" `
  -ApplySensitivityLabel "kv-confidential-internal" `
  -SharePointLocation "https://kloudvin.sharepoint.com/sites/finance" `
  -OneDriveLocation "All" `
  -ExchangeLocation "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 = "10"; confidencelevel = "High" },
     @{ Name = "India Permanent Account Number (PAN)"; minCount = "5"; confidencelevel = "High" }
  )

The auto-labeling-policy mode reference — these are the states you move through, in order:

Mind the service-side limits — these are the constraints that force a wave-based rollout rather than one tenant-wide flip:

Service-side auto-labeling applies a label silently and can apply encryption. Before you set Mode Enable, you must be certain (via simulation) that the rule isn’t about to encrypt a million files that an external partner currently reads — because once encrypted, they lose access until you grant rights. Simulation is not optional; it is the safety interlock.

6. 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 (the service must be able to process labels at rest; it’s auto-enabled if not).
• Every app/service/script that reads or writes label metadata must support the new labeling metadata format. A stale mail-flow rule, a scanner, or a third-party DLP tool 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 the old custom properties — so any tool keying off old custom properties breaks.

The app/service version prerequisites — validate all of these before flipping the tenant switch:

Two label configurations are incompatible with co-authoring/AutoSave — this is why §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. Connect-IPPSSession first.
Set-PolicyConfig -EnableLabelCoauth:$false

Allow 24 hours for the setting to replicate before relying on it. The co-authoring compatibility matrix — what works, what warns, and what to do:

7. Container labels for Teams, Groups, and SharePoint

Container labels enforce privacy, guest access, and external-sharing posture at the workspace level. They are a different object from file labels (scoped Site, UnifiedGroup) and require a tenant ritual before they appear. First enable label support for containers at the tenant, then synchronise labels to Entra ID:

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

# Then sync labels so Entra ID can apply them to groups/sites (allow up to 24h).
# (Requires the AzureADPreview / Microsoft Graph PowerShell label-sync cmdlet.)
Execute-AzureAdLabelSync

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

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

The container-label parameter reference — every workspace control and what it forces:

The external-sharing control mapping — these values are the SharePoint site sharing slider, expressed on the label:

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. The sync can take up to 24 hours; don’t declare it broken until then.

The container vs file label distinction, made explicit because it confuses everyone once:

8. Extending labels to SharePoint files, PDF, and Power BI / Fabric

A label’s reach extends well beyond desktop Office once you enable the relevant integrations. Each surface has a switch and a gotcha.

• 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 include them in search/eDiscovery. As of recent releases 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 needed 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.

The integration switchboard — what to turn on, where, and what it unlocks:

9. DLP integration: labels as conditions and as actions

Sensitivity labels and Data Loss Prevention (DLP) are two sides of one coin. A label classifies and protects the document; a DLP policy watches what people do with classified content and intervenes. The integration runs both directions: a DLP policy can use a label as a condition (“if the document is labeled Confidential and is being shared externally, block it”), and a DLP policy (or its sister, auto-labeling) can be the thing that applies protection. The deep DLP authoring lives in Purview DLP across Endpoint, Exchange & SharePoint; here is the labeling-relevant integration.

# A DLP rule that uses a sensitivity label as a condition (block external sharing
# of anything labeled Highly Confidential across SPO/ODB/Exchange/Endpoint).
New-DlpComplianceRule -Name "Block external share: Highly Confidential" `
  -Policy "KV Data Protection" `
  -ContentContainsSensitiveInformation @(@{ Name = "Highly Confidential"; Type = "SensitivityLabel" }) `
  -AccessScope "NotInOrganization" `
  -BlockAccess $true `
  -NotifyUser "Owner"

The two integration directions, made explicit:

A note on order of precedence when both auto-labeling and DLP can touch the same content: auto-labeling decides the label (and any label-driven encryption); DLP decides whether an action is allowed. They are complementary, not competing — but a label that removes protection (RemoveProtection) interacts with DLP rules that key off encryption, so test those edge cases.

10. Decryption, super-user, and break-glass

Encryption that no one can ever undo is a liability, not a control. The day an executive leaves and their OneDrive holds the only copy of a board deck encrypted to them, or the day eDiscovery must review protected content, or the day a file is encrypted to a deprovisioned group — you need a deliberate decryption capability. Microsoft Purview gives you several, and you design them before you encrypt.

Super-user is the controlled escape hatch: identities you explicitly grant the ability to decrypt and remove protection from any protected content in the tenant. It is off by default and audited. Configure it through the AIPService module:

Connect-AipService

# Turn on the super-user feature (off by default).
Enable-AipServiceSuperUserFeature

# Grant a break-glass account or the eDiscovery service identity super-user rights.
Add-AipServiceSuperUser -EmailAddress "breakglass-rms@kloudvin.com"

# Confirm who holds it (review this regularly — it's a powerful grant).
Get-AipServiceSuperUser

The decryption mechanisms — every legitimate way protected content gets opened or recovered, and who should hold each:

Super-user is the most powerful grant in the entire system — it bypasses all usage rights. Treat it like Global Admin: grant it to a break-glass account and to service identities that genuinely need it (eDiscovery), monitor Get-AipServiceSuperUser on a schedule, alert on changes, and never leave a person’s day-to-day account in the list. DKE content is the one thing super-user cannot decrypt — because Microsoft never holds the second key.

Document tracking and revocation — the per-file recovery lever for a leak:

# Revoke access to a specific tracked document (e.g. a leaked file).
# Requires document tracking; identify the content by its tracking ID.
Set-AipServiceDocumentRevoked -ContentId <id> -IssuerName "admin@kloudvin.com"

11. Staged rollout: simulation, policy scoping, default labels, and waves

A label does nothing until a label policy publishes it to users (New-LabelPolicy). The rollout sequence that avoids self-inflicted outages is the heart of this whole article — the technology is reversible enough only if you sequence it right.

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

Set-LabelPolicy -Identity "KV Pilot" -AdvancedSettings @{
  DefaultLabelId = "<GUID-of-kv-general>"   # safe default (not Public, not encrypted)
  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 — each phase de-risks the next:

The rollout-ring strategy — who gets it when:

Never start auto-labeling in Enable. TestWithoutNotifications first, every time — it is the only way to see what would happen before encryption locks files. The single most expensive mistake in this entire domain is enabling service-side auto-labeling with encryption on a broad scope without simulation, and discovering you encrypted a SharePoint library that external partners depend on.

Architecture at a glance

Picture the system as three concentric rings around a single object — the sensitivity label — because that object is the only thing that exists in all of them.

At the centre is definition: the label and its sublabels live in Microsoft Purview / IPPS as one object with a ContentType scope, a Priority, optional encryption (admin-defined Template, author-chosen UserDefined, or DKE), content marking, and — for Site, UnifiedGroup-scoped labels — container protection settings. Nothing reaches a user yet; this ring is pure configuration, fully reversible, fully diff-able in PowerShell.

The middle ring is distribution and application. A label policy publishes a chosen subset of labels to a chosen population (Exchange/SharePoint/OneDrive locations or security groups), sets the default label, mandatory/justification behaviour, and policy tips. From there the label is applied by three distinct engines that you must hold separate in your head: manual (the user picks it in the Office sensitivity bar), client-side auto-labeling (Office evaluates the label’s conditions as the user edits and either applies silently or recommends with a tip), and service-side auto-labeling (a separate AutoSensitivityLabelPolicy evaluates content at rest in SharePoint/OneDrive and in transit through Exchange, applying silently — and only after you have proven its match quality in TestWithoutNotifications simulation). Detection feeds all three from the same toolbox: SITs, EDM, and trainable classifiers.

The outer ring is enforcement and consumption — where the label does something. When a label carries encryption, Azure Rights Management wraps the content with a use-license, and from that moment the rights travel with the file: a partner granted VIEW opens it read-only on their own laptop, offline, until the cached license expires; DLP reads the same label as a condition to block risky movement; co-authoring lets multiple editors work the encrypted file in real time only if the label avoids content expiry and DKE; containers (Teams/Groups/Sites) inherit privacy and sharing posture via the Entra ID label sync; and decryption is available exactly to the identities you pre-authorised — the author with OWNER, eDiscovery, and the super-user break-glass account. The whole design discipline is keeping these rings in order: define before you publish, simulate before you enforce, decide co-authoring before you commit encryption, and design decryption before you encrypt anything at all.

The single most useful way to read this architecture during an incident is to ask, in order: Is the label defined and scoped to this surface? Is it published to this user? Which engine applied (or failed to apply) it? Does its encryption permit what’s being attempted? And who can decrypt it if recovery is needed? Five questions, one per ring-transition, and every labeled-document problem in the troubleshooting section below lands on exactly one of them.

Real-world scenario

Northwind Capital, a 4,000-seat asset-management firm in Mumbai, ran a regulated Information Protection programme. They rolled “Highly Confidential” with admin-defined encryption and, to satisfy an offline-revocation control demanded by their compliance team, set content expiry to 30 days (EncryptionContentExpiredOnDateInDaysOrNever 30) so stale copies of deal documents would lock themselves out. The label tested fine; encryption worked; partners with VIEW rights could read deal teasers and nothing more. The programme owner declared victory and moved on.

Six weeks later the firm enabled tenant-wide co-authoring for files with sensitivity labels — a separate initiative, driven by loud complaints from the deal team that they couldn’t co-edit financial models and kept emailing Project-Atlas-model-v11-FINAL.xlsx around, the exact behaviour the labels were meant to kill. The co-authoring switch flipped, 24 hours passed, and AutoSave came alive for most documents. But every “Highly Confidential” deal model now threw “co-authoring and AutoSave aren’t available” in desktop Office. Shared models could not be edited concurrently — precisely the workflow they had just spent a quarter enabling co-authoring to fix. Worse, a junior analyst, unable to co-author the protected model, saved an unprotected copy to a personal folder “to work on it” — a near-miss the Insider Risk team caught only because the label downgrade fired a signal.

Root cause was the documented incompatibility: any content-expiry value other than Never disables co-authoring/AutoSave for that label. The 30-day expiry control and the real-time-collaboration requirement were mutually exclusive on the same label — two correct requirements, fatally overloaded onto one object. Nobody had connected the two projects, because the encryption decision (the compliance team, six weeks earlier) and the co-authoring decision (the productivity team, now) lived in different change tickets.

The fix was to separate the concerns instead of overloading one label. They reverted the collaborative tier to non-expiring encryption — the revocation requirement was satisfied differently, by a short offline-access window (EncryptionOfflineAccessDays 1), so a stale copy re-checks rights daily and a revoked user loses access within 24 hours without needing content expiry. The genuinely short-lived artifacts — signed term sheets that must self-destruct — moved to a distinct, knowingly non-co-authored “Highly Confidential \ Time-Bound” sublabel:

# 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 deal team got real-time co-authoring on the model tier; compliance kept a self-expiring tier for the artifacts that truly needed it; and Insider Risk stopped seeing analysts make unprotected copies to escape a broken collaboration experience. The incident as a timeline, because the order of decisions is the lesson:

The lesson on the wall: encryption settings, co-authoring, and DKE interact across project boundaries. 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.

Advantages and disadvantages

Information Protection with sensitivity labels is the strongest data-centric control Microsoft 365 offers — and it is also the one most able to strand your own data if mis-sequenced. Weigh it honestly:

The model is right for any organisation with regulatory exposure or genuinely sensitive data that leaves the tenant. It bites hardest on teams that treat it as a wizard rather than a system: enable encryption without planning decryption, flip co-authoring without checking which labels block it, or set service-side auto-labeling to Enable without simulation. Every disadvantage is manageable — but only with the sequencing this article prescribes.

Hands-on lab

Stand up a minimal, defensible label set end to end, run an auto-labeling policy through simulation, and verify it — all in Security & Compliance PowerShell, all reversible. This lab does not enable encryption broadly or flip the irreversible tenant switches (co-authoring, mandatory) so it is safe to run in a test tenant.

Step 1 — Connect and confirm the RMS service.

Connect-IPPSSession -UserPrincipalName admin@kloudvin.com
# In a second window, confirm encryption is even possible:
Connect-AipService
Get-AipService        # ServiceStatus should read 'Enabled'

Expected: ServiceStatus : Enabled. If Disabled, run Enable-AipService (test tenant only).

Step 2 — Create a three-tier taxonomy (file/email scope, no encryption yet).

New-Label -Name "kv-public"  -DisplayName "Public"  -Tooltip "Approved for public release" -ContentType "File, Email"
New-Label -Name "kv-general" -DisplayName "General" -Tooltip "Internal business data"        -ContentType "File, Email"
New-Label -Name "kv-confidential" -DisplayName "Confidential" -Tooltip "Sensitive business data" -ContentType "File, Email"
Set-Label -Identity "kv-general"      -Priority 1
Set-Label -Identity "kv-confidential" -Priority 2

Expected: three labels; Get-Label | Format-Table DisplayName,Priority shows Public (0) → General (1) → Confidential (2).

Step 3 — Add content marking to Confidential (visible, harmless).

Set-Label -Identity "kv-confidential" `
  -ApplyContentMarkingFooterEnabled $true `
  -ApplyContentMarkingFooterText "Confidential — KloudVin Internal" `
  -ApplyWaterMarkingEnabled $true -ApplyWaterMarkingText "CONFIDENTIAL"

Step 4 — Publish to a pilot with a safe default + downgrade justification.

New-LabelPolicy -Name "KV Lab Pilot" `
  -Labels "kv-public","kv-general","kv-confidential" `
  -ExchangeLocation "you@kloudvin.com"
Set-LabelPolicy -Identity "KV Lab Pilot" -AdvancedSettings @{
  DefaultLabelId = (Get-Label -Identity "kv-general").Guid.ToString()
  RequiredDowngradeJustification = "True"
}

Expected: Get-LabelPolicy "KV Lab Pilot" | Format-List Labels,Settings shows the three labels and the default/justification settings.

Step 5 — Create a service-side auto-labeling policy in SIMULATION.

New-AutoSensitivityLabelPolicy -Name "Lab Auto: Confidential" `
  -ApplySensitivityLabel "kv-confidential" `
  -OneDriveLocation "All" -SharePointLocation "All" `
  -Mode TestWithoutNotifications        # SIMULATION — applies nothing

New-AutoSensitivityLabelRule -Name "Lab rule: credit cards" `
  -Policy "Lab Auto: Confidential" `
  -ContentContainsSensitiveInformation @{ Name = "Credit Card Number"; minCount = "1"; confidencelevel = "High" }

Expected: policy created with Mode : TestWithoutNotifications. It will simulate over time and label nothing.

Step 6 — Verify everything as deployed.

Get-Label -Identity "kv-confidential" |
  Format-List DisplayName,ContentType,Priority,ParentId,EncryptionEnabled,ApplyWaterMarkingEnabled
Get-LabelPolicy | Format-Table Name,Mode
Get-AutoSensitivityLabelPolicy | Format-Table Name,Mode,Workload

Expected: Confidential shows ContentType : File, Email, Priority : 2, watermark enabled; the auto policy shows TestWithoutNotifications.

Validation checklist. You created a sane three-tier taxonomy, marked the sensitive tier, published it to a pilot with a safe default and downgrade justification, and stood up a service-side auto-labeling policy in simulation — the exact safe-by-default posture this article argues for. No encryption was switched on broadly; no irreversible tenant switch was flipped. The lab steps mapped to what each proves:

Cleanup (remove the lab objects).

Remove-AutoSensitivityLabelRule -Identity "Lab rule: credit cards" -Confirm:$false
Remove-AutoSensitivityLabelPolicy -Identity "Lab Auto: Confidential" -Confirm:$false
Remove-LabelPolicy -Identity "KV Lab Pilot" -Confirm:$false
Remove-Label -Identity "kv-confidential" -Confirm:$false
Remove-Label -Identity "kv-general" -Confirm:$false
Remove-Label -Identity "kv-public" -Confirm:$false

Cost note. Labels, policies, and auto-labeling carry no per-object Azure charge — the cost is licensing (E5/E5 Compliance for auto-labeling and classifiers) and the operational time to design and run the rollout. A test tenant or E5 trial runs this lab at zero marginal cost.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First as a scannable table you can read mid-incident, then the highest-value entries expanded with the exact confirm command.

The expanded form for the entries that bite hardest:

2. Container labels missing on new Teams/SharePoint. Root cause: EnableMIPLabels is $false, or Execute-AzureAdLabelSync was never run, or the 24-hour sync hasn’t completed. Confirm: Connect-ExchangeOnline; Get-OrganizationConfig | Select-Object -ExpandProperty EnableMIPLabels returns False; the container label has SiteAndGroupProtectionEnabled $true but doesn’t show in the Teams/SharePoint creation UI. Fix: Set-OrganizationConfig -EnableMIPLabels $true, then Execute-AzureAdLabelSync, then wait up to 24 hours. Do not declare it broken before then — premature re-runs don’t speed it up.

4. Encrypted file won’t open for a recipient who should have access. Root cause: The recipient is not covered by EncryptionRightsDefinitions (missing user, wrong group, or wrong domain string), or they hold a right that doesn’t include VIEW. Confirm: The recipient sees “you do not have permission to open this”; Get-Label -Identity <label> | Format-List EncryptionRightsDefinitions shows the exact identities and rights — check the recipient’s domain/group is present and includes VIEW. Fix: Add the identity or domain with at least VIEW,VIEWRIGHTSDATA; for partners, VIEW,VIEWRIGHTSDATA,REPLY is a common read-only bundle. The change applies to files labeled after the update (already-encrypted files carry the rights baked in at apply time — they may need reapplying).

5. “Co-authoring and AutoSave aren’t available” after enabling co-authoring. Root cause: The label has content expiry (EncryptionContentExpiredOnDateInDaysOrNever ≠ Never) or DKE — both are incompatible with co-authoring by design. Confirm: Get-Label -Identity <label> | Format-List EncryptionContentExpiredOnDateInDaysOrNever, EncryptionDoubleKeyEncryptionUrl — a non-Never value or a DKE URL is the cause. Fix: Set expiry to Never on the collaborative tier (use a short EncryptionOfflineAccessDays for revocation instead), and move the strict expiry/DKE requirement to a separate, knowingly non-co-authored sublabel — exactly the Northwind Capital pattern.

8. External partner suddenly can’t open files (service-side auto-label encrypted them). Root cause: A service-side auto-labeling policy moved to Enable with an encrypting label, on a scope that included a library external partners read — encrypting files they have no rights to. Confirm: Activity Explorer (Purview → Information Protection → Activity Explorer) shows Label applied events with encryption on those files, timestamped to when you enabled the policy; the partner sees “no permission”. Fix: Either add the partner’s domain to the label’s EncryptionRightsDefinitions with VIEW, or exclude that site from the auto-labeling policy. Prevent it: this is the reason simulation (TestWithoutNotifications) is mandatory — simulation would have shown the impending encryption before any file was touched.

13. Can’t recover a leaver’s encrypted file. Root cause: No super-user was configured before encryption, so no identity can decrypt content the leaver was the only rights-holder for. Confirm: Connect-AipService; Get-AipServiceSuperUser returns empty; Get-AipServiceSuperUserFeature shows the feature disabled. Fix: Enable-AipServiceSuperUserFeature then Add-AipServiceSuperUser -EmailAddress <break-glass>; the break-glass account can then open/remove protection. Design this before encrypting anything — retrofitting super-user works going forward but underscores that decryption is a pre-requisite, not an afterthought. (Note: super-user cannot decrypt DKE content — Microsoft never holds the second key.)

Use Activity Explorer throughout (Purview → Information Protection → Activity Explorer) to watch Label applied, Label changed, Label removed, and Label downgraded 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”, and a feed into Insider Risk.

Best practices

• Design the taxonomy before any cmdlet — fewer tiers than you think (4–5), file vs container as deliberately separate objects, priority order agreed and signed off. Every label is a decision a user must make.
• Decide co-authoring support before committing content-expiry or DKE to any label users collaborate on. Use sublabels to isolate the strict, non-collaborative tier.
• Plan decryption before you encrypt. Configure super-user (break-glass + eDiscovery identity) first; encryption without a recovery path strands data.
• Simulation is mandatory. Every service-side auto-labeling policy starts in TestWithoutNotifications; only enforce a scope after simulation proves match quality and shows no surprise encryption.
• Roll out in the disciplined order: default label → client recommend → service simulation → enforce by wave → containers → co-authoring → mandatory labeling last.
• Use the least restrictive encryption that meets the control. Prefer label Template with a short offline window over content expiry; reserve DKE for the narrow zero-trust tier.
• Express external access explicitly — grant partner domains VIEW,VIEWRIGHTSDATA (read-only that travels), never EXTRACT/PRINT/FORWARD unless intended.
• Tune detection for signal, not noise — High confidence and a sensible minimum instance count on SITs; EDM for zero-false-positive matching of your real data; trainable classifiers for document types.
• Validate every co-authoring prerequisite (Office build, scanner 3.0+, OneDrive sync, third-party tooling) before flipping the tenant switch; allow 24h to replicate.
• Manage labels and policies as reviewed change — script them in PowerShell, version the definitions, and never delete an in-use label (disable by removing it from policies instead).
• Monitor Activity Explorer for downgrades, justifications, and auto-labeling volume against the ~100k/day ceiling; alert on super-user membership changes.
• Run Execute-AzureAdLabelSync and EnableMIPLabels early for container labels, and wait the full 24 hours before troubleshooting “missing” container labels.

Security notes

• Encryption rights are least-privilege. Grant the minimum usage rights — VIEW for read-only partners, never blanket OWNER. Every extra right (EXTRACT, PRINT, FORWARD, EXPORT) is a way data leaves protection.
• Super-user is your most powerful grant. It bypasses all usage rights tenant-wide. Restrict it to a break-glass account and genuinely-needed service identities (eDiscovery); monitor Get-AipServiceSuperUser, alert on changes, and keep no person’s day-to-day account in the list.
• DKE is the zero-Microsoft-trust boundary — use it where regulation demands that Microsoft itself must never be able to decrypt, and accept that it disables co-authoring, web edit, and all service-side inspection (including your own DLP/eDiscovery).
• Container labels enforce isolation — pair an “Internal” tier (Private, no guests, Disabled external sharing) with conditional access for unmanaged devices so the workspace and its files stay internal; this complements, not replaces, file encryption.
• Label-downgrade is a security signal. RequiredDowngradeJustification plus Insider Risk Management turns “user lowered Confidential to Public” into a captured, scored event — wire it through.
• Protect the detection pipeline — EDM uploads your real sensitive data (hashed); secure the EDM schema and upload process, and restrict who can edit SITs and classifiers (a loosened SIT can silently stop protecting data).
• Secure the DKE service you host — it holds half your most sensitive keys; treat its availability and access control as tier-0 infrastructure, because if it’s down, DKE content can’t be opened at all.
• Audit everything — RMS access, super-user use, and label changes are logged; route them to your SIEM. Encryption you can’t audit is encryption you can’t defend at an audit.

Cost & sizing

The bill for Information Protection is almost entirely licensing and operational time, not per-object Azure charges. What drives it:

• Licensing is the gate. Manual labeling and basic protection are broadly available, but the high-value capabilities — client-side and service-side automatic labeling, trainable classifiers, EDM, DKE — require Microsoft 365 E5, E5 Compliance, or E5 Information Protection & Governance (or the standalone Information Protection & Governance add-on stacked on a lower base). Budget per-user E5 economics for the population that needs auto-labeling, not the whole tenant if only a subset is in scope.
• Operational time dominates the real cost. A defensible rollout is weeks of design, simulation, pilot, and wave enforcement — the expensive resource is the architect’s and the IP team’s time, not infrastructure. Skipping this time is what creates cost (stranded files, broken external access, help-desk floods).
• DKE adds infrastructure — you host the key-management endpoint (a small, highly-available web service). Its cost is modest but its availability requirement is high (DKE content is unopenable if it’s down), so size it for redundancy.
• No per-label or per-policy Azure charge — you can create the labels, policies, and auto-labeling policies you need within the documented object limits (100 auto-labeling policies, etc.) at no marginal cost; the constraint is the ~100k-files/day labeling ceiling, which shapes time, not money.

A rough sizing picture for a 4,000-seat firm like Northwind Capital: E5/E5-Compliance for the population in scope (the dominant line item, in the order of the E5 add-on per user per month), a small always-on DKE service if a zero-trust tier exists (~₹5,000–15,000/month for a redundant pair), and the one-time programme cost of the rollout (weeks of architect + IP-team effort). The cost drivers as a table:

Interview & exam questions

1. What determines where a sensitivity label can appear, and why are file and container labels separate objects? A label’s ContentType scope (File, Email, Site, UnifiedGroup, Teamwork, schematized) determines its surfaces; a label scoped only to File, Email never appears on a Team or Site. File and container labels are separate because they do different jobs — file labels classify and encrypt bytes; container labels govern a workspace’s privacy, guest access, and external sharing and do not encrypt the files inside. The same display name (“Confidential”) often legitimately needs both a file label and a container label.

2. Explain the difference between client-side and service-side auto-labeling. Client-side runs in Office as the user edits/composes, is configured as conditions on the label/policy, and can recommend (prompt) or apply silently. Service-side is a separate AutoSensitivityLabelPolicy that runs in the service on content the user isn’t touching — files at rest in SharePoint/OneDrive and mail in transit through Exchange — applies silently only (no recommend), and supports a simulation mode (TestWithoutNotifications) you must use before enforcing.

3. A label uses Template encryption. How do you give an external partner read-only access that travels with the file? Add the partner’s domain to EncryptionRightsDefinitions with VIEW,VIEWRIGHTSDATA (and optionally REPLY for email) — e.g. partners.example.com:VIEW,VIEWRIGHTSDATA. Because the rights are embedded by Azure Rights Management at apply time, the partner gets read-only access on their own device, offline, anywhere — and cannot print, copy, or forward unless you also grant those rights.

4. Which two label configurations are incompatible with co-authoring, and how do you keep the control while enabling collaboration? Content expiry (EncryptionContentExpiredOnDateInDaysOrNever ≠ Never) and Double Key Encryption (DKE) both disable co-authoring/AutoSave. To keep collaboration, remove expiry from the collaborative tier (use a short EncryptionOfflineAccessDays for revocation instead) and move the strict expiry/DKE requirement to a separate, knowingly non-co-authored sublabel.

5. What does DKE protect against that ordinary label encryption doesn’t, and what does it cost? DKE holds one key in your control and one in Microsoft’s, so Microsoft can never decrypt the content — protecting against scenarios where even Microsoft must be untrusted (certain regulated data). It costs you co-authoring, Office-for-the-web editing, and all service-side processing — service-side auto-labeling, DLP content inspection, and eDiscovery cannot see inside DKE content. It’s a hard wall for a narrow tier, not a default.

6. An app restart-loop equivalent for labels: a freshly-published label doesn’t show up in a user’s Office. What do you check? Confirm the label is in a label policy that targets that user (Get-LabelPolicy <p> | Format-List Labels,ExchangeLocation), that the user is in scope, and that Office has synced the policy (it refreshes periodically — restart Office to force it). A label exists but is invisible until a policy publishes it to that person.

7. Why is TestWithoutNotifications mandatory before enforcing service-side auto-labeling? Because service-side auto-labeling applies labels silently and can apply encryption. Enabling it on a broad scope without simulation can mass-encrypt files that external partners currently read, locking them out until rights are regranted — an effectively irreversible mistake. Simulation shows exactly what would be labeled and encrypted before any file is touched; it is the safety interlock.

8. What is super-user, who should hold it, and what is its one limitation? Super-user is an Azure RMS capability that lets specified identities decrypt and remove protection from any protected content tenant-wide, bypassing all usage rights — the break-glass path for recovery, eDiscovery, and leavers. It should be restricted to a break-glass account and genuinely-needed service identities, monitored and audited. Its one limitation: it cannot decrypt DKE content, because Microsoft never holds the second key.

9. How do priority and sublabels work together, and what can’t you do with a parent label that has sublabels? Priority orders labels by sensitivity (higher number = more sensitive, lower in the list) and drives silent-upgrade vs justification-on-downgrade and auto-label precedence. Sublabels group variants under a parent header. A parent that has sublabels cannot be applied directly — it’s a grouping header; the user must choose one of its sublabels.

10. You enabled tenant co-authoring and now a scanner reports labeled files as unlabeled. Why and how do you fix it? Co-authoring changes the metadata format and storage location Office uses, and labeling info for unencrypted files stops being written to the old custom-property location. A scanner/tool below the supported version (Information Protection client/scanner 3.0+) reads the old location and sees the files as unlabeled. Fix by updating every tool that reads/writes label metadata to a new-format-aware version before (ideally) enabling co-authoring.

11. How do labels and DLP integrate? Both directions: a DLP policy can use a label as a condition (e.g. block external sharing of anything labeled Highly Confidential) and detection (SIT/EDM/classifier) can apply a label via auto-labeling. The label classifies and (optionally) encrypts; DLP governs movement and actions. A label downgrade also feeds Insider Risk as an exfiltration signal.

12. What’s the right rollout order, and what goes last? Default label (coverage, zero training) → client-side recommend (users learn the taxonomy) → service-side simulation (validate match quality on a tiny scope) → enforce by wave → container labels → co-authoring → mandatory labeling last, only once auto-labeling carries the load. Starting auto-labeling in Enable, or turning on mandatory labeling first, are the two classic order-of-operations failures.

These map to SC-400 (Information Protection Administrator) as the primary cert — implement information protection, implement DLP, implement information governance — and touch SC-401 (Administering Information Security), MS-102 (Microsoft 365 Administrator) for the tenant integration, and SC-100 (Cybersecurity Architect) for the data-protection strategy. A compact cert mapping:

Quick check

1. A container label (scoped Site, UnifiedGroup) is configured with SiteAndGroupProtectionPrivacy "Private" and no guests. Does it encrypt the files inside the Team? Why or why not?
2. You turn on tenant co-authoring and your “Highly Confidential” deal models suddenly can’t be co-edited, showing “co-authoring and AutoSave aren’t available.” Name the two label settings that could cause this and the one you most likely have.
3. True or false: you should set a new service-side auto-labeling policy directly to Mode Enable so it starts protecting immediately.
4. An external partner with VIEW,VIEWRIGHTSDATA on a label complains they can’t print the document. Is this a bug? What would you change if printing is intended?
5. A leaver’s encrypted OneDrive file is the only copy of a critical document and no one can open it. What capability should have been configured before encryption, and can it recover DKE content?

Answers

1. No. Container labels govern the workspace (privacy, guest access, external sharing) — they do not encrypt the bytes of files inside. To encrypt those files you need a separate file-scoped (File, Email) label with EncryptionEnabled $true. File and container labels are deliberately different objects, and may share a display name.
2. Content expiry (EncryptionContentExpiredOnDateInDaysOrNever ≠ Never) and Double Key Encryption (DKE) both disable co-authoring/AutoSave. On a “Highly Confidential” deal tier you most likely have content expiry set to a number of days (a common compliance control). Fix: set it to Never and use a short EncryptionOfflineAccessDays for revocation, moving the strict-expiry need to a separate non-collaborative sublabel.
3. False. Always start in TestWithoutNotifications (simulation). Service-side auto-labeling applies labels and encryption silently; jumping straight to Enable on a broad scope can mass-encrypt files external partners depend on, locking them out irreversibly. Simulation shows what would happen first.
4. Not a bug — it’s by design. VIEW,VIEWRIGHTSDATA grants read access only; printing requires the PRINT right. If printing is intended, add PRINT to that identity in EncryptionRightsDefinitions (and reapply the label to existing files, which carry rights baked in at apply time). Granting only VIEW is precisely how you give read-only access that can’t be printed or copied.
5. Super-user should have been enabled and granted to a break-glass account before encryption (Enable-AipServiceSuperUserFeature + Add-AipServiceSuperUser); a super-user can then open/remove protection from the leaver’s file. However, super-user cannot decrypt DKE content — because Microsoft never holds the second key — so DKE content owned solely by a leaver is unrecoverable, which is a deliberate property of DKE to weigh before using it.

Glossary

• Sensitivity label — a Microsoft Purview classification object that can also enforce encryption, content marking, and (for container scope) workspace controls; one object projected across files, email, containers, PDF, and Power BI.
• ContentType (scope) — the surfaces a label can appear on (File, Email, Site, UnifiedGroup, Teamwork, PurviewAssets, SchematizedData); determines where the label even renders.
• Sublabel — a variant grouped under a parent header label (Confidential\Internal); set via ParentId. A parent that has sublabels cannot be applied directly.
• Priority — sensitivity ordering of labels (higher number = more sensitive, lower in the list); drives silent-upgrade vs downgrade-justification and auto-label precedence.
• Label policy — the object (*-LabelPolicy) that publishes a chosen set of labels to a chosen population and sets defaults, mandatory/justification behaviour, and policy tips. A label is invisible until a policy publishes it.
• Azure Rights Management (Azure RMS) — the Microsoft Purview Information Protection service that encrypts content and enforces usage rights via embedded use-licenses; must be activated for the tenant for encrypting labels to work.
• EncryptionProtectionType — the encryption mode: Template (admin-defined rights), UserDefined (author chooses recipients), or RemoveProtection (strips encryption).
• EncryptionRightsDefinitions — the identity:rights;... string defining who can do what under Template encryption (e.g. VIEW,EDIT,PRINT,EXTRACT,FORWARD,OWNER).
• Usage rights — the catalogue of granular permissions (VIEW, EDIT, PRINT, EXTRACT, FORWARD, EXPORT, OWNER, etc.) embedded in protected content.
• Double Key Encryption (DKE) — encryption with one key in your control and one in Microsoft’s, so Microsoft can never decrypt; disables co-authoring, web edit, and all service-side inspection.
• Content expiry (EncryptionContentExpiredOnDateInDaysOrNever) — access expires after N days; any value other than Never disables co-authoring/AutoSave.
• Offline access (EncryptionOfflineAccessDays) — how long a use-license is cached for offline work (0 = re-auth every open, -1 = unlimited, N = revoke window).
• Client-side auto-labeling — labeling that runs in Office as the user edits/composes; can recommend or apply silently; configured as label conditions.
• Service-side auto-labeling — labeling that runs in the service on content at rest (SharePoint/OneDrive) and in transit (Exchange), via AutoSensitivityLabelPolicy; applies silently; supports simulation.
• Simulation (TestWithoutNotifications) — auto-labeling mode that logs what would be labeled without applying anything; the mandatory pre-enforce safety interlock.
• SIT (sensitive information type) — a pattern detector (regex + corroboration + confidence) used to find sensitive data; built-in (CC, SSN, PAN, Aadhaar) or custom.
• EDM (Exact Data Match) — detection that matches against a hashed copy of your real sensitive data table, giving effectively zero false positives.
• Trainable classifier — an ML model that recognises a category of content by meaning (resumes, source code, contracts) rather than pattern.
• Container label — a Site, UnifiedGroup-scoped label that governs Team/Group/Site privacy, guest access, and external sharing; does not encrypt files.
• EnableMIPLabels / Execute-AzureAdLabelSync — the org-config switch and Entra label-sync command required before container labels appear in Teams/SharePoint/Entra (up to 24h to take effect).
• Co-authoring (for labeled files) — the tenant feature enabling real-time editing and AutoSave on labeled/encrypted Office files; changes the metadata format and location.
• Super-user — an Azure RMS capability granting specified identities the ability to decrypt/remove protection from any protected content tenant-wide (break-glass, eDiscovery); cannot decrypt DKE content.
• Activity Explorer — the Purview view that surfaces label events (Label applied/changed/removed/downgraded) and downgrade justifications; the audit trail and Insider Risk feed.

Next steps

You can now design, encrypt, automate, and roll out sensitivity labels without stranding data or breaking collaboration. Build outward:

• Next: Purview DLP across Endpoint, Exchange & SharePoint: Policy Authoring and Rollout — wire the labels you built into DLP as conditions and actions across every channel.
• Related: Microsoft Purview Retention Labels & Records Management: Disposition Review — the retention twin of sensitivity labels; classify for lifecycle, not just protection.
• Related: Purview eDiscovery (Premium): Legal Hold & Review Sets — scope holds by label and decrypt protected content for legal review (where super-user matters).
• Related: Purview Insider Risk Management: Policies & Forensic Evidence — turn label downgrades and exfiltration into scored, investigable signals.
• Related: SharePoint & OneDrive External Sharing Governance with Sensitivity Labels — the container and site-sharing side of label enforcement.
• Related: Teams Governance: Lifecycle, Naming, Expiration & Sensitivity Labels — container labels in the Teams lifecycle, end to end.
• Related: Email Authentication: SPF, DKIM & DMARC in Exchange Online — secure the mail channel your encrypted email travels over.