Encryption Overview

1. Introduction

Encryption is a core control in how Vexaro protects the Service and the data Processed in connection with it. This document describes the encryption model Vexaro applies: how data is protected in transit and at rest, the path that remote-session media may take, what is and is not visible to a relay, and how keys are handled at a high level. Exact protocol versions, providers, and deployment details may vary by Product, plan, environment, and configuration.

The facts in this document describe the general cryptographic model used by the Service. Encryption reduces risk but is one control among many; this document does not claim that the Service is unbreakable or fully “zero-knowledge” (see Section 7). Defined terms have the meaning given in the Terms of Service. If this document conflicts with an Order Form, the Order Form controls; otherwise the order of precedence in the Terms of Service applies.

2. Encryption in Transit

Vexaro protects data in transit with standard, widely deployed transport encryption, selected according to the channel and deployment model:

• API and Agent traffic. Connections between Vexaro Agents, Vexaro applications, and the Vexaro control plane are protected with transport encryption designed to provide confidentiality and integrity for data moving between Customer devices and Vexaro-operated systems.
• Edge provider. Traffic to Vexaro’s websites, API, and browser viewer reaches Vexaro through its edge provider, Cloudflare (listed in the Subprocessor List), which terminates TLS at its edge: that traffic is decrypted there and passed on to Vexaro’s servers over a separate encrypted connection. This includes the session media of browser-viewed sessions (see below). Direct and relayed sessions between Vexaro apps do not pass through the edge provider.
• Remote-session media. Remote-session media between Vexaro apps is encrypted end-to-end, whether it travels directly (peer-to-peer) or through a relay because a direct connection cannot be established: the two devices agree the keys of each session and no Vexaro component holds them. This needs version 0.2.13 or later of the Vexaro app on both devices; where one of them runs an older version, a relayed session is encrypted with a key the relay supplies and is not end-to-end encrypted against the relay (see Section 5).
• Browser viewer. When the viewer is a web browser, the session always uses the relay, and a Vexaro server component (the browser bridge) joins the session on the browser’s behalf, opens the session media, and forwards it to the browser over TLS, which the edge provider terminates. Browser-viewed sessions are therefore not end-to-end encrypted against Vexaro, and their media is also decrypted at the edge provider (see Section 4).
• Vexaro Mesh. Vexaro Mesh is in development and no Mesh client is available yet; its traffic is planned to run in encrypted tunnels.

Exact protocol versions and cipher suites are implementation details that may change as the Service is updated, hardened, or deployed in different environments. Vexaro does not publish operational key hierarchies, rotation schedules, or low-level cryptographic configuration in this public document.

3. Encryption at Rest

Vexaro encrypts these stored fields at rest: multi-factor authentication secrets; webhook, directory-connector, and single sign-on client secrets; and the email address in each account record. Database backups are encrypted before they leave the database server. Other stored data, including the details and timelines of Recordings, is not encrypted at rest by Vexaro. Encryption at rest protects stored data against exposure of the underlying storage media; it does not, by itself, control who is authorised to read data through the Service. That is governed by access controls, described in the Security Overview.

4. Remote-Session Media Path

Remote sessions (Vexaro Desk) are established and carried as follows:

1. Signaling. Connection setup (the exchange of the information the two endpoints need to find and authenticate each other) is coordinated through the Vexaro backend (signaling). Signaling establishes the connection; it is the negotiation channel, not the media channel.
2. Direct peer-to-peer when possible. Where the network allows it, media flows directly between the two participating devices over an encrypted media channel, without passing through a Vexaro media server.
3. Relay when peer-to-peer is not possible. Where the network does not allow a direct connection (for example, because of restrictive NAT or firewalls), the session is carried over a relay service selected for the relevant deployment. Between Vexaro apps of version 0.2.13 or later the relay forwards end-to-end encrypted data it cannot read; for older versions it is technically capable of accessing relayed content (see Section 5).
4. Browser viewer. When the viewer is a web browser, the session always takes the relay path, and a Vexaro server component (the browser bridge) joins it on the browser’s behalf: it opens the session media and forwards it to the browser over TLS, which the edge provider terminates (Section 2). The bridge does not store session content; it records only metadata (for example, that a clipboard item of a given size was synchronised) in the audit log.

Between Vexaro apps, media is encrypted end-to-end in the direct (peer-to-peer) case and in the relay case alike, and no Vexaro component holds the session keys; only where one of the devices runs a version of the app older than 0.2.13 is a relayed session encrypted with a key the relay supplies, and so not end-to-end encrypted against the relay. A browser-viewed session is not end-to-end encrypted against Vexaro, because the browser bridge opens its media to deliver it to the browser. Live session media is not stored by Vexaro, and when the Customer turns session recording on, the recording files stay on the Customer’s computers (see Section 7).

