Unattended Remote Access: Use Cases, Risks and Controls

Short answer: Unattended remote access lets an admin connect to a device without anyone present to approve the session, which is why IT teams use it for off-hours patching, server management and MSP fleet support. It also removes the one control attended sessions get for free, a human who can say no, so it needs its own layer of controls: a unique credential per device, MFA on the console, least-privilege permission profiles, an allowlist of who can connect, and logged or recorded sessions.

What unattended access is

Unattended access is a remote connection that does not require a person at the far end to click "accept." Splashtop describes it as connectivity that works "without requiring someone at the remote end to grant access," which it contrasts with attended access, where the person at the device has to approve every session (Splashtop, accessed September 28, 2026). TeamViewer frames the same distinction around supervision: unattended access lets a technician "set up a remote access session with devices located anywhere in the world without supervision" (TeamViewer, accessed September 28, 2026).

The setup itself is simple by design. TeamViewer's documented process is three steps: install the client on both ends, set a password for unattended access, and add the remote computer to a partner list; after that, the device is reachable any time it is powered on and connected (TeamViewer, accessed September 28, 2026). AnyDesk's equivalent is a permission profile: an admin turns on Unattended Access inside a named profile and sets a password for that profile specifically, and anyone who connects with that password gets exactly the permissions the profile grants (AnyDesk support documentation, accessed September 28, 2026).

That simplicity is also the risk. An attended session has a person deciding, connection by connection, whether access is appropriate right now. An unattended connection has a standing credential that grants access whenever it is used, whether that use is an admin, a former employee who still has the password, or an attacker who found it.

Where unattended access is used

Unattended access solves a specific problem: reaching a device when nobody is sitting in front of it, or when interrupting the person who is would slow the work down. The vendor documentation for this keyword clusters around a consistent set of scenarios.

(Sources: LogMeIn Resolve, Splashtop and TeamViewer product and blog pages, all accessed September 28, 2026.)

The common thread is scale and timing: one admin reaching many devices, on a schedule the device owner does not control. That is exactly the pattern that makes unattended access valuable for IT support and MSPs, and exactly the pattern that makes a single compromised credential expensive.

Why unattended access carries more risk than attended access

An attended session has a built-in check: a person has to be present and has to say yes. Unattended access removes that check by design, which is the point of the feature, but it means every other safeguard has to be built deliberately rather than inherited for free.

NIST's guide to enterprise remote access sorts connection methods into four architectures by where the application client and its data actually sit: tunneling, application portals, remote desktop access, and direct application access (NIST SP 800-46 Rev. 2, accessed September 28, 2026). Unattended access tools fall into the remote desktop access category, where the user controls a specific device directly. NIST's caution about that category is direct: it should be used only for exceptional cases after a careful analysis of the risks, because other methods offer superior security capabilities (NIST SP 800-46 Rev. 2, accessed September 28, 2026).

The reason is decentralization. A VPN or a per-application broker puts the hardening burden on one gateway. Remote desktop access, including unattended access, puts it on every device that can be reached, because each one is now a remote access endpoint in its own right, whether or not it was designed to be one.

Watch out: an unattended access password or agent enrollment is a standing credential, not a one-time approval. If it is never rotated, never scoped to a permission profile, and never tied to an allowlist of approved connecting accounts, it behaves like a permanent backdoor that happens to have a legitimate business reason for existing.

This is also why unattended access is a standing-access design choice, not just a feature toggle. The same reasoning that argues for just-in-time access over permanent admin rights applies here: the safest unattended access deployment is the one scoped to the fewest devices, for the shortest time, with the fewest people holding the credential. Our zero standing privileges explainer covers that argument in more depth for privileged accounts generally.

The controls that close the gap

None of this means unattended access is unsafe to run. It means the controls that an attended session gets automatically have to be configured explicitly. The vendors in this space document a consistent set of them, even though each one implements its own version.

(Sources: AnyDesk support documentation, TeamViewer and Splashtop product and blog pages, all accessed September 28, 2026.)

