End-to-End Encryption for Video Conferences

This page is written for the security and compliance teams of our enterprise customers. It describes how end-to-end encryption (E2EE) works on our video conferencing service, what it protects, what it does not, and how to enable it.

This page covers video conferences only. Encryption for point-to-point voice calls that bridge to the public phone network is a separate topic and is summarised at the end of this page.

At a glance

• Standard encryption (always on): every video conference is encrypted in transit using DTLS-SRTP, the encryption mandated by WebRTC and used by every modern browser. Media and signaling traffic between your users and our infrastructure is never sent in the clear.
• End-to-end encryption (opt-in): when E2EE is enabled for a conference, media content is additionally encrypted with a key that our servers do not possess. The conferencing server forwards encrypted media between participants without ever being able to decrypt it.
• How to enable it: E2EE is an opt-in setting that the meeting host turns on. It is not on by default.
• What it protects: the content of the audio and video streams between participants in the conference.
• What it does not protect: metadata about the call (participants, timing, packet sizes), the integrity of the participant list, or the contents of any participant who joins through a recording bot or phone dial-in.

Background: how a standard video conference is encrypted

To understand what E2EE adds, it helps to know what is already in place without it.

Our video service uses a Selective Forwarding Unit (SFU) architecture. Each participant's browser establishes its own encrypted media session directly with our conferencing server. The server receives encrypted media from each participant and forwards copies of it to the other participants. It does not mix or re-encode streams.

Each of those sessions is encrypted using DTLS-SRTP, the standard encryption protocol for WebRTC. The key exchange and the cipher are mandated by the browser, and the keys are negotiated freshly for every call and discarded when the call ends. Signaling traffic between your browser and our backend is protected separately by TLS.

This baseline protects all media in transit between any user and our infrastructure. It does not protect media from being read on our conferencing server itself: because the server must terminate each session in order to route media between participants, it sits inside the encryption boundary. A baseline (non-E2EE) conference therefore relies on the operational controls we apply to our servers (access management, hardening, audit logging, and so on) to keep media content private.

E2EE is the layer that removes that reliance.

What E2EE adds

When E2EE is enabled for a conference, the sending participant's browser performs a second layer of encryption on each media frame before the standard WebRTC encryption is applied. The keys for this layer are derived inside the participant's browser and shared only among the conference participants — not with our servers.

When our conferencing server receives a frame, it can still read the routing information that lets it forward the frame to the right participants (which user the frame came from, the size and ordering of packets, basic codec metadata). It cannot read the audio or video content.

Without E2EE

Your browser establishes an encrypted session with our conferencing server. The server holds the keys for that session, decrypts each media frame in order to route it, and re-encrypts it on the way to each other participant. Media content is readable on the server, and customers must rely on our operational controls to keep it private.

With E2EE

Your browser applies an additional, inner layer of encryption to each media frame before the standard WebRTC encryption is applied. The keys for the inner layer are held only by the conference participants. The conferencing server can still decrypt the outer (transport) layer to read routing headers and forward each frame to the right destinations, but the inner layer remains encrypted end to end. The server cannot read media content.

E2EE turns our service into a transport for opaque media payloads. Even an operator with full access to a conferencing server, or an attacker who compromises one, cannot read the audio or video of an E2EE conference.

How to enable E2EE

See how to enable end to end encryption at this article - https://support.callbridge.com/support/solutions/articles/42000101939-encryption-explained#What-is-encryption-and-why-is-it-important?

E2EE is opt-in per conference. The meeting host enables it from within the conference, after which it remains active for the duration of that conference. It is not enabled by default.

When E2EE is active, the participant interface indicates this clearly so users can verify the encryption state at a glance.

E2EE can be enabled by any host whose plan includes it. If your organisation requires E2EE to be available — or to be required — for specific user groups, contact your account team to configure that as part of your tenant settings.

What E2EE protects, in detail

E2EE protects the encoded media payload of every audio and video stream exchanged in the conference. The encryption is applied per frame, using AES in Galois/Counter Mode (AES-GCM), an authenticated encryption algorithm. Every frame is integrity-protected: a tampered frame fails to decrypt and is dropped by the receiver.

Specifically, this means the following are unreadable to anyone who does not hold the conference key, including our own infrastructure:

• The audio of every spoken word in the conference.
• The video of every participant who has their camera on.
• Any screen content shared during the conference.

The encryption keys are generated and managed inside participants' browsers and never leave the participant devices in a form our servers can read.

What E2EE does not protect

We want to be precise about this, because overstating the protection would be worse than not offering it.

