End-to-end encryption (E2EE) has become the gold standard for securing digital communication. Tech giants like Microsoft are responding with updates to their tools that promise “end-to-end encryption”, especially in platforms like Microsoft Teams.
But what is actually behind these promises? And more importantly, is it really enough for organizations operating in critical sectors or under strict regulations like the NIS2 Directive?
Let’s break down what Microsoft’s E2EE really means, and why it may fall short of what security-first organizations need.
Microsoft’s E2EE is Extremely Limited
Microsoft’s official documentation confirms that end-to-end encryption is available in Teams, but with significant limitations. It only covers one-on-one VoIP calls, leaving out group calls, meetings, chat, and file sharing. Additionally, the feature isn’t enabled by default: IT administrators must proactively activate it through policy settings.
Once enabled, E2EE disables several core features:
- Call recording
- Live captions and transcription
- Call transfer and park
- Companion devices
This means enabling encryption comes at the cost of collaboration features many enterprises rely on. And more critically, users may remain unaware of whether their calls are encrypted at all.
.png?width=800&height=539&name=Heading%20(1).png)
The Limitations of Optional Encryption
While offering flexibility, Microsoft’s approach reveals several red flags when viewed through a security and compliance lens:
- Encryption is opt-in: If E2EE isn’t enabled by default, many calls will happen without it, by design or by oversight
- Unclear user awareness: It’s difficult for users to verify when encryption is active, undermining trust in the platform
- Metadata exposure: Even when E2EE is active, metadata, such as who called whom and when, remains accessible, potentially creating exploitable information trails
- Outdated protocol: Microsoft uses an older protocol called Datagram Transport Layer Security (DTLS) which has poor support for forward secrecy and no post-compromise security, lagging far behind state-of-the-art protocols like MLS
For organizations governed by strict regulatory frameworks like NIS2, this is a critical gap. Encryption needs to be systemic, robust, and always-on by default, not a toggle buried in admin settings.
Want to see how this aligns - or doesn’t - with regulatory expectations? Download our NIS2 whitepaper to explore what true compliance entails.
Why That’s Not Enough for Critical Infrastructure and Regulated Sectors
If your organization operates in sectors like energy, finance, telecom, or public services, the stakes are higher. Here’s what these environments typically require:
- Encryption that is always on, not optional
- Coverage across all communications: chat, voice, video, and file sharing
- Tamper-proof audit trails for investigations and compliance reporting
- Fallback and crisis-resilient communication channels for maintaining operations during cyber incidents
- Zero-trust principles at the core: assume compromise, verify everything
Under frameworks like NIS2, executive-level accountability and traceable security controls are now non-negotiable. Microsoft Teams may suit general business use, but its narrow and optional E2EE is insufficient to protect sensitive data.
Redefining E2EE for the Real World
Microsoft’s implementation of end-to-end encryption looks good on paper, but is functionally . For enterprises that only need to show checkbox compliance, it may be “good enough.” But for real-world E2EE requirements, especially for critical sectors, regulated environments, or organizations under geopolitical scrutiny, Microsoft’s implementation is far from safe.
The message is simple: end-to-end encryption only matters if it’s universal, robust, enforceable, and user-friendly. Optional features that only work on a subset of communications, utilize out-of-date protocols, break collaboration or rely on perfect admin configuration won’t meet the demands of real-world data protection, risk management and compliance.