Is EU Data Boundary or hosting in Switzerland sufficient for compliance?

These measures can help with residency and operational constraints, but they do not change the key-control model. If Microsoft can technically access the keys, the deployment remains problematic for sensitive or legally confidential data under Swiss expectations.

Why is BYOK / Customer Key often considered insufficient?

With BYOK, the key is stored and operated in Azure Key Vault, which is run by Microsoft. This can preserve Microsoft’s technical ability to access key material and thus decrypt data, which is why certain Swiss guidance excludes it for high-sensitivity categories.

What makes Double Key Encryption different?

DKE requires two keys to decrypt. Microsoft only holds one key, while the administration holds the second key in a sovereign external infrastructure. Without both keys, data cannot be decrypted, even if the encrypted data is disclosed.

How do we get started in an administration already using M365?

Start by mapping the data you process (including sensitive and legally confidential categories), assessing the current M365 encryption/key architecture, then implementing a provider-excluded key control architecture such as DKE for the relevant workloads.

Microsoft 365 for Swiss Public Administration

Nov 2025

Swiss guidance raised the bar: provider-accessible keys are no longer acceptable for sensitive or legally confidential data in M365.

US CLOUD Act

Swiss/EU hosting doesn’t remove extraterritorial access risk when the provider is a US entity.

Double Key Encryption

Keep the decisive key outside Microsoft to exclude provider access—while preserving Microsoft 365 usability.

Why “standard” Microsoft 365 encryption is no longer enough

Swiss guidance has made the decision criterion explicit (source): if the cloud provider can technically access decryption keys, protection is not sufficient for sensitive personal data or data under a legal duty of confidentiality.

That decision point applies to typical Microsoft 365 deployments, where encryption remains dependent on keys Microsoft can operate—even when customer-managed options are enabled.

Limits of Microsoft default encryption

Across “standard” Microsoft 365 encryption setups, protection ultimately depends on keys that remain within Microsoft’s operational control. That means there is no strict technical separation between the encrypted data and the ability to decrypt it, so the provider can retain a path to cleartext access, an issue for sensitive and legally confidential categories in the Swiss public sector.

Compliant architecture: Double Key Encryption (DKE)

Double Key Encryption (DKE) is explicitly referenced in Swiss discussions as an example of encryption that is effective against the cloud provider. DKE relies on two distinct keys

DKE establishes strict technical separation between encrypted content and the decisive decryption key.

Key benefits for Swiss public bodies

Align M365 usage with Swiss confidentiality and data protection expectations — without sacrificing productivity.

Provider-excluded key control

Keep the decisive key outside Microsoft, preventing provider access to cleartext data.

Regulatory readiness

Address the post-2025 compliance bar for sensitive personal data and legally confidential information.

Maintain M365 usability

Preserve core Microsoft 365 workflows while strengthening cryptographic control.

Frequently Asked Questions (FAQs)

Keep Microsoft 365, without compromising sovereignty

Whether you have already migrated or are planning a migration, you can integrate a compliant encryption architecture and maintain full M365 functionality.