Who can see a remote session, really

Every remote access product says "encrypted". They are all telling the truth and it settles less than it appears to, because the interesting question is not whether the traffic is encrypted but who is at the ends of the encryption.

Transport encryption is the floor, not the answer

WebRTC-based tools encrypt media with DTLS-SRTP and cannot be configured not to — encryption is mandatory in the specification. RDP encrypts with TLS. SSH tunnels are encrypted by definition. Plain VNC famously is not, which is why it should always be tunnelled.

So "encrypted in transit" is table stakes and tells you nothing distinguishing. The question that separates products is: does any server in the middle hold keys that let it decrypt the session?

Relayed versus decrypted

These two are easy to conflate and are completely different.

• Relayed. A server forwards packets between two endpoints that negotiated encryption directly with each other. The relay sees ciphertext and cannot read it. A TURN server is this — it moves bytes it has no key for.
• Decrypted server-side. The session terminates at the provider's infrastructure, is decrypted there, and is re-encrypted onward. This is architecturally necessary for features like server-side session recording, and it means the provider can see your screen.

Both are legitimate designs with different trade-offs. The problem is that both are described with the same word, so "we relay your session through our servers" and "your session is decrypted on our servers" can be presented identically to a buyer.

What always leaks, regardless

No architecture hides all of this, and it is worth knowing what remains visible even in the best case:

• That a session happened, between which addresses, when, and for how long.
• Roughly how much data moved, which correlates with what you were doing — video looks different from reading a document.
• Account or device identifiers, if the product has accounts.
• Your IP address and the host's, which implies approximate location for both.

If the fact that you connected to a particular machine is itself sensitive, content encryption is not the property you need, and no remote access product solves it.

The threat that is not the network

Focusing on the wire is a common mistake, because the realistic threats sit at the endpoints.

1. Whoever is at the host. Most remote tools show the desktop on the physical screen too. Someone standing at the machine watches everything you do. Tools that offer a privacy screen blank the local display; if yours does not, assume the room is an audience.
2. Whoever you gave the code to. A session code is a credential. Codes read out on a call, pasted into a group chat, or left visible in a screenshot are a real disclosure path, and codes that do not expire are worse.
3. The host machine itself. Connecting to a compromised machine means everything you type on it — including passwords — is exposed regardless of transport security. Remote access does not protect you from the computer you are using.
4. Session persistence. If a tool allows unattended access, the credential that permits it is the whole security of the machine. That is a much larger commitment than a one-off session with a code that expires.

A short checklist

1. Can any server decrypt the session? Get a direct answer.
2. Is unattended access on, and does it need to be? A code per session is far safer than a permanent credential.
3. Does the host screen show the session locally, and is anyone near it?
4. How is the code delivered, and does it expire?
5. Is there a record of who connected and when — see what your logs should show.
6. Can a session be started without the person at the host agreeing? For support scenarios that should require explicit consent every time.

More guides