What it does

Dataverse encrypts customer data at rest by default and everything in transit over TLS. The only part that's genuinely configurable is who holds the database encryption key — Microsoft by default, or you via customer-managed keys — plus a separate column-level encryption key used by the customer engagement apps.

Key facts

• Dataverse spreads data across several stores and all of them are encrypted at rest: Azure SQL Database for relational data, Azure Blob storage for binary data, Azure Search for indexes, Azure Cosmos DB for audit data, Azure Data Lake for analytics.
• The default is a Microsoft-managed key. You don't configure it, you don't rotate it, and you can't turn encryption at rest off.
• Customer-managed keys are the configurable alternative: an RSA 2048-bit or 4096-bit key in your own Azure Key Vault or Managed HSM, including HSM BYOK, referenced through a Power Platform enterprise policy. Reverting to the Microsoft-managed key is supported at any time.
• Separately, the customer engagement apps use standard SQL Server cell-level encryption for a fixed set of columns holding sensitive values such as user names and email passwords. This helps organisations meet FIPS 140-2 compliance.
• That column-level encryption is on for all new and upgraded organisations and can't be turned off. A System Administrator can change its key under Settings > Encryption > Data encryption.
• The generated passphrase is Unicode. Save it with a Unicode-aware editor or you'll corrupt it — Notepad defaults to ANSI.
• In transit, Microsoft uses industry-standard TLS between user devices and datacentres and within datacentres, plus IPsec and AES-256 across the infrastructure. Internal service-to-service traffic runs over the Microsoft backbone rather than the public internet.
• Current server endpoints require TLS 1.2 or higher; older versions are rejected. Cipher suite and TLS specifics have their own Microsoft page and change over time — check it rather than quoting a suite list.

When to use / skip

There's very little to decide here, which is exactly the message to give a client asking "is our data encrypted?". At rest and in transit, yes, by default, with no configuration. The two real decisions are whether you need to hold the key yourself — which is the CMK conversation and a control requirement rather than a security one — and whether anyone has a copy of the column-level encryption key stored somewhere sensible. Beyond that, effort spent on encryption is usually effort taken from access control, which is where Dataverse data actually leaks.

Configuration decisions

• Microsoft-managed key or customer-managed key per environment, driven by whether revocation is a requirement you can articulate.
• Where the column-level organisation encryption key is stored, in what format, and who can retrieve it.
• Whether client-side TLS configuration on any integrating system meets the 1.2 minimum — this bites on older on-premises middleware.
• Which supporting stores are in scope for the client's encryption statement, given Dataverse spans SQL, Blob, Search, Cosmos DB and Data Lake.
• Whether data leaving Dataverse — Synapse Link exports, Excel exports, integration targets — inherits any protection at all, because that's usually where the real gap is.

Gotchas

• Saving the organisation encryption key with an ANSI text editor mangles the Unicode passphrase, and you find out when you need it.
• Column-level encryption covers a fixed set of platform columns. It isn't a mechanism for encrypting your own sensitive columns — that's column-level security, which is a different feature solving a different problem.
• TLS 1.2 as a minimum breaks older integrating systems that negotiate 1.1 or below, and the failure looks like a network problem rather than a policy one.
• Encryption at rest protects against someone walking off with the storage. It does nothing about a user with an over-broad security role, which is the threat clients actually face.
• Anything you export out of Dataverse loses all of this. A CSV on a laptop is not encrypted by Dataverse's key.

Consultant notes

• When a security questionnaire asks about encryption, answer from the Microsoft pages and attach them. Paraphrased answers about cipher suites age badly and get challenged.
• Redirect the "can we encrypt this column" question to column-level security. Nine times out of ten what the client wants is access restriction, not cryptography.
• Keep the CMK conversation separate from the general encryption conversation. Mixing them leaves clients thinking their data isn't encrypted unless they buy CMK, which isn't true.
• Spend the security budget on the security model, sharing behaviour and export privileges. Encryption is already handled; row access usually isn't.

---

Worth revisiting if the minimum TLS version moves again, or if the set of column-level encrypted fields changes.