Scope & evidence

Authorised IT support and administration. Actual consent prompts, elevation behaviour and supported devices vary by product and operating system.

Stuart Kerr Spindlow has confirmed personal use and testing of the software covered by Happy SysAdm. The assessments here distinguish documented behaviour from measured results; worked scenarios are labelled and are not personal test records.

Match the access model to the job

Attended access is the stronger default for a one-off user problem because the session is tied to an immediate request and the user can observe it. Unattended access is preferable for recurring administration of managed systems when nobody is present, provided enrolment, technician scope and revocation are controlled. Persistent access should earn its place through an ongoing operational requirement.

Attended support fits a user asking for help on a device in front of them. They can describe the symptom, approve the connection and observe the work. Unattended access fits managed systems that need maintenance when nobody is present, such as a server or a scheduled endpoint change.

The choice is not a measure of trust in a particular user. It is an operational design decision about when access is needed and how authorisation is recorded. Avoid installing persistent access for a one-off session unless there is a separate approved need.

Decision map

Who can approve access at the endpoint?

Attended session
A person participates in the support workflow and provides session consent according to the selected tool.
Unattended access
Previously authorised persistent access supports work when nobody is present. Maintain enrolment and access records.
Both models
Use named technicians, limited privileges, accountable sessions and verified revocation.
Access-model comparison. Exact prompts, permissions and recording depend on the product and plan. Evidence sources.

Treat persistent access as an asset

For unattended agents, record the enrolled device, service owner, permitted technician group and review date. Verify deployment source and policy. Restrict access to the smallest useful set of systems rather than making every device visible to every technician.

Test what happens after a technician leaves, a device is reassigned or the supplier account is disabled. Removing a local user account may not remove a remote-support agent or its cloud permissions. Check both the endpoint and the management console.

Close and verify the session

Record the actions taken and the outcome. Remove temporary files, elevated credentials or temporary access introduced for the task. For attended support, confirm that the user understands the result and that the session has ended.

Review session logs and their retention. Recording can capture sensitive data, so enable it only under an appropriate policy and access model. For unattended access, periodically verify that the business need still exists and that revocation works.

Count identities, devices and simultaneous work separately

An illustrative team with four authorised technicians, two simultaneous support sessions and 80 managed endpoints has three separate quantities to license and control. Four accounts do not imply four concurrent sessions, and two sessions do not describe the 80-device unattended-access footprint.

For an attended session, the useful record includes approval, connection and disconnection times. For unattended access, record the continuing device authorisation and last review as well as individual sessions. These are different accountability models; a temporary session code should not be treated as evidence of a permanent access entitlement.

References

Next useful steps

Read our editorial and corrections policy.