Unattended remote access security: best practices before you install a permanent host

Unattended remote access is useful because nobody has to sit in front of the target machine to approve every session. That makes it perfect for managed workstations, shared office PCs, out-of-hours maintenance and client devices under support contract.

It also means the host becomes a standing access path. If nobody owns that path, nobody removes it. If nobody reviews it, people keep access after roles, clients and projects change; that is why the remote desktop policy guide treats review dates as a core control.

Treat every permanent host like a small privileged asset. It should have an owner, a reason, an access group and a review date.

The first security decision is whether a permanent host is needed at all. A one-off support job should usually use attended access. A monthly maintenance task on a managed finance PC may justify unattended access. A dormant laptop in a cupboard probably does not.

This reduces the number of doors the business must secure. It also makes your remote access list easier to explain to a client, insurer, auditor or manager.

A simple rule works well: if the machine has no named owner and no recurring support or remote-work purpose, do not install a permanent host.

Unattended access should never depend on a shared technician password or a shared owner account. Named accounts create accountability. MFA helps protect those accounts when passwords are phished, reused or guessed.

NCSC authentication guidance is relevant here because remote access protects devices and services from unauthorised access. CISA has also called out weak controls such as missing MFA as routinely exploited.

For small teams, start with administrators, technicians and users who can access sensitive machines. If the tool supports MFA for everyone, make that the standard rather than the exception.

Flat device lists are convenient on day one and painful by month six. Once you manage more than a handful of hosts, groups become the control layer.

Group by client, site, department and sensitivity. Finance machines, director laptops, servers and shared reception PCs should not sit in the same permission bucket as low-risk test machines.

This makes onboarding and offboarding cleaner. A technician can be added to the client group they support, then removed without hunting through individual device permissions.

Unattended access logs should help you answer who connected, to which device, when, for how long and for what purpose. For privileged work, support notes or recordings may be appropriate, but they should be proportionate.

The ICO's security guidance expects organisations to manage access so data is handled only by authorised people acting within their authority. Logs are part of demonstrating that control after an incident or complaint.

Do not wait until something goes wrong to discover that the logs are too thin. Check the audit trail during setup and during each access review.

Security reviews are easier when they are scheduled. For a small support business, monthly is a good starting rhythm. For a stable internal team, quarterly may be enough after the process is mature.

The review should cover hosts, users, administrators, client groups, inactive devices and recent sessions. Remove old hosts. Remove leavers. Confirm that sensitive machines still need the same access.

DeskZap users can turn this into a practical operating habit: review the Host list, check the user list, confirm the reason for each permanent device and keep quick support as the default for anything temporary.

Three pitfalls show up repeatedly in UK support teams that roll out unattended access without a clear ownership model. Each one is easy to overlook because it builds up slowly, and each one has the same shape: a control that should be temporary or reviewed has become permanent and unreviewed.

Hosts without an expiry date

A device gets added for a one-week project, and two years later it is still in the Hosts list with full access to whoever knew the original owner's password. The expiry field on a Host is one of the cheapest controls in any remote desktop tool and one of the most consistently skipped. Set every Host with an expiry, and add a calendar reminder to review the Hosts list every quarter. The reminder is the actual control; the date field is just a label.

Shared Host accounts

A shared Host is used by every technician on the team: when something goes wrong, the audit log shows the support team rather than a named person. If an incident happens and the regulator or a client asks who started a session on a particular date, the answer has to be a person, not a team. Audit logs should always show named operators, even for shared infrastructure, and access should be tied to the individual who actually performed the work.

Dormant operator accounts

People who left six months ago still have the ability to start a session, because nobody removed their access when they left the business. The fix in all three cases is the same shape: assign an owner, an expiry and a review date to every host, and remove the operator account from the offboarding checklist the day someone hands in their notice. Hosts that do not have an active owner should be flagged for review at the next security check, and the audit log should show named operators rather than shared team accounts.

None of this needs new tooling: it needs the existing tools used with intent. DeskZap's Host list and Activity log already capture the data; the team just needs a process to act on it.

When a managed device reaches the end of its support relationship, the uninstall needs to be as deliberate as the install. Start by confirming the device is still needed: check the last session timestamp, confirm with the device owner that the support contract is ending, and verify the replacement device (if any) is set up before the old one is removed. A 30-day notice is a good default: long enough to transfer any in-progress work, short enough that nobody forgets about it.

The actual uninstall should remove the DeskZap Host package from the device, rotate any credentials that were shared with the support team, and archive the session history for the device for at least 12 months in case of a post-contract dispute. If the support relationship is ending acrimoniously, the rotation should happen immediately and the session archive should be reviewed for any unusual activity in the prior 90 days. The discipline of a clean retirement is what separates a support team that scales from one that accumulates technical debt.

Unattended access is the right call for machines that are managed on an ongoing basis: an office workstation under a support contract, a server that needs occasional maintenance, a workshop PC that runs the same diagnostic tool every week. In each case, the device has a stable identity, a known owner, and a support relationship that justifies the long-lived access. The user is not at the keyboard. The session is initiated by a named operator with audit and recording enabled. That is the natural shape of unattended access.

Unattended access is the wrong call when the user is at the keyboard, the issue is one-off, or the relationship is short-term. A customer who needs help with a printer, a freelancer who needs a single session to configure a tool, or a contractor who needs a one-hour walkthrough are all better served by quick support codes that expire in five minutes. Unattended access is not faster in those cases: the operator still has to wait for the device to respond, and the audit trail is heavier than the work justifies. Use quick support by default, switch to unattended only when the relationship and the device both justify it, and review the Hosts list on a schedule so dormant entries do not accumulate.