What it does

Two separate things clients tend to ask about in the same breath. Data residency is which region an environment lives in and therefore where its data sits. Customer-managed key (CMK) is the option to supply your own encryption key from your Azure Key Vault, so you control rotation and can revoke Microsoft's access to your data at will.

Key facts

• An environment is bound to the region you create it in. Everything created in that environment — Dataverse database, apps, flows, connections, gateways, custom connectors — is deployed in that geography's datacentres.
• You can create an environment in a different region from your Entra tenant. The exceptions are tax-driven: India and Australia each require the tenant to be in-country, though Australia has an exception path. Only US Government organisations can create in GCC.
• On-premises data gateways aren't available in the India region.
• All customer data in Power Platform is encrypted at rest by default with Microsoft-managed keys. CMK is the option to swap that for your own.
• CMK needs an RSA (RSA-HSM) key in your Azure Key Vault, a Power Platform enterprise policy that references it, and permission grants so the policy can read the key. Microsoft has no direct access to your key vault.
• CMK is only enforced on environments activated for Managed Environments, and users in those environments need a qualifying Microsoft 365 / Office 365 compliance-tier subscription on top.
• Power Automate is on the list of services whose data can be encrypted with CMK in the commercial cloud. The GCC High list is shorter and doesn't include it.
• Several things stay on Microsoft-managed keys regardless: connector connection settings, Power Platform environment settings, Power Apps display names, descriptions and connection metadata, and solution checker output.
• Revoking key vault or key access locks the environment. Locked environments can't be accessed by anyone, Microsoft support included, and Microsoft's own documentation warns that data loss can occur.
• Changing the key means creating a new enterprise policy, removing the environment from the old one and adding it to the new. There's no in-place key swap.

When to use / skip

Residency is a design decision you make once and can't undo, so get it right at environment creation and expect to justify it in writing. CMK is a different beast — it's for clients with a specific regulatory or contractual requirement to hold their own key, and it brings real operational risk in exchange. If the client can't name the clause that requires it, the default Microsoft-managed encryption is stronger in practice because nobody in their organisation can accidentally lock the environment. When someone asks for CMK "for security", it's usually a procurement checkbox rather than a threat model.

Configuration decisions

• Which region each environment sits in, decided against both the client's compliance boundary and where their users actually are.
• Whether CMK is genuinely required, and whether the Managed Environments plus compliance-subscription licence stack is affordable across every user in scope.
• Who holds key vault access, how the key rotates, and what the break-glass process is.
• What the client accepts is out of scope for CMK — connection settings and environment metadata stay on Microsoft keys, and that needs to be in the compliance sign-off.
• Whether the sovereign cloud service list actually covers the workloads planned, since the GCC High coverage is narrower.

Gotchas

• Region is fixed at environment creation. Moving an environment between regions isn't a configuration change, it's a rebuild and migration.
• "Our data stays in region" is not quite true end to end. Connectors reach out to whatever service they're pointed at, and that service's location is a separate question from the environment's.
• Revoking key access is a genuine self-destruct button. Nobody, including Microsoft support, can get into a locked environment. Make sure the client's key vault admins understand that before you hand over.
• CMK doesn't cover everything. Clients who read "customer-managed key" as "all our data, our key" are wrong about connection settings and app metadata, and that's the sort of gap an auditor finds.
• Admin centre analytics data has its own residency behaviour — it's hosted in the environment's region and retained there for a defined window, separate from your Dataverse retention settings.

Consultant notes

• Get the residency requirement in writing during discovery, before anyone creates an environment. Retrofitting is the single most expensive mistake in this area.
• Push back gently on unqualified CMK requests. Ask what the requirement is, then show the risk trade-off. Half the time the client lands on Microsoft-managed keys plus Lockbox and is happier for it.
• If CMK goes ahead, insist the key vault sits under the same change control as anything else that can take production down. Treat key access revocation as a Sev 1 capability, not a setting.
• Give the client the exclusion list explicitly. It's short, it's documented, and it's much better raised by you than discovered in an audit.

---

Recheck the CMK service coverage list, especially for sovereign clouds, before committing to it in a compliance design.