Metadata about the call

E2EE encrypts the content of the streams, not the framing around them. Our conferencing server still observes:

• Which user is sending or receiving, when, and for how long.
• The size and timing of each media packet, which can correlate with whether a participant is speaking or quiet.
• Which participant is the active speaker at any given moment (this information is signalled in headers used for layout selection).
• Connection quality information used for routing decisions.

This metadata is necessary for the server to do its job as a media router. It is protected by the same operational controls that apply to any other data we process, but it is not end-to-end encrypted.

Integrity of the participant list

E2EE protects media against the server; it does not protect against a compromise of the signalling layer that establishes who is in the meeting. An attacker with the ability to forge a meeting invitation, hijack an account, or compromise our signalling infrastructure could in principle cause an extra participant to join an E2EE conference and receive the key like any other legitimate participant. Customers who care about this risk should use the same authentication controls (SSO, meeting passwords, lobby/waiting room, host approval) that they would use for any sensitive meeting.

Participants who join through a server-side component

Some features by their nature require a server-side participant to decode media, and are therefore incompatible with E2EE on a given call:

• Cloud recording. A recording bot is a server-side participant that must decode media to write it to storage. E2EE prevents this. A conference that is recorded cannot also be end-to-end encrypted on the recording.
• Phone dial-in / dial-out (PSTN). A dial-in participant arrives via a server-side gateway that must decode media to convert it to a telephone call. That gateway cannot read E2EE-protected media, so PSTN participation is not available in an E2EE conference.
• Live captions / transcription that we provide. These features rely on a server-side speech-to-text component. They are not available in an E2EE conference unless transcription is performed client-side on the participant device.

When a host enables E2EE, the in-call interface communicates these limitations clearly so users can make an informed choice.

Endpoint security

E2EE protects the conference against the network and against our infrastructure. It does not protect against compromise of a participant's own device. If a participant's machine is infected with malware, or if a screen recorder is running on it, the content of the conference can be captured at the endpoint regardless of how the wire is encrypted.

Underlying technology

For security teams that want the specifics, the implementation is based on the open-source lib-jitsi-meet library and follows the design documented at github.com/jitsi/lib-jitsi-meet/blob/master/doc/e2ee.md.

The salient points:

• Cipher: AES-GCM, an authenticated encryption with associated data (AEAD) cipher.
• Frame transform: the encryption is applied using the browser's WebRTC Encoded Transform API (also known as Insertable Streams). This API exists for exactly this purpose: to allow a layer of encryption to be applied between the encoder and the network transport, transparently to the underlying WebRTC stack.
• Per-conference keys: keys are generated within participants' browsers, are unique to each conference, and are rotated when participants join or leave to ensure that a participant who leaves a meeting cannot decrypt media sent after their departure.
• Key exchange: the keys are distributed among participants over the signalling channel, which itself is protected by TLS, and is authenticated by the signed identity each participant presents.
• No key escrow. We do not retain copies of conference media keys. We cannot decrypt an E2EE conference under any circumstance, including legal compulsion. We can produce metadata about the call (timing, participants, traffic patterns) but not its content.

The implementation is open-source and reviewable. Security teams who require a deeper technical review are welcome to inspect the lib-jitsi-meet source directly, and to contact our security team for a longer briefing.

Compatibility

E2EE relies on the WebRTC Encoded Transform API, which is supported in recent versions of all major browsers. The minimum versions required to participate in an E2EE conference are listed below.

These versions are the floors at which the WebRTC Encoded Transform API became available without an experimental flag. Older browsers do not support E2EE; participants on an unsupported browser cannot join an E2EE conference, and the host's interface will indicate this if a participant attempts to join.

Internet Explorer and legacy (non-Chromium) Edge are not supported for E2EE — these browsers do not support WebRTC features required by the implementation.

Native mobile clients, where we provide them, implement E2EE using the same wire format.

Standards alignment and audit

The cryptographic primitives used — AES-GCM, HKDF-SHA-256, and the WebRTC DTLS-SRTP suite — are well-established standards. They are widely deployed, peer-reviewed, and form the basis of the encryption used by major messaging and conferencing platforms.

The underlying library is open-source and developed in public. We track upstream releases and apply security updates promptly. Independent assessments of our overall security posture, including encryption controls, are available under NDA — contact your account team for the most recent SOC 2 report and security questionnaire responses.

Contact

For deeper technical questions, security questionnaires, or to discuss configuration options for your tenant — including making E2EE the required default for specific user groups — contact your account team or our security team directly.