Remote access earns trust, or it earns nothing

Remote support gives one person a view into another person’s computer. Used legitimately, that can fix a business problem quickly. Used covertly, the same reach becomes a source of harm. Visibility and authorisation therefore belong in the product design, not only in a paragraph of legal terms.

Remote Login has no invisible session mode. It is built for authorised support and maintenance. The distinction between an attended user accepting a request and an account owner pre-authorising unattended access is explicit. Neither mode makes access legitimate merely because the software can establish a connection.

This page describes concrete controls and their boundaries. It is not a SOC 2 attestation or a claim that buying the product makes a deployment HIPAA compliant. Read it alongside the Privacy Policy, Acceptable Use Policy, Terms of Service and your own contractual requirements.

Remote Login session links use a 15, 30 or 60 minute window, apply to a single device and can be revoked. A link should not become a permanent credential that quietly outlives the support job. Choosing the duration makes the boundary explicit before the session starts.

Revocation and expiry are different: revocation ends the validity early; expiry provides the outer limit. Neither substitutes for carefully identifying the intended device and organisation. A short-lived link to the wrong machine would still be the wrong link.

Plan work around the access window. If a job needs a new session, establish a new valid path. The support record should reflect what actually happened rather than implying that the original authorisation extended indefinitely.

The server checks the caller’s current role and owning organisation from the database when authorising requests. A role or organisation identifier supplied by the browser is not trusted as proof of access. If the required permission cannot be established, the operation is denied.

This matters when staff roles change. A previously displayed button is not continuing authority to use an operation. The meaningful check occurs at the server on the request, against the current permitted scope.

The customer still needs to maintain accurate membership and role assignments. A server can enforce the permissions configured for an identity; it cannot infer that the business relationship behind that identity ended unless the account’s access is updated. Include service access in the offboarding checklist.

Technician sign-in supports TOTP two-factor authentication. The additional factor is separate from the password and helps protect an identity that can reach business devices. Individual technician identities also make the session record attributable to the person who did the work.

Two-factor authentication is not a substitute for correct permissions. An authenticated technician can still be outside the organisation or role needed for a particular action. Authentication establishes the identity; authorisation decides what that identity may do.

Treat recovery and staff changes as part of the deployment. Decide who administers access, how the team verifies a recovery request and what happens when a technician leaves. A shared login defeats attribution even if everyone on the team knows its second-factor code.

The enrolment wizard checks screen, pointer and keyboard capability on the actual machine. It does not assume that a successful install means full control. A device that can only be viewed should be labelled accordingly before somebody depends on remote input.

Capability is different from authority. A Mac may permit input technically, while the technician has no right to use that device. Conversely, an authorised technician may encounter an OS permission that prevents control. Both checks must succeed for the intended action.

The platform capability matrix sets out these limits. Recheck after relevant operating-system, agent or permissions changes; a test result is evidence about a configuration, not a permanent guarantee.

• An invisible mode for watching somebody without their knowledge.
• A covert monitoring workflow disguised as routine support.
• A promise that a technician can bypass the device owner’s required consent.
• A claim that an operating system permits a capability it does not expose.

The Acceptable Use Policy prohibits stalkerware, unauthorised access and tech-support fraud. Reports are handled as abuse matters, not as requests for an additional product feature. A commercial subscription does not authorise access to a device.

For a concrete view of the controls, follow a session from enrolment to retained record. For purchasing, the published plans separate commercial allowances from the access rules that apply to every legitimate session.