Video Conferencing Security: Risks, Best Practices, and How Encryption Works

Video conferencing security refers to the technical and organisational measures that protect virtual meetings from unauthorised access, data interception, and privacy violations. It covers three core areas: encryption (protecting data in transit and at rest), access control (ensuring only authorised participants can join), and infrastructure (where your data is processed and stored).

If you use video calls for anything sensitive – client meetings, medical consultations, board discussions, HR conversations – the security of your platform isn't optional. A poorly secured video call is an open door. 

Table of contents

1. Why video conferencing security matters more than ever
2. The most common video conferencing security threats
3. How encryption protects video calls
4. Authentication and access control
5. Infrastructure and data residency
6. Security checklist for organisations
7. How to evaluate a video conferencing platform's security
8. How Digital Samba approaches video conferencing security
9. FAQ

Why video conferencing security matters more than ever

The scale of cybercrime keeps growing. The FBI's Internet Crime Complaint Center (IC3) recorded over 859,000 complaints and $16.6 billion in reported losses in 2024 alone – a 33 per cent increase from the previous year. Phishing and spoofing were the most reported crime types, with over 193,000 complaints.

Video conferencing isn't immune to these threats. As remote and hybrid work became standard, video calls became a routine channel for sharing confidential information – financial data, intellectual property, personal health records, legal discussions. That makes them a target.

At the same time, regulatory pressure has increased. The EU's General Data Protection Regulation (GDPR) imposes strict rules on how personal data is processed during video calls. The NIS2 directive, which took effect in 2024, extends cybersecurity obligations to a wider range of organisations. In the US, HIPAA governs video conferencing in healthcare, and sector-specific regulations apply in finance and government.

The result: organisations can't treat video conferencing security as an afterthought. It needs to be part of the broader cybersecurity strategy from day one.

The most common video conferencing security threats

Understanding the threats helps you evaluate whether your current platform addresses them. Here are the ones that matter most.

Meeting hijacking

Uninvited participants joining a call – sometimes called 'Zoombombing' after the wave of incidents in 2020 – remains a risk on any platform that relies on shared meeting links without additional access controls. The disruption ranges from nuisance interruptions to exposure of confidential discussions.

Man-in-the-middle attacks

If the connection between a participant and the video conferencing server isn't properly encrypted, an attacker positioned on the network path can intercept and potentially alter the communication. This is why transport-layer encryption (TLS) is the minimum standard, and why end-to-end encryption matters for sensitive calls.

Credential theft and unauthorised access

Stolen or weak passwords remain a top attack vector across all digital services. For video conferencing, this means attackers gaining access to meeting rooms, recordings, or admin dashboards. Multi-factor authentication and scoped access tokens reduce this risk significantly.

Unencrypted media interception

When audio and video streams travel over the internet without encryption, they can be captured by anyone with access to the network path. Modern platforms use DTLS-SRTP (Datagram Transport Layer Security – Secure Real-time Transport Protocol) to encrypt media in transit, but not all platforms enable this by default.

Recording and data exfiltration

Recordings stored without encryption at rest, or accessible without proper authentication, are a liability. If an attacker gains access to a recording server, they gain access to every conversation stored on it.

Phishing via meeting invitations

Attackers send fake meeting invitations that mimic legitimate platforms, directing recipients to malicious sites designed to steal credentials. This is particularly effective because meeting invitations are routine and often clicked without scrutiny.

How encryption protects video calls

Encryption is the foundation of video conferencing security. There are three layers to understand, and they serve different purposes.

Transport encryption (TLS and DTLS-SRTP)

Transport Layer Security (TLS) protects signalling data – the information exchanged when setting up and managing a call. DTLS-SRTP protects the actual audio and video streams during transmission.

Together, these protocols stop anyone on the network path from intercepting or tampering with your call. TLS 1.3 is the current standard; platforms still running TLS 1.0 or 1.1 are using protocols with known vulnerabilities.

