Customer-managed keys

What it does

CMK lets you supply the database encryption key for a Dataverse environment from your own Azure Key Vault instead of using the Microsoft-managed key. You can rotate it, swap it, and revoke access — which locks the environment and cuts off Microsoft's access to your data along with everyone else's.

Key facts

The plumbing is a Power Platform enterprise policy: an Azure resource that references your key and gets its own Entra managed identity. The key vault admin grants that identity access to the key, then grants the Power Platform admin read access to the policy, and only then can the Power Platform admin add environments to it.
Keys must be RSA, 2048-bit or 4096-bit, from Azure Key Vault or Managed HSM. HSM BYOK is supported.
The key vault must have soft-delete and purge protection enabled. Without them you can't encrypt an environment at all.
CMK policy is enforced only on environments activated for Managed Environments, and users in those environments need one of a specific set of Microsoft 365 / Office 365 compliance or security subscriptions. The exact list is on the Microsoft page and changes — check it rather than quoting from memory.
Changing the key means creating a new enterprise policy, removing the environment from the old one, and adding it to the new one. There's no in-place rekey.
Reverting to the Microsoft-managed key is supported: remove the environment from the enterprise policy.
Locking is deliberate and total. Revoke key or vault permissions and the environment becomes inaccessible to everyone including Microsoft support, and data loss can occur.
Coverage is broad across Dataverse, Power Automate, Copilot Studio and most Dynamics 365 first-party apps in commercial cloud, with a shorter list in GCC High.
Documented exclusions that stay on the Microsoft-managed key: connector connection settings, Power Platform environment settings, Power Apps display names, descriptions and connection metadata, maker welcome content, Nuance Conversational IVR, solution checker enforcement results and their download links, and Copilot Studio data sent as part of Agent 365 security audit logging.
Audit log retention settings aren't available on CMK-encrypted environments.
Backup and restore only work between environments carrying the same customer-managed key.

When to use / skip

CMK is a control requirement, not a security improvement — the data is already encrypted at rest with a Microsoft-managed key either way. Do it when a regulator, a contract or an internal policy demands that the customer holds the key, and be clear that what you're buying is the ability to revoke. If nobody can articulate why revocation matters, you're adding an operational failure mode and a licensing bill for no benefit. The honest test: ask who would authorise pulling the key, under what circumstances, and what the recovery plan is. If there's no answer, skip it.

Configuration decisions

Which environments are in scope, given each needs to be a Managed Environment and the whole dev/test/production chain needs the same key for restores to work.
Key vault location, which should match the environment's region, and whether it's standard Key Vault or Managed HSM.
Key size and rotation policy, and who's accountable for executing a rotation given it means a new enterprise policy each time.
Separation of duties between the Azure Key Vault administrator and the Power Platform administrator — the documented mitigation for the malicious-admin scenario.
Whether the audit retention limitation is acceptable, because on a CMK environment you lose that setting.

Gotchas

A single administrator holding both the Key Vault and Power Platform admin roles can lock every environment in the tenant. Microsoft names this as the primary risk and separation of duties as the mitigation.
Losing audit retention configuration on CMK environments catches compliance teams who wanted both controls.
Restore refusing to run unless the target has the same CMK applied means your sandbox refresh chain has to be inside the CMK boundary too. Forget this and refreshes stop working.
The exclusion list is longer than clients expect. Connection settings, environment settings and app metadata all stay Microsoft-managed, so "everything is under our key" is not a statement you can make.
Skip soft-delete or purge protection on the vault and the whole thing simply won't configure — with an error that doesn't obviously point at the vault settings.

Consultant notes

Walk the client through the lock scenario before the design is signed off. It converts CMK from a checkbox into a risk decision with a named owner, which is what it should have been from the start.
Put the exclusion list in the compliance pack verbatim. Someone will eventually ask whether a specific artefact is under the customer key, and the answer needs to be sourced rather than remembered.
The licensing requirement covers users in the environment, not just the admin. Get that in front of licensing before you commit, and point at Microsoft's page rather than naming SKUs from memory.
Treat the enterprise policy as production infrastructure with change control. It's an Azure resource that can take a business offline, and it usually ends up owned by a team that doesn't know that.

Revisit if the CMK exclusion list changes, or if audit retention ever becomes configurable on CMK environments.