Why Your Microsoft 365 Encryption Isn't Enough

This article examines the limitations of default Microsoft 365 encryption and explains why organisations need additional controls to protect sensitive data.

Microsoft 365 encrypts your data. This is true. Microsoft uses AES-256 encryption, TLS for data in transit, and BitLocker for data at rest. These are industry-standard protections.

Yet "encrypted" does not mean "secure from everyone."

When Microsoft manages the encryption keys, Microsoft can access your data. For most organisations, this is acceptable. For regulated industries, sensitive intellectual property, or data subject to strict sovereignty requirements, it is a significant gap.

Let's examine why default M365 encryption falls short — and what you can do about it.

The key problem

Encryption is only as strong as the control over the keys.

With default M365 encryption, Microsoft generates, stores, and manages the encryption keys in Azure Key Vault. Microsoft implements robust security practices, but the fundamental issue remains: the key holder can access the data.

This creates three specific risks:

1. Breach exposure

In 2023, the Storm-0558 attack compromised a Microsoft account signing key. Attackers used this key to access Outlook Web Access across more than 25 organisations. With the key, they could read emails, access SharePoint files, and impersonate Azure AD users.

Had those organisations used customer-controlled encryption keys, the stolen Microsoft key would not have been sufficient to decrypt their data.

2. Government access

Microsoft is a US company. Under laws including the CLOUD Act, US authorities can compel Microsoft to provide access to customer data stored anywhere in the world — often without notifying the data owner.

For European organisations subject to GDPR, or Swiss companies under FINMA regulations, this creates a direct conflict with data protection obligations.

3. Compliance gaps

Regulations including GDPR, HIPAA, and various financial services frameworks require organisations to demonstrate control over data access. If your cloud provider holds the keys, you cannot demonstrate exclusive control.

Some auditors accept Microsoft-managed encryption. Many do not.

Compliance requirements by industry

Stricter frameworks increasingly expect encryption and evidence that decryption is not solely at the disposal of the cloud provider. The following are representative obligations that intersect with how M365 keys are controlled.

Financial services (EU) — DORA

The Digital Operational Resilience Act (DORA) (Regulation (EU) 2022/2554) applies to a broad set of financial entities and sets ICT risk-management expectations, including secure practices for third-party arrangements. Article 28 in particular addresses ICT third-party risk management — relevant when a single vendor both hosts data and operates keys. For a practical view of how encryption and distributed key control support these expectations, see DuoKey’s DORA compliance use case.

Essential and important entities (EU) — NIS2

The NIS2 Directive (Directive (EU) 2022/2555) expands cybersecurity duties for operators in sectors from energy and transport to digital providers and public administration. Article 21(2)(h) requires policies and procedures on the use of cryptography and, where appropriate, encryption — which auditors often read together with demonstrable key governance. For a detailed guide, see NIS2 encryption requirements: what enterprises must implement.

Swiss public administration — data protection and confidentiality

Swiss federal and cantonal bodies often process sensitive personal data or information subject to legal duties of confidentiality (including professional and official secrecy). The revised Federal Act on Data Protection (FADP) requires appropriate technical and organisational measures; complementary federal and cantonal rules apply to official documents and specific sectors. Swiss data protection guidance has stressed that when the cloud provider can technically access decryption keys, standard M365 encryption may be insufficient for the most sensitive categories — and that architectures such as Double Key Encryption, which keep a decisive key outside the provider’s environment, are relevant. DuoKey outlines the compliance angle for the public sector in Microsoft 365 for Swiss public administration.

What Customer Key provides

Microsoft offers Customer Key as a step beyond default encryption. With Customer Key, you provide root encryption keys that Microsoft uses to encrypt your data.

This adds a customer-controlled layer:

Microsoft's service encryption (always present)
Your Customer Key (stored in Azure Key Vault, but under your tenant)
BitLocker encryption (at the physical layer)

Customer Key improves your control, but the keys still reside in Microsoft infrastructure. If your Azure tenant is compromised, your Customer Keys are exposed.

What Double Key Encryption provides

Double Key Encryption (DKE) goes further. It requires two separate keys to decrypt any protected content:

One key in Azure Key Vault (Microsoft can access this)
One key in an external system (Microsoft cannot access this)

Both keys are required. Microsoft cannot decrypt DKE-protected content because it lacks your external key.

This architecture means:

Breach protection — attackers need both keys, which reside in separate systems
Sovereignty — your external key can remain in your jurisdiction
Compliance — you can demonstrate that Microsoft cannot access protected content

When you need more than default encryption

Default M365 encryption is sufficient for general business data. Consider stronger controls when:

You handle data subject to GDPR, HIPAA, FINMA, or similar regulations
Your industry faces heightened breach risk (financial services, healthcare, legal)
You store intellectual property or trade secrets
You operate in jurisdictions with data sovereignty requirements
Compliance auditors require proof of exclusive data control

For most organisations, this represents approximately 5–10% of total data — the genuinely sensitive content that requires additional protection.

Implementing DKE with DuoKey

DuoKey provides the external key management component for Microsoft Double Key Encryption.

Unlike traditional HSM-based deployments, DuoKey offers MPC-based key management. The encryption key is split across multiple independent servers. No single entity — not DuoKey, not any administrator — ever possesses the complete key.

This approach eliminates single points of compromise while maintaining the operational simplicity of a managed service.

Conclusion

Microsoft 365 encryption protects your data from external attackers. It does not protect your data from Microsoft, from government requests routed through Microsoft, or from breaches of Microsoft's own infrastructure.

For sensitive data, this distinction matters.

Double Key Encryption addresses this gap by requiring a second key that never enters Microsoft's environment. Your data remains encrypted even if Microsoft's systems are compromised.

The question is not whether M365 encryption is good. It is whether it is sufficient for your most sensitive data. For many organisations, the answer is no.

Next steps: Watch the DuoKey DKE demo on the Microsoft 365 product page.