Security

How Remotle protects the connection between people and their workstations. Written for IT teams, and describing the software as it ships today.

Updated October 2026

Architecture

Software on your own workstations

Remotle is software. The Remotle host runs on workstations you own and manage. The Remotle app runs on the Windows PC, Mac, iPad, Linux PC or zero client that people connect from. Applications, models and project files stay on the workstation and your own storage. Computle has no access to the workstation beyond the host software’s own connections described on this page.

Outbound connections only

The host does not accept connections from the network. It opens an outbound TLS connection to the Remotle connection service and keeps it open. For each session it sends UDP from a port of its own choosing to the address the connection service names, and the only traffic it receives is the reply on that same flow. There are no firewall ports to open or forward, the host never asks the router for a port mapping, and no VPN or gateway is needed. Services on the workstation communicate with each other over named pipes restricted to specific Windows accounts. The host opens no local network ports.

Direct path with relay fallback

When a session starts, the app and the host each learn their public address with a STUN request and send to each other at the same time. If the network allows, the session runs directly between them. If it does not, both ends send to a Remotle relay operated by Computle in London, New York or Canada, whichever is nearest. Relays carry the session as encrypted QUIC traffic. The session keys are held only by the app and the workstation. Each relayed packet carries an authentication code under a per-session key issued by the connection service, and a relay discards any packet that fails that check without replying. Relays apply a bandwidth cap and a duration limit to every session.

Encryption

TLS 1.3 over QUIC

Every session is a QUIC connection between the app and the host. The TLS configuration accepts TLS 1.3 only, with the AEAD cipher suites TLS 1.3 defines. One connection carries video, audio, keyboard, mouse, pen, clipboard and redirected USB traffic. This applies on the office network and over the internet, direct or relayed. The control connection from each end to the connection service uses TLS 1.2 or later with ordinary certificate verification.

Workstation certificates

Each workstation holds its own certificate from Computle’s private certificate authority. The root key is held in a hardware security module and signs only intermediate certificates. Each customer has its own intermediate certificate, constrained to that customer’s names, and its key is held in the same hardware security module. Workstation certificates are valid for 30 days and renew automatically at day 20 with a fresh key pair. The private key is generated on the workstation. Where the workstation has a TPM, the key is created in the TPM as a non-exportable key. Otherwise it is held in the Windows machine key store. The certificate authority receives only the public key.

What the app checks before showing a desktop

During the QUIC handshake the app verifies that the host’s certificate chains to the Computle root built into the app, that its common name is the identifier of the workstation the person asked for, that it names the right customer, that its public key matches the one the workstation registered with the connection service, and that its serial is not on the revocation list the connection service supplied. After the handshake, each end proves knowledge of a per-session secret that the connection service delivered over its own authenticated control connection, combined with keying material exported from the TLS session. A host holding a valid certificate alone cannot complete a session without that secret. If any check fails, the app shows an identity error and does not offer a retry.

Only pixels leave the workstation

The host sends encoded video and audio. Keyboard, mouse and pen input, together with any clipboard content or USB devices a person chooses to share, travel the other way. No files are synchronised to the device the person connects from.

Identity and access

Sign-in

People sign in to the app and the console with Microsoft Entra ID or with Apple. Where Entra ID is used, your own conditional access and multi-factor policies apply at sign-in. The console also provides its own multi-factor authentication using an authenticator app (TOTP) with backup codes, which an administrator can require for a user or for the organisation.

Session tokens

A connection is authorised by a session token issued for one user and one workstation. The token is signed with RSA (RS256), valid for five minutes and usable once. The connection service checks the signature, the expiry, the customer, and that the token’s unique identifier has not been presented before. When a session needs to re-establish its network path, the app obtains a new token without any user interaction. The right to connect to a workstation is a signed grant held in the customer’s identity service, created when an administrator assigns the workstation. Removing the assignment stops new session tokens being issued for it.

Assigned workstations only

Administrators assign workstations to people in the console. People see, and can connect to, only the workstations assigned to them. A token issued for one workstation cannot open another, and a workstation rejects a token issued for a different customer.

Windows sign-in with Entra ID

Where the workstation is joined to your Entra tenant and silent sign-in is enabled for the organisation, the person who connects is signed in to the Windows desktop with the Entra identity they used in the app. The host sends the app a challenge generated by Windows. The app answers with an assertion signed for that device by Entra ID, and Windows validates the assertion and completes the sign-in itself, using the Entra protocol Windows uses for its own cloud-hosted desktops. Remotle does not handle a Windows password at any point. The credential is used once and is cleared from memory afterwards. If any step fails, the normal Windows sign-in screen is shown.

Connecting to a workstation already in use