Transport encryption operates hop-by-hop. This means the media server (the infrastructure that routes video streams between participants) can technically access the unencrypted content as it passes through. For most business calls, this level of protection is sufficient. For highly sensitive communications, you need the next layer.

For a deeper technical explanation of how these protocols work together, see our guide to WebRTC security.

End-to-end encryption (E2EE)

End-to-end encryption adds a layer on top of transport encryption. With E2EE, media is encrypted on the sender's device and can only be decrypted on the receivers' devices. The server in the middle – even if it's operated by the platform provider – sees only ciphertext. It cannot access, inspect, or record the content.

In a well-implemented E2EE system, each participant generates encryption keys locally. When a participant leaves, keys are rotated so they can't decrypt future communication (forward secrecy). When a new participant joins, they can't decrypt anything that was said before they arrived (backward secrecy).

E2EE comes with trade-offs. Because the server can't access the content, server-side features like cloud recording, live transcription, and AI-generated captions are typically unavailable in E2EE mode. Organisations need to decide which sessions require E2EE and which can use transport encryption with server-side features.

For a detailed look at how E2EE works in WebRTC-based platforms, see our article on end-to-end encryption in WebRTC.

Encryption at rest

Encryption at rest protects stored data – recordings, chat logs, shared files – when it's sitting on a server. AES-256 is the industry standard. Without encryption at rest, anyone who gains access to the storage system (through a breach, misconfigured permissions, or insider threat) can read the stored content.

Authentication and access control

Encryption protects data. Access control protects the meeting itself.

Token-based authentication

Rather than relying on meeting links alone, secure platforms use tokens – short-lived, scoped credentials that grant access to a specific session for a specific participant. Tokens can be configured to expire after a set time, tied to a specific user identity, and restricted to specific permissions.

This approach is especially important for platforms used via API integrations, where meeting access is managed programmatically. For a practical walkthrough, see our guide to securing virtual meetings with token authentication.

Role-based access control (RBAC)

RBAC assigns different permissions to different participants. A host might be able to mute others, share screens, and start recording. A standard participant might only be able to view shared content and use chat. A moderator sits somewhere in between.

The key is that these roles are enforced server-side, not client-side. If a platform only enforces roles in the user interface, a technical attacker could bypass them. Server-side enforcement means the server refuses to execute actions that a participant's role doesn't permit.

Meeting-level controls

Practical controls like waiting rooms (where the host manually admits participants), meeting locks (preventing new joins after a certain point), and unique meeting IDs per session all reduce the risk of unauthorised access.

Infrastructure and data residency

Where your video conferencing data is processed and stored is a security decision, not just an operational one.

Under GDPR, transferring personal data outside the EU requires specific legal mechanisms (like Standard Contractual Clauses) and risk assessments. For organisations in regulated industries – healthcare, legal, finance, government – data residency requirements can be even stricter.

This means the physical location of your platform's servers matters. A platform hosted on US hyperscaler infrastructure (AWS, Azure, GCP) processes data through US-owned systems, even if the data centre is in the EU. Some organisations require infrastructure that is both located in the EU and operated by EU-owned providers.

Related to infrastructure is the concept of data center sustainability – ensuring that the physical infrastructure supporting your video calls is not only secure but also energy-efficient and responsibly managed for long-term server uptime and reliability.

For a deep dive on GDPR requirements specific to video calls, see our guide to GDPR-compliant video conferencing.

Security checklist for organisations

Here are concrete steps to improve your video conferencing security posture.

1. Verify your platform's encryption. Check whether TLS 1.3 is supported, whether media streams use DTLS-SRTP, and whether E2EE is available for sensitive calls. Ask your provider for specifics – 'we use encryption' is not enough.

2. Enable multi-factor authentication. For all accounts that can create or manage meetings, MFA should be mandatory. Authenticator apps are more secure than SMS-based codes.