5. What the Relay Can and Cannot See

When a relay is used, it is important to be precise about its role and what it is and is not capable of.

The relay can see (connection metadata):

• the network addresses (IP addresses) and ports of the connecting endpoints;
• the timing, size, and volume of the encrypted packets it forwards;
• the fact that a relayed connection exists and how long it lasts.

What the relay can access:

• Between Vexaro apps of version 0.2.13 or later on both devices: nothing of the content. The two devices agree each session’s keys through the signed connection setup, and the relay only forwards data sealed with those keys, which it does not have.
• Where one of the devices runs an older version of the app: the session is encrypted with a key the relay supplies, so a relayed session is not end-to-end encrypted against the relay, and the relay is technically capable of accessing its content, including the screen image, keystrokes and mouse input, and anything else exchanged during it.
• A browser-viewed session is opened by the browser bridge (Section 4), not by the relay.

Vexaro does not store or inspect the content of live sessions in the ordinary course of operating the Service; the browser bridge described in Section 4 opens browser-viewed sessions only to deliver them to the browser. Connection metadata that Vexaro retains, and for how long, is described in the Privacy Notice.

6. Key Management

Session keys are per connection: each session uses its own keys, rather than a single long-lived key reused across sessions. Between Vexaro apps the two devices agree them for each session through the signed connection setup, so the keys never leave the two devices.

For the security of the Service, this document describes key management at a high level and does not disclose key hierarchies, rotation schedules, or other operational detail whose publication could weaken the protections it describes. Business customers with a specific assurance need may request further detail under the process described in the Security Overview.

7. Live Sessions vs Recordings

Encryption protects live sessions, and recording does not change what Vexaro stores:

• Live session media is encrypted in transit and is not stored by Vexaro. Between Vexaro apps the media is encrypted end-to-end, whether the devices connect directly (peer-to-peer) or through a relay because a direct connection is not possible: the two devices agree the keys of each session, no Vexaro component holds them, and a relay forwards data it cannot read. This needs version 0.2.13 or later of the Vexaro app on both devices; where one of them runs an older version, a relayed session is encrypted with a key the relay supplies and is not end-to-end encrypted against the relay; a browser-viewed session is opened by the browser bridge (Section 4). Vexaro does not store or inspect the content of live sessions, and the video of a Recording stays on the Customer’s computers.
• Session recording is off unless the Customer turns it on. On the Team, Business, and Enterprise plans (including the Team trial), an owner or administrator of the Customer’s organisation can turn recording on in the administrative console and choose where the recording files are kept: on the computer that is accessed, on the operator’s computer, or on both. The operator’s computer keeps a copy only when the operator connects with the Vexaro Windows app and is a member of the Customer’s organisation; otherwise the computer that is accessed keeps the file. The files are written on those computers by the Vexaro Windows app (version 0.2.15 or later; older versions do not record) and are never uploaded to Vexaro. Vexaro stores only each Recording’s details (the session, the time, which computer keeps the file and where on it, its size and duration) and its event timeline, retained for the recording-retention period of the Customer’s plan; each time the Vexaro app finishes a recording on a computer, it deletes the recording files older than that period from its recordings folder there. Recording files are protected by the permissions of the computers that keep them.

For this reason Vexaro does not describe the Service as fully “zero-knowledge.” The Customer is responsible for notifying its End Users about remote access, monitoring, logging, and recording, and for having a lawful basis to do so. How Recordings are treated is described in the Recording & Monitoring Notice and the Privacy Notice.

8. Self-Hosted Considerations

In a Self-Hosted Deployment, the Customer installs and operates the relevant Vexaro components on its own infrastructure. The in-transit and media-path encryption model described above continues to apply to the connections themselves where supported by the self-hosted configuration, but the Customer controls the surrounding environment. That includes the relay it operates (for example, a self-operated relay), key and secret storage, the configuration of storage and backups, and the encryption of data at rest on infrastructure the Customer runs. The division of responsibility for Self-Hosted Deployments, including these encryption-related elements, is set out in the Self-Hosted Responsibility Matrix.

Contact

For questions about encryption or to request further security assurance documentation:

• Security reports / vulnerability disclosure: [email protected]
• Privacy / data-protection contact: [email protected]

Contracting and notice details are provided on invoices and Order Forms.

---

This document is part of the Vexaro Legal Center.