Microsoft 365 Sensitivity Labels: An Architecture Note for Data Protection Across SharePoint and OneDrive
An architecture note for deploying Microsoft 365 Sensitivity Labels across SharePoint and OneDrive: minimal label schema, encryption scope, trust boundaries, operational checks, failure modes, and design-change triggers.
21 May 2026, 23:07 UTC

The Problem: Encryption Without Operational Overhead
Organizations adopt Microsoft 365 Sensitivity Labels to encrypt files and restrict access based on Azure AD identity. The typical failure isn't technical—it's operational. Teams create ten labels for every department, enable mandatory labeling everywhere, then watch users bypass protection by saving to personal OneDrive or emailing unencrypted copies. The architecture note below defines the smallest design that enforces encryption where it matters, keeps auditing practical, and avoids the "label fatigue" that causes shadow IT workarounds.
Requirements
- Data classification: Map business sensitivity tiers (Public, Internal, Confidential, Highly Confidential) to label names users recognize.
- Encryption scope: Apply rights management only to tiers that require it—typically Confidential and above. Public and Internal labels carry metadata only.
- Container mapping: Assign default labels to SharePoint sites and Teams channels so new content inherits protection without user action.
- Auditability: Record every label application, change, and removal in the Unified Audit Log for compliance evidence.
- Cross-tenant readiness: Design label GUIDs and names to survive future B2B collaboration or multi-geo expansion.
Smallest Suitable Design
1. Label Schema (Four Labels, Two Encrypted)
| Label Name | Tooltip | Encryption | Default Site Scope |
|---|---|---|---|
| Public | Share externally without restriction | None | External-facing sites |
| Internal | Org-wide view, no external sharing | None | Department sites |
| Confidential | Restricted to named groups | Azure AD group-based permissions | Project/Finance/HR sites |
| Highly Confidential | Named individuals only, no printing | User-level permissions + no copy/print | Legal/M&A/Executive sites |
Create labels in the Microsoft Purview compliance portal (compliance.microsoft.com > Information protection > Labels). Use the "Define encryption settings" wizard for Confidential and Highly Confidential. Assign Azure AD security groups (not individuals) to encryption roles—Viewer, Reviewer, Co-Author, Owner. This keeps permission changes in group membership, not label re-publishing.
2. Label Policy Publication
Publish a single policy to all users. Enable:
- Mandatory labeling only for Confidential and Highly Confidential (configured in label settings, not policy).
- Default label = Internal for all sites.
- Site default overrides: Set Confidential as default on Finance, HR, Legal site collections via PowerShell:
# Run in SharePoint Online Management Shell as SharePoint Admin
Connect-SPOService -Url https://contoso-admin.sharepoint.com
Set-SPOSite -Identity https://contoso.sharepoint.com/sites/finance \\
-DefaultSensitivityLabelId ""
This ensures new documents in Finance sites start encrypted. Users can upgrade to Highly Confidential but cannot downgrade below Confidential without justification (enforced by mandatory labeling).
3. Auto-Labeling (Optional, Phase 2)
Trainable classifiers or sensitive info types (SITs) can auto-apply Confidential when credit-card numbers or passport patterns appear. Deploy in simulation mode first—review matches in the Content explorer for 30 days before enabling enforcement. This prevents false positives from blocking legitimate work.
Trust and Data Boundaries
Tenant-Level Trust Boundary
Sensitivity labels and their encryption keys live in the Microsoft 365 tenant. All label evaluation, rights issuance, and audit logging occur inside this boundary. External users (B2B guests) receive rights only if their Azure AD identity is granted permissions in the label's encryption settings. Guests without an Azure AD account cannot decrypt Confidential or Highly Confidential files.
Encryption Key Hierarchy
- Microsoft-managed keys (default): Microsoft generates and rotates per-label keys. Simplest operations; suitable for most tenants.
- Customer-managed keys (CMK): Bring your own key (BYOK) stored in Azure Key Vault. Required when regulatory mandates demand key custody. Adds operational complexity—key rotation, access policies, and disaster recovery testing become your responsibility.
- Double Key Encryption (DKE): One key in Microsoft Cloud, one in your on-premises HSM. Highest assurance; only for classified or sovereign workloads. Not compatible with co-authoring or eDiscovery.
Decision rule: Start with Microsoft-managed keys. Move to CMK only when a compliance auditor produces a written requirement. DKE is a niche exception—document the business justification before investing.
Operational Checks
Daily: Unified Audit Log Queries
Run a scheduled KQL query in the Audit log search (or export to Log Analytics/Sentinel) to detect:
- Label downgrades (Confidential → Internal) without justification.
- Files labeled Highly Confidential shared via "Anyone with link".
- Auto-labeling false positives (label applied by system, then removed by user within 1 hour).
// Example KQL for AuditLogs table in Log Analytics
AuditLogs
| where OperationName in ("SensitivityLabelApplied", "SensitivityLabelRemoved", "SensitivityLabelChanged")
| extend Label = tostring(ExtendedProperties["SensitivityLabel"])
| extend PreviousLabel = tostring(ExtendedProperties["PreviousSensitivityLabel"])
| where Label == "Internal" and PreviousLabel == "Confidential"
| project TimeGenerated, UserId, SiteUrl, FileName, Label, PreviousLabel
Weekly: Label Coverage Report
Use the Purview Data Map > Information protection dashboard to verify:
- Percentage of files labeled in high-value sites (target > 95%).
- Unlabeled files in sites with mandatory labeling (should be zero).
- Top 10 users removing labels—investigate for training or policy gaps.
Quarterly: Permission Recertification
Review Azure AD group memberships used in Confidential/Highly Confidential encryption. Remove departed employees and expired project members. Automate with Entra ID access reviews scoped to the label-permission groups.
Failure Modes
1. Label Drift via Unsupported Storage
Files copied to USB, personal Google Drive, or non-M365 SaaS lose encryption metadata. The label persists in the file's custom properties, but the rights management service cannot enforce decryption outside the Microsoft 365 ecosystem. Mitigation: Conditional Access App Control (session policy) in Microsoft Defender for Cloud Apps blocks download of Highly Confidential files to unmanaged devices. For USB, deploy endpoint DLP (Microsoft Purview Endpoint DLP) with "Block copy to removable storage" for Highly Confidential.
2. Decryption Rights Loss
User leaves the Azure AD group granted Viewer rights on Confidential label. They retain the file but cannot open it. This is by design, but support tickets spike if not communicated. Mitigation: Document the "access follows group membership" model in onboarding. Provide a self-service portal (Power Automate + Graph) for users to request re-addition with manager approval.
3. Mandatory Labeling Blocks Creation
If a site has mandatory labeling set to Confidential, but the user's client (legacy Office 2016, mobile app without label support) cannot present the label picker, the save fails with a generic error.
Mitigation: Enforce minimum client versions via Conditional Access (require approved apps). Test with Get-LabelPolicy and Get-Label in Security & Compliance PowerShell to verify policy deployment.
4. Search Indexing Gaps
Encrypted files (Confidential+) are indexed only for users with decryption rights. Legacy on-premises search connectors (e.g., SharePoint Server 2019 hybrid) cannot index encrypted content. Mitigation: Accept this limitation for hybrid scenarios. Do not apply encryption to libraries crawled by legacy connectors.
Conditions That Change the Design
| Trigger | Design Change | Effort |
|---|---|---|
| Multi-tenant collaboration (B2B direct connect) | Synchronize label GUIDs and names across tenants via PowerShell; publish matching policies in each tenant. | Medium |
| Multi-Geo enablement | Labels replicate automatically; verify encryption key region aligns with data residency requirements (CMK per geo). | Low (Microsoft-managed) / High (CMK) |
| Regulatory mandate for key custody | Migrate from Microsoft-managed to CMK or DKE; test co-authoring and eDiscovery impact. | High |
| Merger/acquisition | Map acquired company's labels to your schema; use label migration tooling (Set-Label -Guid) to preserve history. | Medium |
| Copilot for Microsoft 365 rollout | Ensure labels are published to all users; Copilot respects label permissions but cannot auto-label—review auto-labeling rules for AI-generated content. | Low |
Verification Checklist (Run Before Broad Rollout)
- Create test user
[contact removed](no group memberships) and[contact removed](member of Finance-Viewers group). - As Finance-Viewers group owner, apply Confidential label to a Word doc in
https://contoso.sharepoint.com/sites/finance. - Open doc as
test-editor—verify edit rights. Open astest-viewer—verify access denied. - Download file as
test-editor, move to personal OneDrive—verify label persists and encryption remains. - Run audit query for
SensitivityLabelAppliedon the test file—confirm log entry appears within 30 minutes. - Attempt to open file on unmanaged iPhone (no Intune enrollment)—verify Conditional Access blocks download if session policy configured.
Rollback Considerations
Disabling a label policy (Set-LabelPolicy -Enabled $false) stops new labeling but leaves existing labels and encryption intact. To fully remove encryption, you must decrypt each file (requires Owner rights) or use the Remove-Label cmdlet in bulk via PnP PowerShell. Plan a 30-day coexistence window before deleting label definitions.
Summary
Start with four labels, encrypt only the top two, assign defaults at the site level, and audit via Unified Audit Log. Defer auto-labeling, CMK, and DKE until you have evidence they're required. The architecture scales to multi-geo and multi-tenant by keeping label GUIDs stable and permissions group-based. The operational burden stays low because the daily check is a single KQL query, not a manual spreadsheet review.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.