16 August 2026
End-to-end encryption on a video call means only the participants' devices hold the keys that decrypt the audio and video — the provider's servers relay ciphertext they cannot open. That protects against a compromised or legally compelled provider, but it also removes the provider's ability to run anything that needs to read the content: live transcription, AI-generated notes, search across past meetings, and an AI participant that answers when addressed. That's why every platform that offers E2EE offers it as an optional mode, never the default.
Standard video call encryption — TLS to the server, DTLS-SRTP on the media stream — protects the packets in transit between a device and the provider's infrastructure. An attacker on the network between you and the server sees nothing useful. But the provider's servers decrypt the stream to route it, and in most products, to process it: mixing audio, running speech-to-text, storing a recording. That server-side plaintext is the thing E2EE removes.
With E2EE, keys are generated and exchanged between participants' devices — often using something like the MLS protocol (Messaging Layer Security) for group calls, an evolution of the same double-ratchet idea Signal uses for messages. The server becomes a relay that forwards encrypted blobs it cannot decrypt. This closes off a specific threat: a provider whose infrastructure is breached, a rogue employee with database access, or a subpoena compelling the company to hand over call content. If the server never has the plaintext, there's nothing to hand over.
This is the part vendors rarely put on the same page as the security pitch. Every feature that depends on server-side processing of audio or video stops working the moment E2EE is on, because those features are, mechanically, the server reading the content.
Live transcription needs the server (or a service it forwards to) to run speech recognition on the raw audio — it can't transcribe ciphertext. An AI participant that keeps notes current or updates a decisions log during the call needs the same access, continuously. Search across past meetings needs a searchable index built from that transcript, sitting in the provider's storage — if the provider never saw the words, there's no index to build. Recording still works in the sense that bytes get saved, but if those bytes are encrypted end-to-end, replaying or summarizing them later requires the same keys the server never had.
If E2EE only cost security, every provider would turn it on everywhere. It doesn't — it costs the features that make a meeting tool more than a phone call. Most meetings aren't legally privileged or trade-secret sensitive; most participants want the notes, the transcript, and the ability to find what was decided three weeks later more than they want protection against a threat model that assumes the provider itself is hostile or compromised.
There's also an operational cost independent of features. Key management gets harder with every participant who joins late, drops and reconnects, or dials in from a phone line that can't run the encryption client at all — PSTN participants are a common gap, since a phone call can't hold an end-to-end key. Group re-keying on every membership change adds latency and CPU work that scales with headcount. None of this is fatal, but it's a reason products treat E2EE as a toggle for the specific call that needs it, not infrastructure that runs under everything.
AVAY runs an AI participant in every meeting that transcribes as people talk, keeps notes and a decisions log current mid-call, and can be addressed directly to answer a question out loud — all of which requires that participant to have the same access to the audio stream as any human on the call. That's not a workaround to be closed later; it's the same constraint every product with server-side AI features runs into. A meeting that wants that AI participant active is, by definition, not a meeting where the media is end-to-end encrypted from every other participant, because the AI itself is one of the parties reading it.
This is worth saying plainly rather than glossing over: AVAY does not offer an end-to-end encrypted mode for calls using its AI participant, notes, or cross-meeting search, because those features are built on server-side access to the content. A team with a genuine need to keep a specific call's content unreadable to any third party — including the platform — is better served choosing a call mode or a different tool for that one meeting, and keeping AVAY's transcription and notes for the calls where that's not the threat they're managing.
| Standard mode (server-processed) | End-to-end encrypted mode | |
|---|---|---|
| Live transcription and notes | Works — server reads audio in real time | Not possible — server only has ciphertext |
| Search across past meetings | Works — server builds a searchable index | Not possible — nothing to index |
| AI participant answers when addressed | Works — AI has the same access as a human participant | Not possible unless AI itself holds a call key |
| Recording usable after the call | Can be stored and transcribed later | Encrypted at rest — unusable without participant keys |
| Protection if the provider is breached or subpoenaed | Provider holds readable content, can be compelled to share it | Provider holds nothing readable — no content to hand over |
| Late joiners and phone dial-in | Trivial — server relays to anyone | Adds re-keying step; plain phone lines usually can't join |
No. Any participant's own device still has the decrypted stream and can record locally, the same way someone can record a phone call on their own end. E2EE stops the provider's servers from being able to produce a usable recording centrally — it doesn't stop a participant from doing it on their machine.
Only if it's treated as a full participant holding its own call key, which means it has the same access to the content as a human would. That defeats the point of E2EE for anyone trying to keep the content unreadable to third-party services, which is why most platforms — AVAY included — simply don't run their AI features in E2EE mode.
There's some overhead from per-device encryption and from re-keying the whole group whenever someone joins or leaves, which can add latency on calls with frequent membership changes. For a stable, small group it's usually not noticeable; for a large call with people constantly dropping in and out, the re-keying cost adds up.
Usually not. Most compliance frameworks are satisfied by standard transport encryption plus access controls, audit logs, and data-handling policies — they assume the provider is a trusted processor, not an adversary. E2EE addresses a narrower and less common threat: the provider itself being compromised or compelled to hand over content.
End-to-end encryption protects a call from the provider itself — but the provider is exactly what runs transcription, notes, search, and any AI participant, so turning E2EE on and keeping those features on is not actually a choice you get to make.
Meetings that take their own notes, in the browser: avay.ai.