Security & IT
Getting AV Software Approved by IT: A Practical Guide
What an IT security review of AV software actually checks, and how to prepare so your tool gets approved first time.
"Is WebRTC secure?" is one of those questions that sounds simple and deserves a proper answer, especially if you are about to run a board presentation, investor call or client pitch through it. The short version is yes, by design, but the honest version explains why, because "it's a web standard" is not actually an argument on its own.
WebRTC is the technology behind most modern peer-to-peer video and control tools, including the connection between a presenter's phone and the computer running their slides in Cliqer. Understanding what it does and does not protect will make you a better judge of any tool that uses it, not just ours.
Key takeaways
- WebRTC encrypts every connection by design, DTLS for data channels, SRTP for media, WSS for signaling, with no unencrypted mode.
- It prefers a direct peer-to-peer path and only falls back to a TURN relay, which forwards encrypted packets it cannot decrypt.
- Encryption in transit does not cover endpoint compromise, room access control or account sign-in, those need separate protections.
What WebRTC actually is
WebRTC, Web Real-Time Communication, is an open standard maintained by the W3C and supported natively in every major browser. It defines how two devices can establish a direct connection to exchange audio, video or arbitrary data, without either side needing to install a plugin. You can read the technical specification and background at webrtc.org.
The key word is "direct." Unlike a video call routed entirely through a company's servers, WebRTC is built to connect two devices to each other as directly as the network allows, only falling back to a relay when a direct path is not possible. That single design choice is why the rest of this article matters: a protocol built around direct connections needs a different security model than one built around a central server, and it is worth understanding both halves before you trust it with a boardroom's content.
Encryption is not optional in WebRTC
This is the part that actually answers the security question. WebRTC does not offer an unencrypted mode. Every WebRTC connection, whether it carries a data channel, audio or video, is encrypted by design:
- DTLS (Datagram Transport Layer Security) secures data channels, the low-latency pipe used for things like slide-advance commands and pointer positions.
- SRTP (Secure Real-time Transport Protocol) secures any audio or video media, such as a screen share or camera feed.
- The initial handshake that sets a connection up, called signaling, runs separately over WSS (WebSocket Secure), so the coordination step is encrypted too, even before the peer-to-peer link exists.
There is no configuration flag to turn this off. It is baked into the standard, which is a meaningfully different guarantee than "we chose to enable encryption," because it cannot be quietly misconfigured.
If a vendor describes their product as "WebRTC-based" as a security selling point, that is table stakes, not a differentiator. The real question is what they do with signaling data and where content is stored, not whether the media itself is encrypted.
Peer-to-peer versus server-routed: why it matters for content
Because WebRTC connects devices directly, an application built on it has a real choice that server-routed tools do not: whether content ever needs to touch a server at all. In Cliqer, slide-advance commands, laser pointer coordinates, timer state and any screen or camera stream travel directly between the presenter's device and the host computer, or through an encrypted relay if a direct path is not available. The application servers coordinate who is in the room; they are never in the media path itself, and your presentation content is never uploaded.
That architecture matters most for anything sensitive: board decks, product roadmaps, unreleased financials. We go deeper on that specific case in presenting confidential content.
Where the relay fits in
Not every network allows a direct connection. Corporate firewalls, hotel Wi-Fi and carrier-grade NAT can all block the direct path WebRTC prefers. When that happens, the connection falls back to a TURN relay, which forwards the same DTLS and SRTP encrypted packets without holding the keys to decrypt them. The relay moves bytes; it cannot read them.
We cover exactly how that fallback works, and why it is not a security downgrade, in TURN servers explained. It is also why corporate firewalls rarely block a well-built WebRTC tool outright, a topic we cover in why corporate firewalls block presentation tools.
| Layer | Protocol | Protects |
|---|---|---|
| Signaling | WSS (TLS 1.2+) | Room coordination metadata, before the peer connection exists |
| Data channel | DTLS | Control signals: slide commands, pointer position, timer state |
| Media | SRTP | Camera and screen share streams, when enabled |
| Relay fallback | DTLS/SRTP over TURN | Same encrypted payload, relayed without decryption at the relay |
What WebRTC does not protect against
Encryption in transit is not the whole security story, and it is worth being honest about what it does not cover:
Endpoint compromise
If a device itself is compromised, encryption in transit does not help. Keep your OS, browser and presentation software updated.
Who you let into the room
WebRTC secures the pipe; access control decides who gets a pipe in the first place. That is a job for team roles and SSO, not the transport protocol.
Metadata
Signaling carries who is in a room and how to reach them, which is coordination data, not presentation content, but it is still worth knowing it exists. See the full breakdown in the data flow diagram.
Who signs in to the account itself
Strong transport encryption does nothing for an account protected by a weak or reused password. Pair it with single sign-on or passkeys for the account layer.
How to verify it yourself
You do not need to take a vendor's word for any of this. A few practical checks:
- Ask for a data flow diagram, not a marketing page, and confirm which flows are peer-to-peer versus server-routed.
- Check whether the app requires inbound firewall rules. A properly built WebRTC app should only need outbound connections.
- Ask what happens on a network that blocks direct connections. There should be an encrypted relay fallback, not a hard failure.
- Read the Security & Networking documentation for the specific ports and protocols in use.
If you are reviewing a tool for an entire team rather than a single call, fold this into the broader security checklist for presentation software, since encryption is one line item among several a proper review should cover.
FAQ
Yes, in the sense that every connection is encrypted by design with no unencrypted mode. Whether an application built on WebRTC is a good fit for confidential content also depends on whether it stores that content anywhere, which is a question about the application, not the protocol.
No. It prefers a direct connection but falls back to an encrypted TURN relay when the network does not allow one, such as behind certain corporate firewalls or symmetric NAT.
No. TURN relays forward encrypted DTLS and SRTP packets without holding the keys needed to decrypt them. They move bytes, not content.
No. A VPN encrypts and routes all of a device's traffic through a third party. WebRTC establishes an encrypted connection for a specific application, ideally directly between the two devices involved, with a relay only as fallback.
Get started
If encryption and peer-to-peer routing matter to how you evaluate presentation tools, read the full security overview, or try Cliqer free and inspect the connection behaviour yourself before you present anything sensitive with it.
WebRTCencryptionsecuritypeer-to-peer
Student Presentations: Classroom Tech That Removes the Friction
Classroom tech that lets students present from their own seat, with no cable swaps or logins eating into class time.
Slide Operator or Speaker Control? Choosing the Right Model
Should a slide operator drive the deck, or should speakers click for themselves? How to pick the right model for your event.
Run your next show with Cliqer
Any slides, any phone, anywhere. The desktop app hosts the room, presenters just open a link.
Keep reading
More security & it for your next show
Security & IT
Presenting Confidential Content: Data Protection for Board Meetings
Keep board presentations confidential: what should never leave your device and how to check where a tool sends data.
Security & IT
Passkeys Explained: Passwordless Sign-In for Busy Teams
Passkeys explained simply: how passwordless sign-in works, why it resists phishing and how to turn it on for your team.
Newsletter
Get the next guide before your next show
Practical guides for presenters, AV crews and event teams, plus the Cliqer releases that matter. No spam, one click to leave.