"Is Zoom encrypted end to end?" is one of the most searched security questions on the internet. The answer is yes — technically, optionally, and with significant caveats that most users do not understand. Zoom does offer an end-to-end encryption (E2EE) feature. But the gap between what "end-to-end encrypted" implies to most people and what Zoom's E2EE actually delivers is substantial. And even when Zoom's E2EE is enabled, the underlying cryptographic algorithms are vulnerable to quantum computers — a threat that is active today through harvest-now-decrypt-later attacks, not just a theoretical future concern.
This article provides a factual, technical analysis of Zoom's encryption. We explain exactly what Zoom's E2EE covers, what it does not cover, what cryptographic algorithms it uses, and why those algorithms represent a material security risk in 2026. We also explain what genuine post-quantum end-to-end encryption looks like and why V100 is the only video platform that delivers it.
What Most People Think "End-to-End Encrypted" Means
When most people hear "end-to-end encrypted," they understand it to mean that only the people on the call can see and hear the content. No one else — not the platform provider, not hackers, not governments — can access the unencrypted data. The encryption starts at one end (the sender) and only ends at the other end (the receiver). The platform in the middle cannot decrypt the content even if it wanted to. This is a reasonable interpretation, and for messaging apps like Signal, it is accurate.
The problem is that Zoom's implementation of E2EE does not work this way for most Zoom calls. The vast majority of Zoom meetings use what Zoom calls "enhanced encryption" — which is encryption in transit using TLS for signaling and SRTP for media. This is not end-to-end encryption. With encryption in transit, the data is encrypted between your device and Zoom's servers, and then between Zoom's servers and the other participants. But at Zoom's servers, the media is decrypted and re-encrypted. This means Zoom's infrastructure has access to the unencrypted content of every standard meeting.
Zoom does offer a separate, opt-in E2EE mode. But this mode is not the default. It must be manually enabled by the meeting host for each individual meeting. And enabling it comes with severe feature restrictions that make it impractical for most enterprise use.
What Zoom's E2EE Actually Covers (and What It Does Not)
Zoom introduced its E2EE feature in October 2020, initially as a technical preview and later as a generally available feature. When enabled, Zoom's E2EE encrypts meeting content so that Zoom's servers relay encrypted data without the ability to decrypt it. The encryption uses AES-256-GCM for symmetric media encryption, with key agreement performed using ECDH over the P-256 elliptic curve. The E2EE protocol is based on the Messaging Layer Security (MLS) framework.
However, Zoom's E2EE has substantial limitations that most users are not aware of. Understanding these limitations is critical to assessing whether your Zoom calls are genuinely protected.
Features disabled when Zoom E2EE is enabled
Source: Zoom support documentation, updated January 2026
The practical impact of these restrictions is severe. Cloud recording is used by the majority of enterprise Zoom accounts for compliance, training, and documentation purposes. Live transcription has become a standard accessibility feature. Breakout rooms are essential for workshops, training sessions, and collaborative meetings. AI Companion, Zoom's recently launched AI features, are among the platform's most promoted capabilities. Enabling E2EE disables all of them.
The result is predictable: almost no one uses Zoom's E2EE in practice. Enterprise IT administrators who manage compliance-sensitive environments cannot accept the loss of cloud recording. Accessibility-focused organizations cannot sacrifice live transcription. Training teams cannot give up breakout rooms. The feature exists on paper but is effectively unusable for most real-world enterprise scenarios.
Additionally, Zoom's E2EE is capped at 200 participants. Large webinars, all-hands meetings, and company-wide events — which often contain the most sensitive organizational communications — cannot be E2EE-protected on Zoom.
The Cryptography Behind Zoom's E2EE: ECDH P-256 and Why It Matters
Even when Zoom's E2EE is enabled, the underlying cryptographic algorithms have a fundamental weakness that most security analyses overlook: they are not quantum-safe. Zoom's E2EE uses ECDH (Elliptic Curve Diffie-Hellman) over the P-256 curve for key agreement. P-256 is a well-studied, widely-deployed elliptic curve specified by NIST. By classical cryptographic standards, it is considered strong. By post-quantum standards, it is fatally vulnerable.
Shor's algorithm, when executed on a sufficiently powerful quantum computer, solves the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial time. This means that ECDH P-256 key exchanges can be retroactively broken by recording the public keys exchanged during the handshake, storing them, and solving the ECDLP when a quantum computer is available. The private keys can be recovered, the shared secret reconstructed, and the session key derived. At that point, every media packet from that session can be decrypted.
This is the harvest-now-decrypt-later threat applied specifically to Zoom's E2EE. An adversary who records the key exchange and encrypted media of a Zoom E2EE call today can decrypt the entire session when quantum computers break P-256. The E2EE is providing protection against Zoom (the company) seeing the call content today, but it is not providing protection against a quantum-equipped adversary decrypting the call in 2035.
| Component | Zoom E2EE | V100 PQ-E2E |
|---|---|---|
| Key exchange | ECDH P-256 (quantum vulnerable) | ML-KEM-768 + X25519 (quantum safe) |
| Signatures | ECDSA (quantum vulnerable) | ML-DSA-65 + FALCON-512 (quantum safe) |
| Media encryption | AES-256-GCM | AES-256-GCM |
| E2EE default | Off (opt-in per meeting) | On (every call) |
| Features disabled by E2EE | 8+ features disabled | None |
| PQ algorithm families | 0 | 3 (MLWE + NTRU + Hash-based) |
| HNDL protection | No | Yes |
Zoom's Default "Enhanced Encryption": What It Actually Means
The majority of Zoom calls do not use E2EE at all. They use Zoom's default encryption mode, which Zoom labels "enhanced encryption." This is standard TLS encryption for the signaling channel and SRTP encryption for the media stream. In this mode, each participant's device encrypts media before sending it over the network, and the media is decrypted at Zoom's servers. Zoom's media processing infrastructure then re-encrypts the media for delivery to each recipient.
This is encryption in transit, not end-to-end encryption. The critical difference is that Zoom's server-side infrastructure has access to the unencrypted content of the call. Zoom has stated that it does not routinely monitor call content, and its privacy policy describes limitations on how content is used. But the technical architecture means that the capability exists. Zoom's servers can, and do, process unencrypted media for features like cloud recording, live transcription, AI Companion, and real-time translation.
For organizations that care about the distinction between "our vendor promises not to look at our data" and "our vendor physically cannot look at our data," this matters enormously. The former is a policy commitment. The latter is a mathematical guarantee. True end-to-end encryption provides the mathematical guarantee. Zoom's default mode provides only the policy commitment.
Furthermore, in the default enhanced encryption mode, the SRTP key management also uses classical ECDH, which means the same quantum vulnerability applies. Even the encryption-in-transit layer is quantum-vulnerable. An adversary who captures Zoom traffic in the default mode gets both the content exposure risk from server-side decryption and the quantum exposure risk from classical key exchange.
A Brief History of Zoom's Encryption Controversies
Zoom's encryption has been the subject of significant controversy since the platform's explosive growth during the COVID-19 pandemic in 2020. In March 2020, The Intercept reported that Zoom was marketing its calls as "end-to-end encrypted" when in fact they were only encrypted in transit. The FTC subsequently investigated and found that Zoom had been misleading users about the level of encryption since at least 2016. Zoom settled with the FTC in November 2020, agreeing to implement a comprehensive security program and stop misrepresenting its security practices.
In April 2020, researchers at the Citizen Lab at the University of Toronto found that Zoom was using AES-128 in ECB mode (not the more secure GCM mode) for some calls, and that encryption keys were being transmitted through servers in China even for calls between non-Chinese participants. Zoom subsequently upgraded to AES-256-GCM and implemented geographic routing controls.
Zoom launched its actual E2EE feature in October 2020, initially limited to free and paid accounts on the desktop and mobile clients. The feature has been gradually expanded but, as detailed above, it remains opt-in with significant feature trade-offs. The gap between Zoom's marketing of its encryption and the technical reality has been a recurring theme since 2020.
None of these historical issues related to quantum safety — they were about whether Zoom's encryption even met classical standards. The quantum vulnerability of Zoom's cryptographic primitives is an additional, independent layer of risk on top of the design and implementation issues that have already been documented.
What Genuine Post-Quantum End-to-End Encryption Looks Like
V100's approach to end-to-end encryption is architecturally different from Zoom's in three fundamental ways. First, it is on by default for every call — there is no opt-in toggle, no feature trade-offs, and no configuration required. Second, the key exchange uses post-quantum algorithms (ML-KEM-768 hybridized with X25519) that are resistant to both classical and quantum attacks. Third, V100 uses three independent post-quantum algorithm families rather than relying on a single mathematical assumption.
When a V100 video session begins, each participant generates both an ML-KEM-768 keypair and an X25519 keypair. The public keys are exchanged over the signaling channel, and each participant performs both ML-KEM encapsulation and X25519 key agreement. The session key is derived as SHA3-256(x25519_shared || ml_kem_shared). This hybrid approach means the session is secure if either ML-KEM or X25519 holds — a belt-and-suspenders design that protects against both quantum and classical attacks.
V100's SFU (Selective Forwarding Unit) relays encrypted packets without decryption. Unlike Zoom's default mode, the V100 infrastructure never has access to unencrypted content. Cloud recording on V100 works with E2EE because recordings are encrypted with participant-controlled keys — not decrypted at the server. Live transcription uses client-side speech-to-text models. There are no feature trade-offs because the system was designed for E2EE from the ground up, not retrofitted onto an architecture that assumes server-side media processing.
Signaling messages are authenticated with ML-DSA-65 and FALCON-512, providing dual-family post-quantum signature verification. Long-lived artifacts like recordings and transcripts are additionally signed with SLH-DSA (hash-based signatures) for maximum long-term assurance. Every session generates a 74-byte H33-74 substrate attestation — a cryptographic proof of session integrity that is PQ-attested across all three algorithm families.
Who Should Care About This
If your organization uses Zoom for calls that contain information with multi-year sensitivity, the analysis above has direct implications for your security posture. The question is not whether Zoom's E2EE exists — it does. The question is whether your calls are actually using it (they probably are not, because of the feature trade-offs), and whether the encryption it provides will remain secure for the lifetime of the information it protects (it will not, because ECDH P-256 is quantum-vulnerable).
Healthcare organizations conducting telehealth on Zoom should consider that PHI has no expiration date under HIPAA. Legal teams using Zoom for privileged communications should consider that attorney-client privilege does not have a quantum exception. Financial services firms using Zoom for board meetings should consider that the decryption of a pre-earnings discussion could create regulatory liability decades from now.
The complete guide to quantum safe video conferencing provides a full evaluation framework. The V100 live demo shows what post-quantum E2E encryption looks like in practice. The free trial lets you make your first quantum-safe call in under two minutes.
Zoom has a place in the market for casual, non-sensitive video calls where the content has no long-term value. But for any communication where the content matters beyond today, the encryption it provides — whether in its default mode or its E2EE mode — is not sufficient for the threat landscape of 2026 and beyond.
Your calls deserve real end-to-end encryption
V100 delivers post-quantum E2E encryption on every call by default. No opt-in toggles. No disabled features. No quantum-vulnerable key exchange. Three independent PQ algorithm families. See the green PQ-E2E badge on your first call.