Remote Login / How it works
Three steps, and nothing hidden from the person at the desk
How does remote support work when the connection is accountable? Enrol the device into the right organisation, open a visible session within an access window, and retain a record after it ends. Here is the complete flow, including refusals and failures.
Remote Login
Step 1 — a guided setup link
Start with the organisation that owns the device. The guided setup link leads the customer through enrolment into that organisation, rather than leaving a technician to remember which miscellaneous group should contain it. That choice establishes the context for subsequent access and records.
The installer is only the start. Setup checks whether the screen can be viewed and whether pointer and keyboard input actually work on the supported platform. A result should distinguish viewing-only access from verified control. If a Mac is missing a permission, fix that dependency before describing the device as ready.
Ask the person at the machine to test a safe, non-sensitive action. They should recognise the provider, understand why the agent is being installed and know how to ask for help. The workflow must be explainable to someone who did not participate in the purchase.
Read the per-platform permission reference first if your fleet includes Macs, Linux desktops or mobile devices. A rollout is more predictable when each operating system’s limit is part of the plan rather than a discovery during the first urgent session.
Remote Login
Step 2 — a session that expires
The technician selects the authorised device and chooses a 15, 30 or 60 minute access window. For attended work, the person at the device sees who is asking and accepts or declines. During the session, an indicator remains visible and the person can end the access.
The link is scoped to one device. It can be revoked before its scheduled expiry. This limits the life and reach of the access path without relying on the technician to remember to delete a permanent credential later.
For unattended work, authority is configured in advance by the account owner. That can support agreed server maintenance or out-of-hours work. It is not equivalent to someone accepting a prompt at the time, and the record should not imply otherwise.
The consent and authorisation model explains the distinct roles of identity, organisation scope and device-side permission. A valid window does not grant permission to an unrelated device, and network reachability does not establish authority.
Remote Login
Step 3 — a record that survives
When the session ends, the access record remains associated with the organisation. It identifies the technician and device, the timing and relevant activity events. The support team can use that record to answer a later question without reconstructing the visit from memory.
- Technician
- Marcus Ellery
- Organisation
- Northline Dental
- Device
- FRONTDESK-01
- Started
- 09:41:07 UTC
- Ended
- 09:41:33 UTC
- Transfer event
- 2 files
session.ended · record retained
The example is illustrative and uses fictional details. A real record should be interpreted for what it contains: evidence of access and recorded events, not automatically a video of every screen or an explanation of the fault. Put the support diagnosis and follow-up into your normal ticket or customer notes.
Keep retention requirements explicit. If an organisation must keep a particular category of record for a fixed time, verify the available configuration and agreement before deployment. “There is an audit log” is not a complete answer to a retention questionnaire.
Remote Login
Attended and unattended, and when each applies
| Mode | Authority | Typical support situation |
|---|---|---|
| Attended | The person is present and accepts the request. | An employee demonstrating an application problem. |
| Unattended | The account owner has authorised access in advance. | Agreed server maintenance or an out-of-hours workstation task. |
Many teams need both modes. The decision belongs to the device’s purpose and its owner’s policy, not just to whichever setting is easiest for the technician. Document the scope so that a customer can distinguish an expected maintenance session from an unexpected request.
Mobile support can have additional boundaries. In particular, Remote Login on iPhone and iPad provides sharing that the person starts and ends; it does not become unattended control because an organisation uses the product for desktop servers.
For more examples, see attended and unattended IT support. For organisation setup across multiple businesses, see the MSP deployment model.
Remote Login
What happens when something goes wrong
The link expires during the job
The expired access window is not an invitation to keep using the same link. Establish a new valid session if work must continue. Plan tasks that may outlast the connection so that the machine is not left in an unsafe intermediate state when access ends.
The device is offline
An offline device cannot become reachable merely because a technician has permission. Check the device’s power, connection and enrolled-agent state through an appropriate local or existing recovery path. Do not report a capability as verified when the target has not actually been reached.
The person declines consent
A decline is a valid outcome. Confirm that the person recognises the technician, provider and task. If the request was unexpected, use the customer’s established contact channel. Repeatedly sending prompts is not a substitute for resolving the reason they refused.
A technician’s access is revoked
Remove the service permissions and review links and active work as part of offboarding. Current server-side permission checks govern later operations. The operational process should deliberately close any relevant session path, rather than assuming that one account change in a different system covers every tool.
The failure cases are part of the product’s security model, not exceptions to it. Evaluate them alongside the successful session before relying on remote access for customer work. The published plans make it possible to assess the commercial fit at the same time.
Questions, answered
How remote support works — questions
Does the customer need to understand networking?
No. Guided setup leads them through the relevant steps, and the support request identifies who is connecting and for how long. They may still need to grant operating-system permissions locally. Give them a clear way to verify the request if the provider name or timing is unexpected.
Can a link be used for another device?
The session link is scoped to a single device. A technician needs an appropriate authorised path for another target. This prevents a support window for one machine from being treated as a general pass into every device in the organisation.
Is the audit record a full screen recording?
No. A session record identifies access and recorded events. It should not be described as a complete video or transcript of the work. Establish any separate recording and retention requirement explicitly before making that promise to a customer.
What is the best first evaluation?
Enrol a representative test device, verify its capabilities, accept one attended request and decline another, then check the records. Include expiry and revocation. That small set of outcomes tests the boundaries that a successful connection alone cannot demonstrate.
Get started
See how it fits your team.
Tell us how many technicians you have and which platforms you support. We will help you check the fit.