Microsoft Sensitivity Labels Licensing: Complete E3 vs E5 Guide

Sensitivity label deployments fail in two predictable ways: organisations either stop at manual labelling (available at E3) and never achieve the coverage needed for meaningful data governance, or they licence E5 for service-side auto-labelling without deploying it — creating a $540/user/year expense with zero additional protection. The licensing decision for sensitivity labels is not binary between E3 and E5; it is a function of your data volume, classification accuracy requirements, and whether Copilot for Microsoft 365 is in scope. With 92% of enterprise data breaches involving files that were never classified, the auto-labelling question has become a board-level risk discussion — not just a compliance programme detail.

Sensitivity Label Licensing Matrix

Client-Side vs Service-Side Auto-Labelling: The Critical Difference

Understanding the architectural distinction between client-side and service-side auto-labelling is the most important decision point in sensitivity label licensing.

Client-Side Auto-Labelling (E3)

Client-side auto-labelling runs within the Office application (Word, Excel, PowerPoint, Outlook) as a user interacts with a document. The label is evaluated when the document is opened or created. It requires the user to have the Office application open — it does not classify content that already exists in SharePoint or Exchange without user interaction. For new content workflows where users are actively creating files, client-side labelling achieves reasonable coverage. For existing data estates with millions of unclassified documents, it achieves virtually nothing — a user must open each document to trigger classification.

Service-Side Auto-Labelling (E5 / E5 Compliance)

Service-side auto-labelling is a background process that scans all content at rest in Exchange Online, SharePoint Online, and OneDrive for Business — regardless of whether a user has opened the file. A simulation mode allows you to preview which items would be labelled before enabling auto-apply. For an organisation with a 10-million-document SharePoint estate accumulated over 10 years, service-side auto-labelling is the only mechanism capable of retroactively classifying existing content at scale. A typical initial scan of a 10-million-document estate takes 3–5 days; re-scanning for new content runs continuously.

Container Labels: Teams, Groups, and Sites

Container labels apply to Microsoft 365 Groups, SharePoint sites, and Teams — configuring privacy settings, external sharing, guest access, and device access policies at the container level rather than the individual document level. They represent the practical way to enforce data governance at the collaboration workspace level.

Azure Active Directory P1 (now Entra ID P1) is included with Microsoft 365 E3 — so container label deployment is fully covered at E3 without additional licences. The E5-only capability is document inheritance from site labels, where documents uploaded to a labelled SharePoint site automatically inherit the site's sensitivity label.

AIP Scanner: On-Premises Auto-Labelling

The Azure Information Protection (AIP) Unified Labelling Scanner — now the Microsoft Purview Information Protection Scanner — extends service-side auto-labelling to on-premises file repositories: Windows file servers, SharePoint Server (on-premises), and network-attached storage. It requires E5 or E5 Compliance add-on and a separate Windows Server running the scanner service.

Deployment reality: the scanner must be configured with a service account, a SQL Server instance for its database, and network access to every repository being scanned. For a 50-million-file repository, initial discovery scans take 2–4 weeks. Ongoing delta scans process new and modified files continuously. For organisations with significant on-premises data estates alongside Microsoft 365 — typical of manufacturing, healthcare, and government — the AIP scanner is often the primary justification for E5 Compliance add-on licensing, as it is the only mechanism for unified classification across hybrid environments.

Double Key Encryption: When to Deploy It

Double Key Encryption (DKE) requires two keys to decrypt content: Microsoft's key (held in Azure) and the customer's key (held on customer-controlled infrastructure). Because both keys are required simultaneously, Microsoft itself cannot decrypt DKE-protected content without the customer's cooperation. This eliminates the residual trust risk in standard Microsoft-managed encryption where, theoretically, a Microsoft insider or a government compelled access order could access content.

DKE has legitimate use cases in three scenarios: regulated content subject to export control (ITAR/EAR classified technical data), sovereign government content where foreign cloud access is prohibited by law, and financial transaction data subject to strict client confidentiality in jurisdictions with aggressive government disclosure laws. For commercial enterprises without these specific requirements, DKE's operational overhead — files can only be opened by users with network access to the customer's key service — typically outweighs the incremental security benefit over standard Microsoft-managed encryption.

Label Taxonomy: Design Principles That Affect Licensing Cost

How you design your sensitivity label taxonomy directly affects how much E5 capability you need. A well-designed taxonomy maximises E3 coverage and minimises E5 requirements. The principles that matter for licensing:

Fewer top-level labels, more sub-labels: Microsoft supports up to 5 top-level labels and 5 sub-labels per parent — 25 total. Organisations that design simple, mandatory taxonomies (Public / Internal / Confidential / Highly Confidential with business unit sub-labels) achieve higher user adoption and require fewer auto-labelling policies, reducing E5 service-side scan complexity.

Mandatory labelling with default labels: Setting a default label (typically "Internal / General") and enabling mandatory labelling (users must apply a label before saving) captures new content at E3 without requiring auto-labelling. Studies show mandatory labelling with defaults achieves 85–92% label coverage for new content within 90 days. This significantly reduces the unclassified content that requires expensive service-side auto-labelling to retrofit.

SIT-based auto-classification at E3: Keyword and Sensitive Information Type auto-labelling — available at E3 — can achieve 60–75% automatic classification for structured sensitive data (credit card numbers, SSNs, NHS numbers, IBAN codes). The remaining 25–40% of unstructured business content (executive presentations, contracts, financial models) requires trainable classifiers — the E5 capability.

Frequently Asked Questions

What licence do I need for sensitivity labels?

Manual sensitivity labels are available with Microsoft 365 E3. Automatic labelling using Sensitive Information Types requires E3. Automatic labelling using trainable classifiers, service-side auto-labelling for content at rest, and Double Key Encryption require E5 or E5 Compliance add-on.

What is service-side vs client-side auto-labelling?

Client-side auto-labelling runs in Office apps when a user opens a document (E3). Service-side auto-labelling scans all existing content at rest in Exchange, SharePoint, and OneDrive without user interaction — retroactively classifying the entire data estate (E5/E5 Compliance only).

Do sensitivity labels work in Teams?

Yes. Sensitivity labels can be applied to Teams as container labels controlling guest access, external sharing, and device access policies. Container labels for Teams, SharePoint sites, and Microsoft 365 Groups require Microsoft 365 E3 and Azure AD P1 (included in E3).

What is Double Key Encryption (DKE)?

DKE uses two keys to protect content — one held by Microsoft (in Azure) and one held by the customer. Even Microsoft cannot decrypt DKE-protected content. DKE requires E5 or E5 Compliance and is designed for highly regulated content where cloud service provider access must be eliminated.

Can sensitivity labels extend to non-Microsoft apps?

Yes, via MDCA integration. When a sensitivity label is applied to a file, MDCA can enforce the label's protection settings in connected third-party SaaS apps. This requires E5 or E5 Security for full MDCA. The E5 Compliance add-on provides MDCA DLP enforcement but not full MDCA session control.

Are sensitivity labels required for Microsoft Copilot data protection?

Microsoft strongly recommends sensitivity label deployment before Copilot for Microsoft 365 rollout. Copilot respects sensitivity label access controls — a user cannot use Copilot to summarise a document labelled at a higher classification than they have access to. Without labels, Copilot may surface content from documents users should not be accessing.