Microsoft Purview Customer Key: BYOK for Microsoft 365 Explained

Microsoft Purview Customer Key is Microsoft's service encryption with customer-controlled root keys. You create or import RSA keys in Azure Key Vault or Managed HSM, and Microsoft 365 uses them, together with an availability key Microsoft protects, to encrypt Exchange, SharePoint, OneDrive, Teams and Windows 365 Cloud PC data at rest. Microsoft 365 services still decrypt that data in normal operation. (Microsoft Learn: Customer Key overview)

People search for it under several names: Microsoft Purview Customer Key, Microsoft 365 Customer Key, Office 365 Customer Key, service encryption with Customer Key, and Microsoft 365 BYOK. They mean the same feature. It is not Double Key Encryption.

This page explains Customer Key itself. The decision between the two Microsoft models is in DKE vs Microsoft 365 Customer Key.

---

Table of Contents

1. What Customer Key adds
2. BYOK in Microsoft 365: three different things
3. Which workloads a data encryption policy covers
4. What you need before you start
5. Who can decrypt in normal operation
6. What revocation does
7. Customer Key and Double Key Encryption
8. Where DuoKey fits today
9. FAQ

---

What Customer Key adds

Microsoft 365 already encrypts data at rest with BitLocker and Distributed Key Manager. Windows 365 Enterprise and Business Cloud PC disks use Azure Storage server-side encryption. Customer Key sits on top, at the application layer.

Microsoft's description of the control is specific: it lets you control the root encryption keys at the application level, and you explicitly authorise Microsoft 365 to use those keys for eDiscovery, anti-malware, anti-spam, search indexing and similar services. (Microsoft Learn: Customer Key overview)

Two boundaries follow from that page:

• Customer Key encrypts data at rest in the cloud. It does not protect on-premises mailboxes or files.
• The encryption hierarchy uses keys you manage and an availability key that Microsoft protects.

---

BYOK in Microsoft 365: three different things

"BYOK Microsoft 365" is used for three Microsoft features. They protect different layers, so it helps to name the one you mean.

Microsoft documents the second option as an alternative to the Microsoft-generated tenant key: BYOK keys "are created by customers, either in the Azure Key Vault or on-premises", then transferred to Azure Key Vault. For highly sensitive content, the same page recommends DKE. (Microsoft Learn: Managing the Azure Rights Management root key)

The first two are BYOK: you control the key's lifecycle, and Microsoft's services use it. The third is the hold-your-own-key model. For the general definition, see what BYOK is and how it works. For the difference in custody, see BYOK vs HYOK.

---

Which workloads a data encryption policy covers

A data encryption policy (DEP) is the object you create, with PowerShell, and assign. Microsoft documents three kinds. (Microsoft Learn: Customer Key overview)

SharePoint and OneDrive are not covered by the multi-workload DEP. They need the SharePoint DEP. Teams files saved into SharePoint follow that SharePoint policy. Teams Live Events, Viva Engage and Planner are outside these DEPs.

For Exchange, assigning a DEP rewraps existing encrypted mailboxes on next access. Under a multi-workload DEP, Microsoft states that Exchange data is encrypted for existing and new data, while EDM and Teams data is encrypted from the assignment onward. Read the workload note before you tell an auditor the history is covered.

---

What you need before you start

Microsoft's setup article lists the prerequisites. The ones that shape the project: (Microsoft Learn: Set up Customer Key)

• Licensing. Eligible licences are listed in the Microsoft Purview service description. Each mailbox must meet the licensing requirement.
• Two paid Azure subscriptions. Each DEP uses two keys, one per subscription. Microsoft recommends that different people manage each key.
• Key Vault or Managed HSM. With Azure Key Vault, one vault per workload in each subscription: up to six vaults for multi-workload, Exchange and SharePoint. Microsoft recommends the Premium SKU and HSM-protected keys for production. With Managed HSM, two instances in total.
• Soft delete and purge protection, with a 90-day retention period, set when the vault is created.
• RSA keys up to 4,096 bits, with no expiration date. Keys can be created in the vault or generated on-premises and imported through the Azure Key Vault BYOK process.
• Onboarding through the Customer Key Onboarding Service in PowerShell, which validates the setup before it enables the workload. SharePoint and OneDrive onboard separately.

