Customer Key for Microsoft 365

Customer Key is the Microsoft 365 capability that lets a customer provide and manage the root encryption keys used to encrypt their tenant data at rest. Microsoft uses your keys to encrypt content; you control whether Microsoft can decrypt it. It's the strongest form of customer-controlled encryption in Microsoft 365.

BYOK, HYOK, and where Customer Key fits

If you arrived here searching for "BYOK", you're in the right place. Bring Your Own Key (BYOK) is the general encryption model where the customer supplies the root key a cloud service uses, instead of the provider generating and holding keys itself. Customer Key is Microsoft 365's implementation of BYOK for service encryption: your keys live in Azure Key Vault in your own subscription, and Microsoft's services use them without ever owning them.

Two related terms cause most of the confusion in this conversation:

• HYOK (Hold Your Own Key) was the stricter variant where keys never left the customer's on-premises HSM. Microsoft deprecated HYOK for information protection years ago — it broke co-authoring, search, and eDiscovery because the cloud genuinely couldn't read the content. If a requirements document still says "HYOK", it's usually copied from an old template; ask what regulation actually demands, because the answer is almost always satisfied by Key Vault-based BYOK.
• Double Key Encryption (DKE) is the modern successor for the tiny slice of content where Microsoft must mathematically never be able to decrypt — it uses one Microsoft key plus one key you host, and it carries the same functional sacrifices HYOK did. It's a per-document sensitivity-label feature, not a tenant-wide layer.

So the working hierarchy is: default service encryption (Microsoft's keys, everyone has it) → Customer Key (BYOK — your root keys wrap the service encryption) → DKE (Microsoft locked out entirely, for exceptional content only). When a client asks for "BYOK for Microsoft 365", Customer Key is the product name to put in the design.

What Customer Key encrypts

Customer Key applies to data at rest in:

• Exchange Online mailboxes.
• SharePoint Online sites.
• OneDrive for Business.
• Microsoft Teams files (stored in SharePoint).
• Microsoft 365 Copilot content (when Copilot is in scope).

It's a service-level encryption layer on top of Microsoft's default storage encryption. Default storage encryption uses Microsoft-managed keys; Customer Key adds a customer-managed key as a wrapper.

The architecture

Customer Key works with Azure Key Vault in the customer's own Azure subscription:

1. Customer creates two RSA keys in two separate Azure Key Vaults (in two regions, for resilience).
2. Customer grants permissions to Microsoft's specific service principal to wrap/unwrap with those keys.
3. Customer creates a data encryption policy (DEP) in the Microsoft 365 admin center referencing those keys.
4. Microsoft applies the DEP to relevant mailboxes / sites / OneDrives.
5. Microsoft encrypts the data using a chain that ends at the customer's keys in Azure Key Vault. Without the customer's keys, the data cannot be decrypted.

What this gives you

• Cryptographic control — Microsoft cannot decrypt the data without the customer's permission.
• Data destruction by key revocation — revoke the keys, the data is rendered unrecoverable (the legal "data destruction" scenario).
• Compliance evidence — auditable proof of customer-controlled encryption.

Important caveats

Customer Key is sometimes mis-positioned. It's important to understand:

• It doesn't prevent Microsoft from accessing data during normal operation. Microsoft engineers still need to perform support and operations; Customer Lockbox controls that access, not Customer Key.
• Sensitivity-label encryption is different — it encrypts specific labelled files end-to-end, including in transit and at recipient devices. Customer Key is about underlying storage encryption.
• It doesn't replace TDE, sensitivity labels, or DLP — it complements them.
• Key revocation is irrevocable — once you destroy the keys and Microsoft's caches expire, the data is gone. There's no recovery.

When Customer Key is the right answer

Customer Key matters for organisations facing:

• Specific regulatory requirements — some industry frameworks require customer-controlled keys (parts of financial services, healthcare, certain defence scenarios).
• Multinational compliance — when the data residency requirements include cryptographic sovereignty.
• High-sensitivity tenants — typically where the regulator or contract explicitly requires it.

For most organisations, Customer Key is overkill. The default Microsoft service encryption already covers the threats most relevant to most businesses; sensitivity labels handle content-level protection.

Operational realities

• Key management is your responsibility — including geographic resilience, rotation, access control to Key Vault.
• Two Key Vaults in two regions are required for the encryption policy. Plan for the Azure costs.
• Onboarding takes weeks — Microsoft validates your setup before applying policies.
• Decommissioning takes weeks — destroying keys triggers a holding period before data becomes permanently inaccessible.

Licensing

Customer Key requires Microsoft 365 E5 or the standalone Office 365 Advanced Compliance licence, plus an Azure subscription for the Key Vault hosting.

For organisations that genuinely need it, Customer Key is a powerful compliance lever. For organisations without specific regulatory drivers, the operational overhead usually outweighs the benefit.