3. Use unique meeting IDs and access codes. Never reuse meeting links for recurring sessions. Generate new IDs and require passwords or tokens for each session.

4. Restrict recording access. Recordings should be encrypted at rest and accessible only to authorised users. Set retention policies and delete recordings when they're no longer needed.

5. Enforce role-based permissions. Hosts should control who can share screens, use the microphone, access chat, and download shared files. These permissions should be enforced server-side.

6. Keep software updated. Delays in applying security patches leave known vulnerabilities open. Enable automatic updates where possible.

7. Train your team. Phishing attacks targeting meeting invitations are common. Employees should know how to verify legitimate invitations and report suspicious ones.

8. Review your provider's data processing agreements. Under GDPR, your video conferencing provider is a data processor. You need a Data Processing Agreement (DPA) that specifies what data is collected, where it's stored, how long it's retained, and who the sub-processors are.

9. Check data residency. Know where your provider's servers are located and who owns the infrastructure. This is especially important for organisations subject to GDPR, HIPAA, or NIS2.

10. Test your incident response. Know what your provider's incident notification timeline is. Under GDPR, data breaches must be reported to the supervisory authority within 72 hours. Your internal process needs to support that.

How to evaluate a video conferencing platform's security

When comparing platforms, ask these questions:

• What encryption protocols are used for signalling, media transport, and storage?
• Is E2EE available? How are keys generated, exchanged, and rotated?
• Where is the production infrastructure hosted? Who owns it?
• Is a Data Processing Agreement available? What are the sub-processors?
• What authentication methods are supported (tokens, SSO, MFA)?
• Are roles enforced server-side or client-side only?
• What certifications does the provider hold (ISO 27001, SOC 2, etc.)?
• What is the incident response and breach notification process?
• Can recordings be encrypted at rest and access-controlled?
• Is there a published security whitepaper or trust centre?

How Digital Samba approaches video conferencing security

Digital Samba's security architecture is documented in a published Security White Paper (March 2026). Here are the specifics.

• Encryption in transit: All connections use TLS 1.3 where supported, with TLS 1.2 as the minimum. TLS 1.0 and 1.1 are disabled. Media streams are protected with DTLS-SRTP. HSTS (HTTP Strict Transport Security) is enforced on all web-facing services.

• Encryption at rest: All stored data – recordings, chat messages, shared files, and backups – is encrypted using AES-256-GCM.

• End-to-end encryption: E2EE is available as an optional feature. When enabled, media is encrypted on each participant's device using AES-256-GCM via the Web Crypto API before it leaves the browser. The media server (a Selective Forwarding Unit, or SFU) receives and forwards only ciphertext – it cannot inspect, transcode, or analyse content. This is an architectural constraint, not a policy one. Keys are rotated when participants join or leave, providing both forward and backward secrecy. An in-session security code allows participants to verify that all share the same encryption context.

• Access control: The platform supports role-based access control (host, moderator, participant) enforced server-side. The API uses scoped tokens with configurable expiry for session-level authentication. Customers manage their own API key lifecycle through the developer dashboard.

• Infrastructure: Production runs on Leaseweb Netherlands (Amsterdam) and Scaleway (France, Netherlands, Poland) – all EU-based, EU-owned infrastructure. Backup and disaster recovery is on Leaseweb Deutschland (Frankfurt). No application or session data is stored outside the EU. DNS is managed via AWS Route 53 for name resolution only; no application data is involved.

• Compliance: Digital Samba is a GDPR data processor with a designated Data Protection Officer. A DPA is available. Records of Processing Activities are maintained. The company is building an ISMS around ISO 27001:2022 as a reference framework.

• Monitoring: Daily backups with 90-day retention and quarterly restoration testing. Incident response follows a four-tier severity classification, with CISO notification within one hour for critical incidents and supervisory authority notification within 72 hours for personal data breaches.

View the full Security White Paper | Contact our team for a DPA or supplementary compliance documentation.

FAQ