Two of these are worth calling out because they are the ones most often skipped under deployment pressure. The first is scoping the permission profile: AnyDesk's documentation is explicit that Full Access, which grants complete control of the device, deserves more thought before deployment than a view-only profile does (AnyDesk support documentation, accessed September 28, 2026). Defaulting every device to Full Access because it is the path of least resistance during setup erases the benefit of having profiles at all.

The second is treating the credential like the permanent artifact it is. A password set once during onboarding and never rotated, never tied to MFA, and never removed when a technician's role changes is the exact standing-access pattern that zero standing privileges is designed to eliminate for privileged accounts. Unattended access credentials deserve the same discipline even though they live in a remote access tool rather than an identity platform.

Free unattended remote access: what free tiers usually drop

"Free unattended remote access" is a common search because several vendors do offer no-cost tiers, and the connection itself is rarely the limitation. What tends to be missing is the administrative layer that makes unattended access auditable at scale: centralized MFA enforcement across every device, a managed allowlist instead of a password shared by word of mouth, and session logs an admin can pull later rather than none at all.

Admin tip: if a free tier is genuinely the right fit for a one-person shop with one or two devices, apply the same controls manually that a paid console would enforce automatically: a strong, unique password per device, MFA on the account that manages the connections, and a habit of disabling access on any device that has been retired or reassigned.

A single free-tier connection to a personal machine carries limited exposure. The same free tier used to reach a dozen client devices without centralized logging or MFA enforcement is a different risk profile entirely, closer to the standing-credential problem described above, just without the console to manage it.

Rolling out unattended access safely

1. Inventory which devices actually need it. Unattended access earns its risk on servers, unattended workstations and MSP-managed endpoints. It does not need to be the default state for every laptop in the fleet.
2. Pick the narrowest permission profile that does the job. Start from a view-only or limited profile and grant Full Access only where the work genuinely requires it, per device or per profile, not organization-wide.
3. Set a unique credential per device or profile, and enforce MFA on the account that manages connections. A shared unattended password defeats the purpose of a permission-profile model.
4. Build the access allowlist before you build the habit. Define which accounts may initiate an unattended session on which devices, rather than letting the list grow informally as staff change.
5. Turn on session logging, and recording for anything touching sensitive systems. Because no one is present to see what happened, the log or recording is the only evidence that exists after the fact.
6. Review and revoke on a schedule, not just on request. Tie unattended access reviews to offboarding and device-retirement processes, the same way you would review any standing privileged credential.
7. Disable the profile on any device that no longer needs it. A disabled profile removes its password along with it, which is a cleaner control than hoping nobody remembers an old credential.

Third-party and vendor unattended access is a separate problem

Everything above assumes the person connecting is your own staff. Vendors, contractors and MSPs supporting your systems unattended are a different case: they are not in your directory, their devices are not managed by you, and the credential often has to be shared with people you cannot individually vet.

That is the gap the privileged access gateway category is built to close, with a credential vault, session recording and, in some products, an approval workflow layered on top of the connection rather than left to a shared password. Our privileged access management best practices guide covers the equivalent controls in more depth, and the CyberArk vs BeyondTrust comparison shows how two established platforms in that category differ if you are evaluating one for third-party access specifically.

Bottom line

Unattended access is the right tool whenever a device needs to be reached with nobody present, but it trades away the one safeguard an attended session gets automatically: a human who can say no. Replace that safeguard deliberately, with a unique credential per device, MFA on the managing account, a least-privilege permission profile, an access allowlist and session logging, and unattended access is a defensible standing-access design rather than a standing risk.

If you are choosing between remote access tools rather than deciding how to configure one you already have, start with the remote access software hub or the remote desktop tools category for the product-level comparison this guide deliberately does not attempt; for third-party and vendor access specifically, the privileged access gateway model above is the better starting point. To turn any of this into a shortlist by size and constraints, use the shortlist.