Security
Remote support is a way into someone's computer
This page is about what stands between that capability and its misuse, and about which of those things we can enforce rather than merely promise. The difference matters more than any of the individual claims.
Last reviewed 16 September 2026
Consent
The decision is made where the screen is
Our server passes the question along and records the answer. It cannot answer on the customer's behalf, and neither can we.
Allow Max Muster from Acme IT to see your screen?
Your screen only, no control. A banner stays on screen and Stop ends it at any time.
Their machine decides
The program on the customer's computer makes and enforces the decision. There is no instruction we can send that turns sharing on, and no support request we could be talked into that would do it either.
Looking is not controlling
Allowing a technician to see a screen does not let them type or click. Control is a second permission, granted separately and recorded separately, and a request for it before viewing has been allowed is refused outright.
Nothing is installed
The tool a customer runs for a one off session removes itself when the session ends. Nothing stays running on a machine that was only visited.
While it runs
Always visible, always stoppable
A session that can be hidden is a session nobody consented to. The banner is on screen for the whole of it.
- It carries the technician's name and the company they work for, so the customer knows who is looking.
- It cannot be dismissed, minimised or hidden behind another window.
- Stop is in the banner and ends the session from their side, at once.
What we hold
The parts we can prove, not the parts we promise
Four things that are true because of how the system is built, rather than because of a policy somebody could quietly change.
We never hold the picture
Screen images and the input sent back travel directly between the technician's browser and the customer's computer, encrypted end to end. Where a direct connection cannot be made the traffic is relayed by us, and the relay carries ciphertext it has no key for. Sessions are not recorded.
The record cannot be edited
Who asked, who allowed, whether control was granted and when it ended are written as they happen. Nobody using the product can change or remove that, including the organisation that owns the account and including us through the product.
The agent holds no keys
The program on a customer's machine has no database credentials. It can speak to one organisation's session and nothing else. Every table in the database refuses reads it cannot attribute to a member of that organisation.
Accounts are people
Passwords are hashed and never stored in a form we could read, an address is confirmed before an account can sign in, and accounts belong to named people, which is what makes the record of who did what mean anything.
Where it runs
Switzerland, and one relay
The database is in Zurich. Signalling and the relay run on Cloudflare's network, and the relay never holds a key to what passes through it.
Section 6 of the privacy policy lists every processor and what each one does, and the compliance page covers the legal side: who is controller, who is processor, and which of your obligations are yours rather than ours. The question a customer of yours actually asks, how you show afterwards that you were allowed to look, is answered on proving consent without recording the screen.
Not yet
What we have not done
Written here so that nobody has to discover it in a procurement questionnaire.
- We hold no security certifications. No SOC 2, no ISO 27001, and no independent audit of any kind.
- There has been no third party penetration test.
- A technician who has enrolled an authenticator app is asked for its code at every sign in, an organisation can require one of everybody, and an unattended connection to a managed device is refused unless a second factor was passed recently. An organisation that has not required it still lets a member without one in on a password. There is no single sign on and no SCIM. Changed 23 September 2026.
- Turning on an authenticator also gives ten single use recovery codes. One of them signs a technician in without the phone and removes the authenticator, so it has to be set up again, and the organisation's log says so. Changed 26 September 2026.
- Every agent download since 0.1.11 is signed by Maxapp GmbH, and since 0.1.12 so are the files the installer puts on the machine. The release pipeline refuses to publish a file whose signature does not verify. Windows SmartScreen may still show its reputation warning on a new download until enough machines have run that release, because it counts downloads per file rather than trusting the signature alone. Changed 26 September 2026. The current release is 0.1.21, published 1 October 2026.
When any of these changes it will be stated here with the date it changed.
Disclosure
Reporting something you have found
We will not pursue anyone who reports a genuine issue in good faith and gives us a reasonable chance to fix it before publishing.
Write to security@livedesk.sh with enough detail to reproduce it. We will acknowledge it and keep you informed until it is closed.