An end-to-end encryption video call encrypts media on participant devices, so intermediaries route ciphertext without holding the decryption key. VideoSDK supports client-side, room-level E2EE with one shared key for audio, video, and screen-share tracks. Recording and transcription remain unavailable while E2EE is enabled.
An end-to-end encryption video call solves a precise trust problem. Your real-time communication provider should carry media without being able to watch or hear it.
VideoSDK implements this boundary by encrypting media on participant clients before its infrastructure routes the call. Only clients holding the shared room key can recover protected media.
This guide explains the WebRTC security boundary, shared and per-sender key architectures, a React implementation, performance considerations, feature trade-offs, and a production checklist.
What Is an End-to-End Encryption Video Call?
A true E2EE video call keeps usable media keys only on authorised participant devices.
An end-to-end encryption video call is defined as a real-time call whose media is encrypted by the sender and decrypted only by authorised receivers. Relays, Selective Forwarding Units (SFUs), network operators, and the calling provider can route encrypted packets without recovering their audio or video content.
An end-to-end encryption video call works by encrypting encoded audio and video frames before network transmission. Recipient clients authenticate and decrypt those frames before decoding and playback.
VideoSDK applies E2EE at room level with one shared key for the room's media tracks. Its React E2EE documentation states that the application owns key generation, management, and distribution.
This boundary matters because E2EE protects call content, not every associated data point. The NIST definition of end-to-end encryption notes that routing information can remain visible while communication data stays encrypted.
E2EE also cannot protect an already compromised endpoint. Malware, screen-capture software, a malicious participant, or an unlocked device can access media after legitimate decryption.
How an End-to-End Encryption Video Call Works
An E2EE call adds a client-controlled media-encryption layer above WebRTC's encrypted transport.
- Authorise the participant. Your application authenticates the user, checks room membership, and issues a short-lived VideoSDK meeting token scoped to the room and participant.
- Distribute the media key securely. Your backend creates or retrieves the room's E2EE key and returns it only after a separate authorisation check.
- Encrypt media on the sender. The client captures and encodes microphone, camera, or screen-share data, then encrypts each encoded frame before transmission.
- Route ciphertext through the SFU. VideoSDK infrastructure forwards encrypted media to subscribed participants without receiving the application's room key.
- Decrypt on authorised receivers. Each recipient authenticates and decrypts frames with the room key, then decodes and renders the media.
- Monitor encryption state. The application watches participant encryption events and blocks protected media when a key is missing, invalid, or unusable.
The IETF SFrame standard, RFC 9605, describes this two-layer pattern for multiparty media. An SFU can read routing metadata while remaining unable to access media content.
SFrame is a useful standards model, not a claim about VideoSDK's internal cipher format. VideoSDK's public React guide documents the supported key-provider API and security boundary.
The practical result is a scalable multiparty route where the SFU forwards streams without receiving usable media plaintext.
End-to-End Encryption Video Call vs WebRTC Security
WebRTC encrypts media transport by default, but transport encryption does not always keep media unreadable to an SFU.
The IETF WebRTC Security Architecture, RFC 8827, requires secure real-time media. Its requirement is direct: “Media traffic MUST NOT be sent over plain RTP.”
In a direct peer connection, encrypted transport can extend from one participant to the other. In a multiparty SFU topology, clients usually establish separate secure transport legs with the SFU.
Application-layer E2EE encrypts the encoded frame before those transport legs. The SFU receives information needed for forwarding, but not the key needed to recover media.
| Security question | WebRTC transport encryption | Application-layer E2EE |
|---|---|---|
| Where is media encrypted? | Across each secure transport leg | On the sender before intermediaries receive media |
| Can the network read media? | No | No |
| Can an SFU read media payloads? | Potentially, if it terminates transport encryption | No, if it never receives the E2EE key |
| Can routing metadata remain visible? | Yes | Yes |
| Can server media processing work? | Usually yes | Only if a trusted processing endpoint receives a key |
| Who manages media keys? | WebRTC endpoints and transport protocols | The application controls E2EE key distribution |
| VideoSDK role | Provides secure real-time transport | Offers optional room-level media E2EE |
The critical question is not whether packets are encrypted. It is which systems hold a key that can decrypt the call's media.
How Does VideoSDK Handle Video Call E2EE?
VideoSDK applies client-side E2EE to room media while leaving key ownership with your application.
According to the VideoSDK E2EE guide, one shared room key encrypts and decrypts media tracks. Participants without that key cannot access those tracks.
The guide also states that VideoSDK never stores, accesses, or transfers encryption keys. Your backend must create, authorise, deliver, expire, and replace room keys according to your threat model.
Supported VideoSDK SDKs
VideoSDK documents these minimum versions for E2EE support. They are minimum compatible versions, not recommendations to install an old release.
| SDK | Minimum E2EE version |
|---|---|
| React Native | 0.2.1 |
| iOS | 2.2.2 |
| Flutter | 2.1.0 |
| React | 0.3.5 |
| Android | 0.5.0 |
| JavaScript | 0.2.6 |
This table was checked against VideoSDK's E2EE page on 11 August 2026. The page tracks React SDK version 1.x.x and was last updated on 10 July 2026.
Use the current supported release for your platform and repeat cross-device E2EE tests after every SDK upgrade.
The Exact Protection Boundary
VideoSDK E2EE covers media, including audio, video, and share tracks. Chat, metadata, API calls, and signalling data remain outside the E2EE boundary, although TLS protects them in transit.
Recording and transcription are not supported while VideoSDK E2EE is enabled. Those services require access to media that the documented E2EE model keeps unavailable to VideoSDK servers.
This is a credible privacy boundary, not a promise that every byte associated with a meeting becomes invisible.
Shared Key vs Per-Participant Key Encryption
VideoSDK currently documents a shared room key, while per-sender keys represent a different and more complex key-management architecture.
The phrase per-participant key usually means each sender encrypts their outgoing media with a distinct sender key. Every authorised receiver then needs the active key for every sender it may decrypt.
That design can support granular membership changes, but it multiplies key delivery, rotation, recovery, and device-synchronisation work. It is not a simple security upgrade over a room key.
| Decision factor | Shared room key | Per-sender or per-participant keys |
|---|---|---|
| Key count | One active media key per room | One or more active keys per sender |
| Client setup | Lower complexity | Higher key-ring and rotation complexity |
| Removing a participant | Usually requires replacing the room key | Can support more granular sender-key changes |
| Large-room operations | Fewer secrets to distribute | More secrets and membership events to coordinate |
| Current VideoSDK React documentation | Supported through setSharedKey() | Not documented as a selectable VideoSDK mode |
| Best fit | Trusted groups with strong room membership controls | Custom protocols needing granular sender isolation |
Use VideoSDK's documented shared-key model unless the selected SDK's current documentation says otherwise. If your threat model requires per-sender keys, verify product support with VideoSDK before designing around it.
Never describe an undocumented key architecture as an available configuration switch. Security documentation must match the code customers can actually run.
WebRTC Encoded Transforms and E2EE
WebRTC Encoded Transforms let browser applications modify encoded audio and video frames before they enter, or after they leave, the network pipeline.
The MDN guide to WebRTC Encoded Transforms describes RTCRtpScriptTransform workers attached to RTCRtpSender.transform and RTCRtpReceiver.transform. E2EE is one intended use case.
MDN marks the API as newly baseline across current browsers since October 2025, while warning that older browsers and devices may not support it.
For VideoSDK React, use the documented ExternalE2EEKeyProvider integration instead of writing a custom transform worker. Test the final SDK and browser combination because platform support can differ.
Do not claim that VideoSDK uses a particular cipher or standards profile unless the selected SDK's current documentation states it.
Secure Key Management for Multiparty Calls
The cryptography is only as trustworthy as your key-distribution and participant-authorisation path.
VideoSDK's shared-key model keeps client integration practical. It also means anyone holding the room key can decrypt media, even when their meeting token has narrower permissions.
Treat the meeting token and E2EE key as separate secrets. Possessing either secret should not reveal the other without an application-level identity and membership check.
Generate an ephemeral key for each sensitive room or session. Bind delivery to the authenticated user, room, participant, device policy, and current membership state.
Store server-side keys in a KMS-backed or equivalently protected secret store. Keep client keys in memory where the platform permits, and redact them from observability systems.
Plan revocation before launch. Stop returning the key when access is removed, then use a fresh key for later sessions.
VideoSDK's React guide does not document a portable mid-call rotation workflow. Verify current rotation behaviour across every selected SDK before promising immediate rekeying after a participant leaves.
High-risk products can add an out-of-band room code, verified participant directory, or trusted-device flow. These controls bind a valid key to the intended people.
Strong frame encryption cannot repair weak identity, authorisation, logging, or secret-storage practices.
Does E2EE Affect Video Call Latency?
E2EE adds client-side processing and some frame overhead, but no universal latency number applies across devices, browsers, codecs, and room layouts.
RFC 9605 includes an illustrative two-person SFrame calculation with about 1% total bandwidth overhead. That example is not a VideoSDK benchmark and does not measure client CPU or end-to-end delay.
Modern laptops may show little visible impact, while older phones can struggle with encryption, decoding, effects, and multiple subscribed streams at the same time.
Measure E2EE on your real device matrix. Track join time, glass-to-glass latency, frames per second, CPU, thermal throttling, battery drain, packet loss, and recovery after network changes.
Run each test with E2EE enabled and disabled under identical conditions. Publish your own results only after recording hardware, browser, SDK version, codec, participant count, and network profile.
The honest performance answer is conditional: E2EE overhead may be small, but production acceptance needs device-level evidence.
When Should You Use Video Call E2EE?
Use E2EE when keeping media unreadable to the RTC provider is a documented product requirement.
| Product requirement | Recommended call mode | Reason |
|---|---|---|
| Provider must not decrypt audio or video | VideoSDK E2EE | The application controls the shared media key |
| Cloud recording or transcription is mandatory | Standard encrypted VideoSDK room | Server processing requires media access |
| Sensitive session with no server processing | VideoSDK E2EE | Media confidentiality outweighs processing features |
| SIP bridge or server media bot is essential | Standard encryption or a redesigned trust model | The gateway or bot becomes a trusted endpoint |
| Unknown endpoint security | E2EE plus endpoint controls | Encryption cannot protect a compromised device |
| Granular per-sender key isolation is mandatory | Verify custom architecture or current SDK support | VideoSDK documents a shared room key today |
An end-to-end encryption video call fits telehealth, legal, financial, safeguarding, executive, and research conversations when provider-blind media is required.
Standard transport encryption fits better when recording, transcription, moderation, media conversion, SIP bridging, or automated analysis is essential.
Never downgrade silently. Ask for informed consent, display the active mode, and record the policy decision without logging keys or decrypted media.
E2EE is also not a compliance certificate. HHS telehealth guidance places encryption inside broader risk management, access control, endpoint, recording, and privacy obligations.
Choose the call mode from a threat model, required features, and applicable legal advice rather than a generic “secure” label.
VideoSDK E2EE Features and Trade-offs
VideoSDK E2EE protects media content by giving up server features that require media plaintext.
| Capability | With VideoSDK E2EE | Engineering implication |
|---|---|---|
| Audio, video, and screen-share media | E2EE supported | Only clients with the shared key can decrypt |
| SFU media routing | Supported | VideoSDK routes encrypted media without the room key |
| Chat and metadata | TLS, not E2EE | Do not place media secrets in chat or metadata |
| API calls and signalling | TLS, not E2EE | Keep server authentication and authorisation controls |
| Server-side recording | Not supported | Use another policy or an explicitly trusted recorder |
| Server-side transcription | Not supported | Do not promise server captions or summaries in E2EE rooms |
| Key lifecycle | Application controlled | Your team owns delivery, replacement, and incident response |
The trade-off follows from the trust model. A server cannot remain unable to decrypt media while simultaneously processing that media for recording or transcription.
Some products need both workflows. Use clearly labelled policies: a private E2EE mode for confidential sessions and a processing-enabled mode for consented recording or transcription.
End-to-End Encryption Video Call Security Checklist
A production E2EE launch needs verifiable controls across identity, keys, media, endpoints, operations, and user experience.
- Write the threat model. State whether you protect against network observers, the RTC provider, compromised accounts, malicious participants, or stolen devices.
- Scope meeting tokens. Use short expiry, room ID, participant ID, the
rtcrole, and only the required permissions. - Separate tokens and keys. Never treat a meeting token as an E2EE secret or place the room key in a public URL.
- Authorise key delivery. Check identity, room membership, device policy, and current access before returning the key.
- Protect key storage. Use an encrypted secret store on the server and memory-first handling on clients where practical.
- Fail closed. Block protected media when the key is missing, invalid, or cannot be verified.
- Expose security state. Show whether E2EE is active and surface participant encryption failures accessibly.
- Test membership changes. Cover late joins, reconnects, removals, expired tokens, restored tabs, and second devices.
- Review feature conflicts. Confirm the product does not depend on recording or transcription inside E2EE rooms.
- Secure endpoints. Apply updates, device locks, least privilege, log redaction, malware defence, and appropriate screen-capture rules.
- Log safely. Audit access decisions and state transitions without recording tokens, keys, media, or decrypted frames.
- Retest every release. Run correct-key, wrong-key, missing-key, removal, reconnect, and cross-platform compatibility cases.
This checklist creates evidence that the deployed system matches the words “end-to-end encrypted” instead of relying on a configuration flag.
Telehealth Example Without False Compliance Claims
A fictional telehealth product shows why security mode and feature policy must be designed together.
Imagine CareBridge, an application using VideoSDK React for remote consultations. Its risk assessment requires VideoSDK infrastructure to remain unable to access consultation audio or video.
CareBridge authenticates the clinician and patient through its identity system. The backend checks appointment membership, issues participant-scoped meeting tokens, and releases an ephemeral room key.
The application displays encryption status during the call. If either participant reports MissingKey, InvalidKey, or a cryptor failure, CareBridge blocks protected media.
Because VideoSDK recording and transcription are unavailable with E2EE, CareBridge hides those controls. A future consented transcript would require a separate processing-enabled policy and another risk assessment.
CareBridge still needs device security, access control, audit logs, privacy notices, retention rules, and suitable vendor agreements. E2EE reduces one risk class without completing compliance work.
The design rule is conditional: choose E2EE when media confidentiality outranks server processing, then make that choice visible throughout the product.
Definitions
End-to-end encryption (E2EE): Media protection in which authorised endpoint devices hold decryption keys while intermediaries route ciphertext without reading the content.
DTLS-SRTP: The WebRTC security combination that establishes keys and protects real-time media across a transport connection.
Selective Forwarding Unit (SFU): A media router that receives participant streams and forwards selected streams. With E2EE, it routes encrypted payloads.
Meeting token: A server-generated JWT that authorises a participant to access a VideoSDK room. It is not the room's E2EE key.
Shared room key: The client-held secret used by authorised VideoSDK participants to encrypt and decrypt media tracks in one room.
WebRTC Encoded Transform: A browser API that lets applications process encoded audio or video frames within sender and receiver pipelines.
Key Takeaways for Video Call Security
The right security mode depends on who must remain unable to decrypt media and which processing features your product needs.
- An end-to-end encryption video call encrypts media on participant devices, allowing an SFU to route packets without the application's media key.
- WebRTC mandates encrypted transport, but multiparty calls need a separate E2EE layer when the SFU must remain unable to read media.
- VideoSDK documents room-level E2EE with one shared key across React Native, iOS, Flutter, React, Android, and JavaScript SDKs.
- VideoSDK leaves key generation and distribution to the application, so authentication, secret storage, and failure handling remain your responsibility.
- Recording and transcription are unavailable during VideoSDK E2EE sessions, while chat, metadata, API calls, and signalling remain TLS-protected but outside E2EE.
- E2EE reduces media-access risk without replacing endpoint security, participant verification, audit controls, risk analysis, or legal compliance work.
The most defensible product exposes these boundaries instead of hiding them behind one lock icon.
Sources and Related VideoSDK Guides
Use current product documentation and primary standards when reviewing an encrypted calling design.
- VideoSDK E2EE setup for React documents the room key, React API, state events, supported SDK minimums, and feature limitations.
- VideoSDK authentication and tokens documents token signing, scope, roles, permissions, and expiry.
- VideoSDK React quickstart provides the base meeting flow used before E2EE configuration.
- VideoSDK's general E2EE explainer covers encryption beyond the video-call implementation focus of this guide.
- IETF RFC 8827 defines the WebRTC security architecture.
- IETF RFC 9605 specifies SFrame for authenticated encryption of multiparty real-time media.
- MDN WebRTC Encoded Transforms explains the browser transform pipeline and compatibility boundary.
- NIST E2EE glossary distinguishes encrypted content from visible routing information.
These sources also provide the best refresh path when SDK behaviour, browser support, or security guidance changes.
Conclusion
An end-to-end encryption video call is valuable when your product must keep media unreadable to its RTC provider. VideoSDK provides the room-level client encryption path and observable E2EE states, while your application owns participant trust and key delivery. Start with the VideoSDK React E2EE guide, then create a VideoSDK account to test the flow. What kind of protected video call are you building?
Frequently Asked Questions
Are all WebRTC video calls end-to-end encrypted?
No, not every WebRTC video call is end-to-end encrypted against the service provider. WebRTC mandates encrypted transport, but an SFU can terminate transport encryption unless clients add a separate media E2EE layer.
Does VideoSDK support end-to-end encryption?
Yes, VideoSDK supports room-level media E2EE with a client-held shared key. The current documentation covers React Native, iOS, Flutter, React, Android, and JavaScript SDK minimum versions.
Can VideoSDK decrypt E2EE call media?
No, VideoSDK cannot decrypt media when its documented E2EE setup is configured correctly. Encryption and decryption happen on participant clients, and VideoSDK says it never stores or accesses the room key.
What does VideoSDK E2EE encrypt?
VideoSDK E2EE encrypts audio, video, and screen-share media tracks. Chat, metadata, API calls, and signalling remain outside E2EE, although TLS still protects those communications in transit.
Can VideoSDK record an E2EE video call?
No, VideoSDK's current documentation says recording and transcription are unavailable while E2EE is enabled. Server processing would require access to media that the server-blind model intentionally withholds.
How should an application distribute the E2EE key?
An application should return the room key through an authenticated HTTPS endpoint after verifying identity and room membership. Avoid URLs, logs, analytics, client bundles, and unnecessary persistent storage.
Does E2EE make a video app HIPAA compliant?
No, E2EE alone does not make a video application HIPAA compliant. Regulated teams must also assess identity, access, endpoints, retention, vendor relationships, risk management, and other applicable safeguards.
Does end-to-end encryption increase video call latency?
E2EE adds per-frame client processing, but the effect varies by device, codec, browser, participant count, and network. Measure latency, CPU, battery, and frame rate on your supported device matrix.