Microsoft Purview gives you several kinds of encryption, and they solve different problems: some protect data at rest in Microsoft's datacenters, others travel with a document or email wherever it goes. In this post I'll compare Azure Rights Management (with Microsoft-managed keys or BYOK), Double Key Encryption, Customer Key and Message Encryption: what each protects, how each works with labels, what each means for eDiscovery and Copilot, and the operational cost.
How it works: two layers of encryption#
- At rest in the service. Microsoft 365 always encrypts data at rest with BitLocker and Distributed Key Manager (DKM). Customer Key adds an application-level layer whose root keys you control. Users never see this layer, and anyone who has access to an item can still read it.
- On the content itself. The Azure Rights Management service encrypts the individual file or email and attaches usage rights such as view, edit, copy, print or forward. The protection stays with the item when it's downloaded, emailed or copied to a USB drive. Sensitivity labels and Message Encryption both use it; Double Key Encryption (DKE) adds a second key that you hold.
- In transit. TLS protects traffic between clients and servers and between servers.
The options side by side#
| Option | Protects | Who holds the key | What users notice | Typical use |
|---|---|---|---|---|
| Service encryption (BitLocker, DKM) | All data at rest | Microsoft | Nothing | Baseline for every tenant |
| Customer Key | Data at rest in Exchange, SharePoint, OneDrive, Teams and Windows 365 Cloud PCs, among others | You (root keys) plus an availability key Microsoft protects | Nothing | Control of root keys at rest, with a purge path |
| Azure Rights Management | Individual files and emails, wherever they go | Microsoft-managed tenant key by default | Restricted actions, sign-in to open | Labeled confidential content |
| Azure Rights Management with BYOK | Same as above | A tenant key you create and manage in Azure Key Vault | Same as above | A requirement to own the root key |
| Double Key Encryption | The most sensitive files and emails | Two keys: one in Azure, one in a DKE service you host | Desktop apps only, no coauthoring | A small top-secret slice of data |
| Message Encryption | Email, including to external recipients | Uses the Azure Rights Management service | Encrypt or Do Not Forward options | Secure email to anyone |
How each option works with sensitivity labels#
Azure Rights Management and BYOK#
A label applies encryption with permissions you define, or lets users assign them. With a Microsoft-managed key or BYOK, labels work the same and Microsoft 365 services keep working with the content, which is why Microsoft recommends these for most sensitive data.
Double Key Encryption#
DKE is also applied through sensitivity labels once you deploy the DKE service and keys. It comes with Microsoft 365 E5 and needs the Azure Rights Management service. Users apply it in Word, Excel, PowerPoint and Outlook (Microsoft 365 Apps for enterprise on Windows), or with the Purview file labeler, PowerShell or scanner. The limits are substantial:
- Coauthoring and AutoSave are turned off for DKE-encrypted Office documents.
- SharePoint and OneDrive can store DKE files but can't process them: no Office for the web, coauthoring, search, eDiscovery or DLP for those files. A DKE label can't be a library's default label.
- DKE labels can't protect Loop components, calendar items, Teams meetings or chat.
- Encrypt-Only and Do Not Forward aren't supported with DKE in Outlook.
Customer Key#
Customer Key isn't a label setting. You create data encryption policies (DEPs) with PowerShell and assign them: a multi-workload DEP for the tenant (it also covers Microsoft 365 Copilot interactions, exact data match data and sensitivity label configurations), mailbox DEPs (up to 50 active per tenant) and one SharePoint and OneDrive DEP per geo. It only covers cloud data, so on-premises mailboxes and files need their own protection.
Message Encryption#
Message Encryption runs on the Azure Rights Management service and is applied through Outlook's encryption options, mail flow rules or labels for email. For fixes, see Message Encryption not working in Exchange Online.
What each option means for eDiscovery and Copilot#
- Rights Management content in eDiscovery. eDiscovery decrypts protected email and encrypted attachments sent in Exchange Online when you export. With premium eDiscovery features, encrypted documents in SharePoint and OneDrive can also be searched, previewed, reviewed in a review set and exported decrypted. Decryption in eDiscovery lists the exceptions, such as S/MIME and legacy library RMS settings.
- DKE content in eDiscovery. Because Microsoft holds only one key, DKE content is out of reach for eDiscovery, search and indexing, and for mail flow rules that inspect attachments.
- Customer Key and services. You explicitly authorize Microsoft 365 to use your keys for services such as eDiscovery, anti-malware, anti-spam and search indexing, so those keep working. Revoking your keys starts the data purge path and ends in cryptographic deletion, which is meant for leaving the service, not for daily access control.
- Copilot and Rights Management. Copilot only uses content the signed-in user can access, and for encrypted content the user needs both the VIEW and EXTRACT usage rights. A label that grants read-only permissions without the EXTRACT (copy) usage right keeps that content out of Copilot for those users. See how Copilot works with sensitivity labels and encryption.
- Copilot and DKE. DKE-encrypted data isn't accessible to Microsoft 365 services, including Copilot, and Copilot can't be used in an app while DKE-encrypted data is open there. In older Office versions, data in use could reach connected services unless the related privacy setting was turned off, so keep apps current.
Step-by-step: choosing the right mix#
- Label and encrypt confidential content with Azure Rights Management, scoped to groups. Enable sensitivity labels for Office files in SharePoint and OneDrive so search, eDiscovery and coauthoring keep working; see sensitivity labels in SharePoint and OneDrive.
- Use Message Encryption for external email instead of password-protected attachments.
- Choose BYOK only for a clear requirement to own the Rights Management root key. You take on Azure Key Vault operations, while users and services see no difference.
- Reserve DKE for the crown jewels. Viewing needs both keys, so the DKE service becomes a business-critical dependency that you run, monitor and keep available. Limit DKE labels to the few people who need them.
- Add Customer Key when regulation asks for control of root keys at rest. Check its licensing and setup prerequisites with Microsoft first.
Verify#
# Azure Rights Management (AIPService module, Windows PowerShell 5.1)
Connect-AipService
Get-AipService # should return Enabled
Get-AipServiceKeys # lists your tenant key(s)
# Exchange Online: IRM and Message Encryption
Connect-ExchangeOnline
Get-IRMConfiguration | Format-List AzureRMSLicensingEnabled
Test-IRMConfiguration -Sender admin@contoso.com -Recipient user@contoso.com
# Customer Key, if you've deployed it
Get-DataEncryptionPolicy
Get-M365DataAtRestEncryptionPolicyThen test like a user. With labels enabled for SharePoint and OneDrive, a labeled, encrypted document opens in Office for the web and appears in search results; a DKE-labeled document opens only in the supported Windows desktop apps or the Microsoft Purview Information Protection Viewer. Run a test eDiscovery search and confirm that Rights Management content exports readable. Audit records Copilot prompts, responses and the content they referenced, so you can check which files Copilot used; see searching the audit log.
Tips & gotchas#
- Customer Key doesn't stop an over-permissioned user, or Copilot acting for that user, from reading content. Permissions and labels do that.
- Permission problems with encrypted files are covered in can't open a file protected by a sensitivity label; Copilot controls are in Purview DLP for Microsoft 365 Copilot.
