Microsoft 365 Enhanced Data Encryption (EDE) Guide

Microsoft 365 encrypts all customer data at rest and in transit by default. Enhanced Data Encryption (EDE) goes further — it gives enterprises control over the encryption keys themselves, enabling regulatory compliance, data sovereignty, and defense against insider threats at the platform level.

If your organization handles regulated data (financial, healthcare, government, EU personal data), EDE is not optional. Here is how it works and how to deploy it.

The Encryption Stack

Microsoft 365 uses a layered encryption architecture:

Layer 4: Double Key Encryption (DKE) — you hold both keys
Layer 3: Customer Key — you hold one key, Microsoft holds one
Layer 2: Service Encryption — Microsoft-managed per-tenant keys
Layer 1: BitLocker + TLS — disk encryption + transport encryption

Layer 1 (default): Every Microsoft 365 tenant gets BitLocker disk encryption on datacenter hardware and TLS 1.2+ for data in transit. No configuration needed.

Layer 2 (default): Service-level encryption with Microsoft-managed keys. Each tenant has unique keys, rotated automatically. This is what most organizations use today.

Layer 3 (Customer Key): You provide your own root encryption key via Azure Key Vault. Microsoft wraps service keys with your key. You can revoke access by revoking the key.

Layer 4 (Double Key Encryption): You hold both encryption keys. Microsoft cannot decrypt your data even with a court order, because they never have access to your key. Maximum sovereignty, but with usability trade-offs.

Customer Key: How It Works

Customer Key is the most practical EDE option for most enterprises. It provides cryptographic assurance that Microsoft cannot access your data without your key.

Architecture

Your Azure Key Vault          Microsoft Infrastructure
┌────────────────────┐        ┌─────────────────────┐
│  Root Key (RSA)    │───────▶│  Data Encryption    │
│  You control       │        │  Key (DEK)          │
│  You can revoke    │        │  Wraps tenant data  │
└────────────────────┘        └─────────────────────┘

Setup Steps

1. Prerequisites:

• Microsoft 365 E5 or E5 Compliance license
• Two Azure subscriptions (for key redundancy)
• Azure Key Vault Premium (HSM-backed keys)
• Global Admin + Compliance Admin roles

2. Create Azure Key Vaults:

# Create two Key Vaults in different Azure regions for redundancy
$vault1 = New-AzKeyVault -Name "m365-ede-primary" `
  -ResourceGroupName "m365-encryption" `
  -Location "West Europe" `
  -Sku Premium

$vault2 = New-AzKeyVault -Name "m365-ede-secondary" `
  -ResourceGroupName "m365-encryption" `
  -Location "North Europe" `
  -Sku Premium

3. Generate RSA Keys:

# Generate HSM-protected keys (cannot be exported)
Add-AzKeyVaultKey -VaultName "m365-ede-primary" `
  -Name "M365-CustomerKey-1" `
  -Destination HSM `
  -KeyType RSA `
  -Size 2048

Add-AzKeyVaultKey -VaultName "m365-ede-secondary" `
  -Name "M365-CustomerKey-2" `
  -Destination HSM `
  -KeyType RSA `
  -Size 2048

4. Grant Microsoft 365 Access:

# Grant M365 service principal access to wrap/unwrap keys
Set-AzKeyVaultAccessPolicy -VaultName "m365-ede-primary" `
  -ServicePrincipalName "c066d759-24ae-40e7-a56f-027002b5d3e5" `
  -PermissionsToKeys wrapKey,unwrapKey,get

5. Register Keys with Microsoft 365:

# Connect to Exchange Online
Connect-ExchangeOnline

# Create Data Encryption Policy
New-DataEncryptionPolicy -Name "EU-Data-Protection" `
  -AzureKeyIDs "https://m365-ede-primary.vault.azure.net/keys/M365-CustomerKey-1", `
               "https://m365-ede-secondary.vault.azure.net/keys/M365-CustomerKey-2" `
  -Description "Customer Key for EU regulated data"

6. Assign to Mailboxes:

# Assign policy to specific mailboxes
Set-Mailbox -Identity "ceo@contoso.com" `
  -DataEncryptionPolicy "EU-Data-Protection"

# Or assign to all mailboxes in a group
Get-Mailbox -Filter "Department -eq 'Legal'" |
  Set-Mailbox -DataEncryptionPolicy "EU-Data-Protection"

Services Covered by Customer Key

Double Key Encryption (DKE)

DKE is the maximum security option. You host one of the two encryption keys on your own infrastructure. Microsoft never sees it.

When to Use DKE

• Regulatory requirement that cloud provider must not have key access
• Government classified data
• Trade secrets and IP that require sovereign encryption
• EU data sovereignty requirements under GDPR Article 32

Architecture

