Attended vs Unattended Remote Access: How IT Teams Secure Both
October 15, 2026
It is 6:40 on a Monday evening and a finance manager is about to close the month. Her laptop will not open the accounting application. She calls the help desk, a technician connects, and within a minute he is moving her mouse. Nobody asked whether she wanted that, nobody wrote down why it was needed, and the recording, if there is one, sits on the technician's laptop. Two hours later, the same technician connects to a branch server that nobody is using and restarts a service. Same tool, same habit, completely different risk.
Remote access is the most used and least examined capability in most IT departments. A technician opens sessions dozens of times a day, usually under pressure, and rarely stops to ask whether the connection was approved, recorded or even necessary. The same capability, in the wrong hands, is also how attackers get in. That tension is why the choice between attended and unattended remote access deserves a written policy rather than a habit.
We write this as advisors. The first sections apply to any remote support tool. The later sections show how NinjaOne Remote, one of our partners, puts the controls into practice, and what that means for teams in Latin America.
In the industry, the difference between the two modes is not technical sophistication. It is whether a person is sitting at the device when the technician connects. In an attended session, the end user is present and aware. They asked for help, they see what the technician does, and they can stop it. In an unattended session, the technician connects to a device that nobody is using at that moment: a workstation overnight, a kiosk, a server, a laptop left on a desk.
The distinction matters because it changes three things at once. The first is consent. In an attended session, the user's presence is the consent. In an unattended session, consent has to be established in advance, by policy, because nobody can click allow at the moment of connection. The second is visibility. An attended user can notice an unexpected action and say so. An unattended session has no human witness, so the log and the recording are the only witnesses. The third is the blast radius. A mistake in an attended session usually affects one user. A mistake, or a stolen credential, in an unattended context can reach every device the technician group can touch.
Most teams use both modes and mix them without noticing. That is the real starting point: the problem is rarely that one mode is dangerous, but that nobody has decided which mode applies to which work, who approves it and what evidence remains afterward.
Attended sessions suit work that needs a person in the loop: troubleshooting a problem the user can describe, walking someone through a new application, resolving something that depends on what is on the screen right now, or training. The user sees the work, which builds trust in IT. The cost is interruption. The technician needs the user to be available, and the user cannot use the device normally during the session.
Unattended sessions suit work that does not need the user: applying updates, installing software, running a diagnostic, recovering a machine that has stopped responding, or supporting devices that have no regular user at all, such as point-of-sale terminals, digital signage, lab equipment and servers. For distributed teams and for managed service providers, unattended access is what makes support possible outside business hours and across time zones. We covered the visibility side of that reality in our article on endpoint visibility for remote teams.
A simple rule of thumb works well. If the work depends on what the user knows or sees, use attended access. If the work depends only on the state of the device, use unattended access. When a task starts as one and turns into the other, such as an attended session that needs a reboot and a long installation, end the attended session, tell the user and continue under the unattended rules. Switching modes silently is where policy gaps appear.
Every legitimate remote access path is also an attack path if it is exposed or poorly controlled. The incident data is consistent on this point. The Sophos Active Adversary Report for the first half of 2024 analyzed incident response cases handled by the Sophos X-Ops team in 2023. Attackers abused the remote desktop protocol (RDP) in 90% of the attacks. RDP and similar external remote services were the initial access method in 65% of the cases. In 43% of the cases, multi-factor authentication had not been configured.
Two lessons follow. First, the problem is rarely the idea of remote access. It is remote access that is reachable from the internet, protected by a password alone and not monitored. Second, adversaries do not need exotic tools when a legitimate one is already installed and trusted. A remote support tool that is poorly governed is a gift to them.
None of this means you should avoid unattended access. It means you should treat it as a privileged capability, with the same discipline you apply to administrator accounts. For the business, the outcome that matters is simple: support stays fast, and no technician, contractor or attacker can reach a device without someone having decided that they should.
Unattended access carries more risk because nobody is present to notice misuse. These are the controls we ask clients to put in place before enabling it broadly. Limit who can connect: create named technician groups with explicit permission, keep them small, and avoid giving every help desk role the ability to reach every device. Require multi-factor authentication for every technician who can open a session, because a shared password on a remote tool is exactly the weakness the Sophos data points to.
Tie every connection to a record of who connected, to which device, when, for how long and under which ticket. A connection that cannot be tied to a ticket should be exceptional and reviewed. Use time-bound approvals for ad hoc access, so a technician who needs a sensitive group of devices for a specific task receives access for a defined window and not permanently. Review group membership every month, because people change roles, contractors leave and access outlives the reason for it. A monthly review catches this before an audit does.
Finally, decide in advance what you record, who can view recordings, where they are stored and for how long, and set rules for file transfer: limited purposes, a ticket reference for each transfer and a clear place where transferred files live. None of these controls slows a competent technician down. They slow down the mistake and the misuse, which is the point.
Attended sessions carry lower risk, but they are also where social engineering lives. Attackers impersonate support staff, call users and ask them to approve a connection. The user's habit of clicking allow is the vulnerability. The countermeasure is mostly behavioral: obtain explicit consent at the start, tell the user what you intend to do before you take control, narrate actions that touch data, credentials or settings, and confirm the issue, the scope and the fix with the user before closing, recording that confirmation in the ticket.
Users also need to know how legitimate support reaches them, so that an unexpected call asking for a code or a connection stands out. A short internal note with the official process, sent through your regular channel, is often enough. These habits improve quality as well. A technician who explains what he is doing tends to catch his own errors and leaves the user better informed for next time.
Policy that lives in one person's head is not policy. Write down when each mode applies, with two or three real examples from past tickets, the consent wording for attended sessions, the approval path for unattended ones, and what gets recorded in the ticket after every session. Then measure it: first contact resolution, mean time to resolve, repeat visit rate and the ratio of attended to unattended sessions. That ratio is especially revealing. A team that discovers most of its sessions are unattended should check whether its controls match that reality.
A laptop used by a remote employee. The employee reports that a business application fails after a restart. The problem depends on what the user sees, so attended access is the right choice, with consent requested at the start. If the fix involves a long installation, agree on a time and finish the work unattended. The employee works from home, possibly on a shared network, so the connection path matters more than the physical location: no inbound rules, controlled technician groups and a ticket for the record.
A server or kiosk with no regular user. Point-of-sale terminals, branch kiosks, digital signage and servers rarely have a person nearby to approve a connection. Unattended access is the only practical option, which is why it needs the strongest controls: a small approved group, multi-factor authentication, time-bound approvals for anything outside routine maintenance and a monthly review of who belongs to the group.
A contractor or a device that is not yours. A provider needs to look at a device that is not enrolled in your management platform. Do not install a permanent agent for a one-off task. Use a temporary, invitation-based method, set an expiry and record who invited whom and why.
NinjaOne is a partner of GB Advisors, and we implement it for clients across Latin America and the Caribbean. A technician starts a remote session from the device dashboard, and the endpoint receives a connection request. NinjaOne Remote offers full remote control, and on Windows it also offers Background Mode. Users can take control of their own computers when they are away through the End User Portal, and up to three simultaneous connections can run against one endpoint, from the same or different technicians or users.
Consent is a setting, not a habit. A global setting makes NinjaOne Remote ask the end user for confirmation before connecting. At the organization level, the setting adds a confirmation timeout and an option to allow access if the timeout expires, which does not apply to mobile devices. At the device level, administrators can disable NinjaOne Remote on a device, or enforce an approval prompt with an optional timeout. This lets you write your policy into the tool: attended workstations require approval, while servers and kiosks can be handled differently, with the exception being a deliberate and reviewable decision.
Technician access is gated by permissions, assigned through roles or per user, and Background Mode needs its own separate permission. An IP allowlist accepts up to 10 WAN source IP addresses and blocks other sources, and an established session stays allowed if the WAN IP changes. During a session, a small notification window on the endpoint tells the user the device is controlled and shows configurable branding. End users can hide that window, and hiding it does not end the session, so confirm that this matches your transparency expectations before rollout.
Technicians can use full control, send keystrokes such as Ctrl-Alt-Del and F12, print remotely, transfer files, chat with the end user, adjust video quality, record the session and terminate it. Session settings carry much of the policy. You can set an inactivity timeout with an action that does nothing, locks the workstation or signs out the user, choose an on-close action with the same three options, sync the clipboard in both directions and clear it on close, disable the remote wallpaper, record sessions automatically and prevent the technician's keyboard and mouse for a view-only session. Recordings are stored on the technician's computer by default, and the directory can be changed. That changes your evidence strategy: a recording on a laptop is only as durable and as protected as the laptop, so decide how recordings are collected and who can reach them.
Background Mode is the practical answer to maintenance while someone is working. It runs under the Windows SYSTEM account on a separate desktop, and the user sees no remote session. Technicians get File Explorer, Registry Editor, Service Manager and PowerShell, along with Event Viewer, Disk Manager and CMD. It supports patching, software deployment, scripts, configuration changes, log collection and service restarts without a reboot. To use it, the role needs the permission Background Mode for NinjaOne Remote set to allowed, the feature must be enabled under Administration, Apps, Installed, NinjaOne Remote, and the device must be managed by NinjaOne. Session start and end are logged with the technician's name, and background sessions are recorded.
Background Mode has limits worth knowing. Applications that depend on the user's interactive session, graphics or profile tokens may not work there. Reboots interrupt the user's session, so schedule them outside working hours or use a standard session instead. This links directly to patching, which we covered in our article on automated patch management: a technician can move from a failed update to a fix without switching tools.
For devices that are not enrolled in NinjaOne, Quick Connect provides one-time access with no pre-installed agent. Invitations are created for specific recipients, with a name, an optional description, an optional organization, an expiration and optional end-user confirmation, and they are sent by link, code or email. Quick Connect can also deploy the NinjaOne agent, connect with saved or one-time admin credentials through Connect As, and share a screen from the NinjaOne Assist mobile app with an invitation code. Invitation creation and deletion, agent deployments and other events are logged on the Activities tab. It must be enabled first under Administration, Apps, Installed, NinjaOne Remote, it cannot connect to an offline device, expiring an invitation is permanent, and an On use invitation becomes invalid once the session begins. That fits the contractor scenario above.
On the network side, NinjaOne Remote uses TCP port 443 as the primary path, TCP port 7075 as a fallback and supports SOCKS 5 proxies. Endpoints need no inbound rules, because both sides connect outbound to the NinjaOne cloud. Proxies or SSL inspection can break sessions, so that traffic must be allowlisted or bypassed. Supported endpoints are Windows, macOS, Android, iOS and iPadOS, with limits on mobile: Android fully managed devices allow full control if the end user allows it, Android work profile and personal devices are view-only, and all Apple devices are view-only. On macOS, remote control needs the Screen Recording and Accessibility permissions, with Full Disk Access optional, and all can be pre-approved through MDM. The streamer deploys silently with the NinjaOne agent, while the player is installed manually from the library.
When remote access sits in the same platform as monitoring, patching and automation, there are fewer places for an unmanaged access path to hide. We examined that logic in the hidden cost of IT tool sprawl, and the RMM guide explains why remote access belongs next to those functions.
Organizations in the region often run lean IT teams that cover several countries, sites and time zones, and many depend on external providers for part of their support. That makes unattended access more common, and it makes the governance of third-party technicians more important than in a single-office company. A regional retailer with a hundred branches, each with a point-of-sale terminal and a back-office PC, cannot send a person to every site. It needs maintenance at night, and it needs confidence that the person connecting is who the policy says it is.
Three practical points follow. Write down which technician group belongs to which provider, and remove access the day a contract ends, not at the next review. Check the data handling expectations that apply in each country where you operate, and involve legal or compliance teams when recordings or file transfers could include personal data. And test connection quality from the places where your users actually work, because networks in the region vary widely. Corporate proxies and SSL inspection are common in larger organizations, which makes the allowlisting requirement above a real item for your network team and not a footnote.
The same applies to managed service providers that serve many clients from one team. Access boundaries are what stop one customer's technician group from seeing another's devices, a theme we developed in how MSPs manage multi-tenant IT.
Before assuming your current approach is fine because nothing has visibly gone wrong, answer these five questions honestly.
If you hesitate on two or more of these, the open doors already exist. The next step is an inventory and a one-page policy, followed by a pilot with one technician group before you extend it.
Unattended access is too risky to allow. It carries more risk, but banning it pushes technicians toward unapproved tools that sit outside any log. Governed access with small groups, consent rules and review is safer than access nobody sees.
We do not need to record every session. That is correct. Record where the data, the compliance obligation or the risk justifies it, and define storage, retention and access before you turn recording on. A pile of recordings without rules is a liability.
Our users will resent approval prompts. Usually the opposite happens. Users trust IT more when they see who connects and why, and the prompt also protects them from the impersonation calls we mentioned earlier. Where a prompt does not make sense, such as a kiosk, treat the exemption as a decision and write it down.
A second remote tool costs us nothing. It costs an additional set of credentials, an additional trail and an access path that may sit outside your reviews. Running more than one tool without a reason is one of the most common mistakes we see.
Our firewall will block this. NinjaOne Remote needs no inbound rules on endpoints, because both sides connect outbound over TCP port 443, with port 7075 as a fallback. What your network team needs to do is allowlist or bypass proxies and SSL inspection for that traffic.
The right question is not which mode to use. It is whether your organization can show, at any moment, who has access to which devices, why they have it and what they did with it. If the answer is yes for both attended and unattended access, your remote support is an asset. If the answer is no, it is a risk that happens to be convenient.
Start with the inventory and the one-page policy, then pilot the controls with one team. Measure your baseline first, for example mean time to resolve for remote tickets, so the improvement can be shown rather than assumed. GB Advisors helps IT teams and managed service providers across Latin America and the Caribbean assess, design and implement remote management and security controls, with an independent assessment first and a recommendation second. Talk to our team about a short review of your remote access paths, and we will show you where the open doors are.
