Data sovereignty in Microsoft 365 depends on where data sits, who holds the keys and which law applies. EU Data Boundary, Customer Key and DKE compared.
Data sovereignty in Microsoft 365 means keeping control over who can access your mail, files and chats, and under which law, not only over where they are stored. Microsoft's residency commitments decide the location. The encryption model decides who can decrypt. For most tenants the answer to the second question is still Microsoft, unless a key sits outside Microsoft's reach.
This guide separates the three questions a sovereignty programme has to answer, maps Microsoft's options to each, and shows where a customer-held key changes the outcome.
A data sovereignty requirement for Microsoft 365 usually breaks down into three questions:
| Question | What answers it in Microsoft 365 |
|---|---|
| Where is the data stored and processed? | Data residency commitments: EU Data Boundary, Advanced Data Residency, Multi-Geo |
| Which legal orders can reach it? | The provider's legal exposure, contracts and the jurisdiction of whoever holds the keys |
| Who can technically decrypt it? | The encryption model: Microsoft-managed keys, Customer Key, or Double Key Encryption |
Residency answers the first question only. Data stored in a Swiss or EU data centre is still readable by the service that holds the key. That is why sovereignty programmes end up discussing keys.
Microsoft documents several residency offerings for Microsoft 365. (Microsoft Learn: EU Data Boundary for Microsoft 365)
These commitments are about location. None of them changes who holds the keys.
The legal question is about the provider, not the data centre. The US Department of Justice explains that the CLOUD Act covers data "within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States," and calls the Act "encryption neutral." (DOJ white paper: The Purpose and Impact of the CLOUD Act)
Encryption neutral means the law neither requires nor forbids decryption. In practice, what a provider can produce depends on whether it holds a usable key. If it does, it can produce plaintext. If the decisive key sits with you, it can produce ciphertext only.
European regulators reached a similar conclusion for transfers. In its Recommendations 01/2020 on supplementary measures, the European Data Protection Board accepts strong encryption as an effective measure when the keys stay under the control of the data exporter, and finds no effective technical measure when a cloud provider needs the data in the clear to deliver its service. (EDPB Recommendations 01/2020)
This is a planning view, not legal advice. Whether a given setup meets a specific law or contract is a question for your counsel.
| Default encryption | Customer Key | BYOK for the Azure RMS root key | Double Key Encryption | |
|---|---|---|---|---|
| What it protects | All data at rest (BitLocker, DKM) | Exchange, SharePoint, OneDrive, Teams, Copilot interactions, Windows 365 | Purview Information Protection encryption | Selected items with a DKE label |
| Where your key lives | Microsoft | Azure Key Vault or Managed HSM, in your subscriptions | Azure Key Vault | Your DKE service, outside Microsoft |
| Can Microsoft 365 decrypt in normal operation? | Yes | Yes, for services you authorise | Yes | No. Both keys are required |
| Features kept | All | All | All | No web co-authoring, search or Copilot on protected items |
| Sovereignty effect | Location only | Lifecycle control and an exit path ending in cryptographic deletion | Lifecycle control of the label root key | Microsoft cannot produce readable content on its own |
Sources: Customer Key overview, Azure Rights Management root key, Double Key Encryption.
Customer Key and BYOK are covered in Microsoft Purview Customer Key. DKE is defined in what Double Key Encryption is. The direct comparison is DKE vs Microsoft 365 Customer Key.
DKE removes features, so it is not a tenant-wide setting. Sovereignty programmes that work classify first, then apply the control per class.
| Data class | Typical control |
|---|---|
| General collaboration | Default encryption inside the EU Data Boundary |
| Regulated data that must stay searchable and usable with Copilot | Customer Key, for lifecycle control and a documented exit |
| M&A, board papers, legal privilege, trade secrets, client-identifying data under secrecy rules | A Double Key Encryption label, with the key held outside Microsoft |
Microsoft itself positions DKE for a small share of content, about 5% in its own illustration. The point of classification is to make that share explicit and defensible to an auditor. The broader model behind this split is described in BYOK vs HYOK.
For Swiss organisations, the same logic applies to public-sector and banking secrecy requirements. See Microsoft 365 for Swiss public administration and data sovereignty in Switzerland.
Technical controls carry most of the weight, but the EDPB also expects contractual and organisational measures around them:
DuoKey provides the external key for Microsoft 365 Double Key Encryption:
See DuoKey for Microsoft 365 and the DKE setup guide. To shortlist providers, use six operational criteria for a DKE provider.
What is data sovereignty in Microsoft 365?
It is control over where Microsoft 365 data is stored, which legal orders can reach it, and who can technically decrypt it. Residency options answer the first point. The encryption model answers the last one.
Does the EU Data Boundary make Microsoft 365 sovereign?
It keeps storage and processing in EU and EFTA countries, with documented exceptions. It does not change who holds the encryption keys, so Microsoft's services can still decrypt the data.
Is Switzerland covered by the EU Data Boundary?
Yes. Microsoft lists Switzerland among the EFTA countries in the EU Data Boundary, and lists Swiss data centres among the locations it uses.
Does Customer Key give data sovereignty?
It gives lifecycle control over root keys and an exit path that ends in cryptographic deletion. Microsoft 365 services still decrypt the data in normal operation, so it does not stop the provider from reading it.
Which Microsoft 365 option keeps data unreadable to Microsoft?
Double Key Encryption. Labelled content needs both Microsoft's key and your key, and your key stays outside Microsoft. The trade-off is that web co-authoring, search and Copilot do not work on that content.
Does encryption protect against the CLOUD Act?
It changes what a provider can produce. If the provider holds no usable key, it can hand over only ciphertext. The DOJ describes the Act as encryption neutral. Whether that meets a specific legal requirement is a question for counsel.
Geschrieben von
Josua Rochat
Related Resources
Sagen Sie uns, wo Kontrolle heute schwierig ist. Wir helfen Ihnen, den nächsten praktischen Schritt zu finden.