Your Infrastructure            Microsoft Cloud
┌──────────────────┐          ┌──────────────────┐
│  DKE Key Service │          │  Microsoft Key   │
│  (your server)   │          │  (Azure-managed) │
│                  │          │                  │
│  Key 1 (yours)   │          │  Key 2 (theirs)  │
└────────┬─────────┘          └────────┬─────────┘
         │                             │
         └──────────┬──────────────────┘
                    │
              Both keys required
              to decrypt content

Trade-offs

Pros:

• Microsoft cannot access your data under any circumstance
• Meets strictest regulatory requirements
• Full key lifecycle control

Cons:

• You are responsible for key availability (if your key service goes down, users cannot access documents)
• Limited to sensitivity label-protected content (not tenant-wide)
• Some features reduced (search, eDiscovery limited for DKE content)
• Copilot cannot process DKE-encrypted content (no Graph grounding)

Sensitivity Labels and Encryption

EDE works alongside Microsoft Purview sensitivity labels to apply encryption based on content classification:

Classification        Encryption Level       Use Case
─────────────────────────────────────────────────────────
Public                Service Encryption      Marketing materials
Internal              Service Encryption      Internal comms
Confidential          Customer Key            Financial data, PII
Highly Confidential   Double Key Encryption   Board materials, M&A

Label Configuration

# Create a sensitivity label with Customer Key encryption
New-Label -Name "Confidential - Customer Key" `
  -DisplayName "Confidential" `
  -Tooltip "Encrypted with company-controlled keys" `
  -EncryptionEnabled $true `
  -EncryptionProtectionType Template `
  -EncryptionDoNotForward $false `
  -EncryptionEncryptOnly $false

Key Management Best Practices

Rotation

# Rotate Customer Key (recommended: annually)
# Generate new key version in Azure Key Vault
$newKey = Add-AzKeyVaultKey -VaultName "m365-ede-primary" `
  -Name "M365-CustomerKey-1" `
  -Destination HSM

# Microsoft automatically re-wraps DEKs with new key version
# Old key versions must remain accessible for existing data

Monitoring

# Monitor key usage in Azure Monitor
# Set alerts for:
# - Key access failures (availability issue)
# - Unusual key access patterns (security issue)
# - Key expiration warnings (operational issue)

# Azure Key Vault diagnostic settings
Set-AzDiagnosticSetting -ResourceId $vault1.ResourceId `
  -WorkspaceId $logAnalyticsId `
  -Enabled $true `
  -Category AuditEvent

Emergency Revocation

If you need to cut Microsoft’s access to your data immediately:

# CAUTION: This makes all Customer Key encrypted data inaccessible
# Only use in genuine emergency (breach, court order, exit)

# Remove Microsoft's access to the key
Remove-AzKeyVaultAccessPolicy -VaultName "m365-ede-primary" `
  -ServicePrincipalName "c066d759-24ae-40e7-a56f-027002b5d3e5"

# Data becomes inaccessible within minutes
# To restore: re-grant access policy

EDE and Microsoft Copilot

Important interaction between EDE and Copilot:

• Customer Key + Copilot: Works fully. Copilot can process Customer Key encrypted data because Microsoft holds one key (wrapped by yours) and can decrypt during processing
• DKE + Copilot: Does NOT work. Copilot cannot process DKE content because it cannot access your key. DKE documents are excluded from Copilot grounding

This creates a strategic decision: maximum encryption (DKE) or maximum AI capability (Copilot). Most enterprises use Customer Key for the majority of data and reserve DKE for the most sensitive subset.

Compliance Mapping

Deployment Roadmap

Phase 1: Assessment (2 weeks)

• Identify regulated data types and applicable requirements
• Map data locations across Exchange, SharePoint, OneDrive, Teams
• Determine Customer Key vs DKE requirements per data classification
• Estimate Azure Key Vault costs

Phase 2: Infrastructure (2 weeks)

• Provision Azure Key Vault Premium in two regions
• Generate and secure HSM-backed keys
• Configure access policies and monitoring
• Test key availability and failover

Phase 3: Pilot (4 weeks)

• Apply Customer Key to executive mailboxes and sensitive SharePoint sites
• Test DKE on a small set of highly classified documents
• Validate Copilot functionality with Customer Key
• Verify eDiscovery and compliance search work correctly

Phase 4: Rollout (4-8 weeks)

• Deploy sensitivity labels with encryption policies
• Apply Customer Key to all regulated data
• Train users on sensitivity label selection
• Establish key rotation and monitoring cadence

Related Resources

• Microsoft Copilot Enterprise Guide
• EU Cyber Resilience Act
• Zero Trust Architecture
• DevSecOps Pipeline
• SSL/TLS Certificate Management

About the Author

I am Luca Berton, AI and Cloud Advisor. I help enterprises implement data encryption and compliance strategies across cloud platforms. Book a consultation to discuss your M365 encryption architecture.