Microsoft's own warning belongs in the project plan: mistakes with these keys can cause service interruptions or permanent data loss.

---

Who can decrypt in normal operation

This is the point that gets overstated.

Customer Key is BYOK for service encryption. Microsoft 365 services decrypt content during normal operation, which is why search, eDiscovery and the rest keep working. Each DEP includes an availability key Microsoft protects. Your root keys improve governance and give you a revocation path. They do not remove Microsoft from the decryption path while the service is running. (Microsoft Learn: Customer Key overview)

If the requirement is that Microsoft cannot read a document on its own, the Microsoft feature for that is Double Key Encryption (DKE), applied through a sensitivity label. Customer Key will not meet that test.

---

What revocation does

Microsoft documents the exit in one sentence: revoking access to your keys triggers deletion of the availability key, which results in cryptographic deletion of your data. You can also ask Microsoft to purge specific DEPs when you leave the service. (Microsoft Learn: Customer Key overview)

That is a leave-the-service control. It is not a per-document deny. Plan for it as a purge, with the availability consequences Microsoft describes, and test it only on a scope you can afford to lose.

---

Customer Key and Double Key Encryption

Many programmes use both: Customer Key across the tenant, DKE on the labels that must stay unreadable to Microsoft. The full decision, with criteria for each, is DKE vs Microsoft 365 Customer Key.

---

Where DuoKey fits today

DuoKey covers both Microsoft 365 options:

• Customer Key. DuoKey for Microsoft 365 Customer Key generates the root keys under MPC custody and imports them into Azure Key Vault or Managed HSM through the documented BYOK process. You keep an independent copy, the key lifecycle and the revocation decision. As with any Customer Key setup, Microsoft 365 uses the imported keys to process your content.
• Double Key Encryption. For the content Microsoft must not read on its own, the DKE key stays in a DuoKey MPC vault, the DKE endpoint is deployed from DuoKey Cockpit and a Zero Trust policy applies to every unwrap. See DuoKey for Microsoft 365 DKE and the DKE setup guide.

---

FAQ

What is Microsoft Purview Customer Key?

It is Microsoft's service encryption with customer-controlled root keys. Microsoft 365 uses your keys, together with an availability key Microsoft protects, to encrypt Exchange, SharePoint, OneDrive, Teams, Copilot interactions and Windows 365 Cloud PC data at rest.

Is Office 365 Customer Key the same as Microsoft 365 Customer Key?

Yes. Current Microsoft documentation uses Microsoft Purview Customer Key and "service encryption with Customer Key" for the same feature. Older pages still say Office 365.

Is Customer Key the same as BYOK for Microsoft 365?

It is the main BYOK option for Microsoft 365 service encryption. Microsoft also offers BYOK for the Azure Rights Management root key behind Purview Information Protection. In both, Microsoft 365 services use your key. Double Key Encryption is the option where Microsoft cannot decrypt alone. (HYOK guide)

Can Microsoft still read my data with Customer Key?

Microsoft 365 services decrypt content in normal operation for the services you authorise, such as search, eDiscovery, anti-malware and anti-spam. Customer Key gives you lifecycle control and a revocation path that ends in cryptographic deletion. It does not stop the running service from reading the data.

Where do Customer Key keys have to live?

In Azure Key Vault (Premium SKU recommended for production) or Azure Key Vault Managed HSM, in two Azure subscriptions. You can generate the keys on-premises and import them, but the keys Customer Key uses are held in Azure.

Does Customer Key cover on-premises Exchange?

No. Microsoft states that Customer Key encrypts only data at rest in the cloud.