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

Both Microsoft Double Key Encryption (DKE) and Customer Key improve on default Microsoft-managed keys. They answer different questions about custody. This guide is a decision aid for security, compliance and cloud architects shortlisting a control model for regulated mail, files and collaboration data in Microsoft 365.

---

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. How DuoKey fits each path
6. Next step

What each model does

Customer Key (service encryption under your root keys)

Microsoft’s Customer Key feature lets you supply root encryption keys used for Microsoft 365 service encryption. You improve governance and can revoke access by controlling your key. Azure Key Vault still participates in cryptographic operations for derived data encryption keys.

Microsoft’s own documentation states that Microsoft does not have access to the root keys you maintain in Azure Key Vault, but can access data encryption keys derived from your keys. That is a stronger posture than provider-managed defaults, not the same as Microsoft never being able to decrypt protected content.

Double Key Encryption (DKE)

DKE encrypts selected content with two keys: Microsoft’s key and your external key. Both are required to decrypt. Microsoft never holds your external key. For highly sensitive labels and documents, that is the Microsoft model that keeps decryption authority outside Microsoft’s sole control.

DuoKey provides the external key service for DKE using HSM-backed Multi-Party Computation (MPC) with dual-control authorization, so no single party, including DuoKey, can use the key unilaterally.

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-operated root keys and clearer revocation than Microsoft-managed defaults
• Regulators or contracts ask for customer keys in Azure Key Vault, not necessarily dual-key content encryption
• The priority is service-level encryption and operational governance across M365, not per-document external unlock
• Legal and security agree that Azure Key Vault participation in derived-key operations meets your threat model

Customer Key is the right step when default encryption is insufficient and full DKE scope is not yet required.

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 demonstrate keys outside the Microsoft trust boundary for highly sensitive mail and files
• Sovereignty or extraterritorial access (for example CLOUD Act questions) is a named programme risk
• You need labelled protection that stays usable in M365 while custody stays independent

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

How DuoKey fits each path

Many programmes run both: Customer Key for broad service encryption posture, DKE for the highest-sensitivity labels.

Next step

1. Map which M365 datasets need independent unlock authority versus stronger Customer Key governance.
2. Shortlist a DKE provider with six operational criteria if DKE is in scope.
3. Review product pages for DKE and Customer Key, or talk to DuoKey about a scoped pilot.