DKE vs Microsoft 365 Customer Key: Which Control Model Do You Need?

Customer Key and Double Key Encryption (DKE) both put a customer key into Microsoft 365, but at different layers. Customer Key encrypts whole workloads at rest under root keys you control, and Microsoft 365 still decrypts that data to run its services. DKE protects selected labelled items with a second key that stays outside Microsoft, so Microsoft cannot open them alone.

This page is the decision aid between the two. For each model on its own, read what Double Key Encryption is and how Microsoft Purview Customer Key works.

---

Table of Contents

1. What each model does
2. Side-by-side comparison
3. When Customer Key is enough
4. When you need DKE
5. Using both
6. How DuoKey fits
7. FAQ

What each model does

Customer Key (service encryption under your root keys)

Customer Key lets you control the root keys Microsoft 365 uses for service encryption of Exchange, SharePoint, OneDrive, Teams, Copilot interactions and Windows 365 Cloud PCs. The keys live in Azure Key Vault or Managed HSM, in two Azure subscriptions you own. Microsoft states that you "explicitly authorize Microsoft 365 to use your encryption keys" for eDiscovery, anti-malware, anti-spam and search indexing, and each data encryption policy also uses an availability key Microsoft protects. (Microsoft Learn: Customer Key overview)

That is BYOK: a stronger governance and exit posture than Microsoft-managed keys, not a guarantee that Microsoft cannot decrypt. For the general model, see what BYOK (bring your own key) means.

Double Key Encryption (DKE)

DKE encrypts selected content with two keys: Microsoft's key and your external key. Both are required to decrypt, and Microsoft never holds your external key. It is applied through a sensitivity label, for the small share of content that must stay outside Microsoft's read path. (Microsoft Learn: Double Key Encryption)

DKE: two independent keys are required. Microsoft's infrastructure never holds the external key.

Side-by-side comparison

Default Microsoft-managed keys sit below both options: data is encrypted, Microsoft holds the keys.

When Customer Key is enough

Choose Customer Key when:

• Your programme needs customer-controlled root keys and a documented exit path, compared with Microsoft-managed defaults
• Regulators or contracts ask for customer keys in Azure Key Vault, not for content Microsoft cannot read
• The priority is service-level encryption across Microsoft 365 with no change to user features
• Legal and security agree that Microsoft 365 services decrypting data in normal operation fits your threat model

When you need DKE

Choose DKE when:

• Supervisors, public-sector guidance or board risk appetite require that Microsoft cannot decrypt selected content alone
• You must show that a decisive key sits outside the Microsoft trust boundary for highly sensitive mail and files
• Requests addressed to the provider, for example under the US CLOUD Act, are a named programme risk
• The affected users can work without web co-authoring, search and Copilot on that content

DKE is not a blanket replacement for every mailbox. It is the control for content that must remain under an external unlock authority.

Using both

The two models are not exclusive. A common pattern is Customer Key across the tenant for governance and exit, and DKE on one or two labels for M&A files, legal privilege, regulated personal data or trade secrets. Users keep full Microsoft 365 features on everything except the labelled slice. For the general logic of choosing per data class, see BYOK vs HYOK.

How DuoKey fits

If DKE is in scope, shortlist providers with six operational criteria and follow the DKE setup guide for a pilot.

FAQ

What is the difference between DKE and Customer Key?

Customer Key encrypts Microsoft 365 workloads at rest under root keys you control in Azure, and Microsoft 365 still decrypts the data to run its services. DKE protects selected labelled items with a second key outside Microsoft, so Microsoft cannot open them alone.

Is Customer Key HYOK?

No. It is BYOK for service encryption. The keys sit in Azure Key Vault or Managed HSM and Microsoft 365 uses them. DKE is the Microsoft 365 option that follows the hold-your-own-key model.

Can I use DKE and Customer Key together?

Yes. They work at different layers. Many programmes use Customer Key for the tenant and DKE for a small set of labels.

Does Copilot work with DKE or Customer Key?

Copilot keeps working on data protected by Customer Key; Copilot interactions are even one of the workloads a multi-workload policy can encrypt. Microsoft lists Copilot among the features that do not work on DKE-protected items.

Which one do regulators ask for?

It depends on the requirement. If the requirement is customer-controlled keys and an exit path, Customer Key can meet it. If the requirement is that the provider cannot decrypt a class of content on its own, only DKE meets it in Microsoft 365. Whether a model satisfies a specific rule is a question for your counsel.