When someone connects to a workstation that already has a session, their app shows that it is in use and who is using it, and offers two actions: take over the session, or ask the current user to share it. If they ask to share, the current user is prompted and has 30 seconds to answer. A request with no answer, or a connecting app that makes no choice within 10 seconds, results in a take-over. Only people assigned to the workstation can connect in the first place. Only one person’s microphone, webcam and USB devices reach the workstation at a time.

Security keys

FIDO security keys such as YubiKey plugged into the device are recognised as security keys by the USB policy and can be shared to the workstation.

Session policy

USB and copy and paste: allow or block

Administrators set a session policy in the console, for the whole organisation or for individual people. It allows or blocks USB sharing, copy and paste from the device to the workstation, and copy and paste from the workstation to the device, each on its own. The policy is carried inside the session token and applied by the host at the start of every session.

Console controls

The same policy can require the workstation to lock or sign out when a session disconnects, sign out after a set number of minutes, lock after a period of idleness, and turn silent sign-in on or off. A control the policy does not mention is allowed.

USB device sharing

USB sharing is on by default and can be turned off per workstation or by organisation policy. Devices are classified before anything is shared. USB hubs, the device’s system disk, its built-in keyboard and mouse, network adapters, display adapters, and audio or video devices are refused. Mass storage always asks the person before it is shared. Smart card readers and other HID devices are shared when the person selects them. The USB drivers installed on the workstation are signed by Microsoft through the Windows hardware developer programme.

Zero client mode

In zero client mode a Windows PC or Mac runs a dedicated standard-user account whose shell is the Remotle app. A privileged service creates the account with a 32-character random password generated on the device and held only in the operating system’s protected secret store. The app and the console never receive that password. On Windows the account’s policies block the Run dialog, Control Panel and Settings, the command prompt and scripting hosts, registry tools, Task Manager, Edge and local USB storage, and the service re-applies the lockdown and removes the account from any privileged group at every start. The lockdown uses Windows policy and a deny-list of named programs rather than an application allow-list. Maintenance access at the terminal requires a per-device maintenance password held in the console, with a lockout after five failed attempts. The account can only be removed from the console. No session content is stored on the terminal.

Software updates and code signing

Updates

The host and the app update themselves, and releases go out in stages. Before anything is installed, the updater fetches the release manifest from three independent hosting providers and requires all three to agree, verifies the manifest’s RSA signature against a release key built into the updater, and checks the SHA-256 of every downloaded file. On Windows it also verifies each file’s Authenticode signature and requires the signer to be Computle Limited. The release signing key is held on a hardware token that requires a PIN and a physical touch for each signature. An update never applies while a session is active. After an install, the updater health-checks the new version and restores the previous files if the check fails.

Code signing

Windows binaries and installers are signed with Azure Trusted Signing in the build pipeline. macOS builds are signed with an Apple Developer ID, notarised by Apple and stapled. The iPad app is distributed through the App Store. Windows drivers are signed by Microsoft. A release build is published only from a release tag signed with a hardware-backed key held by Computle.

Host hardening

The host runs as separate Windows services under separate accounts. The service that terminates the network connection and parses session traffic runs as Local Service with no privileges. Input injection, display control and the Windows sign-in path run in a separate system service that is reachable only through named pipes whose access control lists admit SYSTEM, local administrators and the session service’s own service identity, and which reject remote clients. The driver objects and shared memory used for display capture carry owner-only security descriptors.

Tenant isolation

Each customer has its own identity service instance, with its own database, its own signing keys for grants and tokens, its own certificate authority intermediate and its own encrypted backup store. An instance serves one customer and refuses a request for any other before performing any lookup. The shared connection service and relays identify every workstation by customer and machine, and a session token for one customer cannot reach another customer’s workstation.

Logging and audit

The app and the host write logs about what the software is doing: sign-in, connections, settings, connection quality, performance and faults. Input logging records counts and kinds of events and never which keys were pressed. Screen content is never logged. Logs are sent to Computle over HTTPS, authenticated by the workstation certificate or the signed-in user’s token. Local log files on the host are optional. The connection service records each session’s user, workstation, customer, start and end time, the path taken and the bytes carried, and records every refused connection with a reason code. Every use of a certificate authority key in the hardware security module is written to an audit log with alerting. Customer identity data, session records and backups are held in the United Kingdom and the European Union. What is collected, where it is stored and for how long is set out in the privacy policy.

Security testing

Static analysis runs across the codebase weekly and findings are triaged in the engineering tracker. Internal security reviews of the host, drivers and clients in 2026 drove the current architecture: no listeners on the host, TLS 1.3 with host verification, privilege-separated services and explicit permissions on every shared object.

Reporting a vulnerability

If you believe you have found a security issue in Remotle, please tell us through remotle.com/contact. We will acknowledge your report and keep you updated while we investigate.