Remote access software for MSPs: is a separate remote tool still worth paying for?
The remote access line on an MSP's software bill is usually the oldest one there. It was bought before the RMM, before the PSA, sometimes before the second technician, and it has renewed quietly every year since. That history is not a reason to keep paying for it. Choosing remote access software for MSPs today means asking a narrower question than it used to: does a standalone product still do something your RMM's built-in access cannot? This piece compares the two on the four things that matter, connection quality, unattended access, session logging and cost per technician, and ends with a test you can run against your own invoice.
Why the separate remote tool existed in the first place
For a long time the split made sense. Early RMM platforms treated remote control as an afterthought: a bolted-on VNC viewer, a sluggish Java applet, or an integration that simply launched somebody else's product. Dedicated vendors, by contrast, lived or died on how fast the screen repainted over a hotel Wi-Fi connection. So MSPs bought both, and the habit stuck.
The ground has shifted. Most current RMMs now ship their own remote access, frequently browser-based, and the gap in everyday quality has narrowed to the point where many technicians cannot tell which engine they are using. The habit, however, has not shifted with it. If you are unsure where remote access sits among the other tools, our explainer on which tool does what across RMM, PSA and endpoint management covers the boundaries.
Connection quality: close enough for most, not for all
Connection quality is where standalone vendors still earn their reputation, and it is worth being precise about what that reputation covers.
- Frame rate and codec work. Dedicated tools have spent years tuning adaptive codecs, so fast-moving content such as video playback or CAD rotation stays smoother on poor links. For a technician clearing a print queue or editing a registry key, this advantage is invisible.
- Latency on bad networks. Both approaches now relay through vendor infrastructure when a direct connection fails. The difference shows up on congested or high-latency links, where mature standalone relays tend to degrade more gracefully.
- Session start time. Here bundled access often wins. You click the device you are already looking at in the RMM and you are in, with no second console, no second login and no copying a device ID between windows.
For the ordinary work of support, the honest verdict is that built-in access is good enough, and the time saved not switching consoles is real every single session.
Unattended access: the agent you already have
Unattended access is the part of remote access that MSPs actually depend on: reaching a server at 11pm, fixing a laptop while its owner is in a meeting, or logging in before anybody has arrived. This is where the case for a separate tool is weakest.
A standalone product needs its own agent on every machine, deployed, updated and monitored separately. Your RMM agent is already there, already running as a service with system privileges, already reporting health. Adding a second always-on remote agent doubles the software you have to keep patched and doubles the attack surface on every endpoint. It is redundancy that looks like resilience.
The second-agent test: for every endpoint, count the persistent remote-control agents installed. If the answer is two, you are maintaining, patching and defending one more than you need unless the second earns its place with something the first genuinely cannot do.
This matters beyond tidiness. Remote access tools are a favourite route for attackers precisely because they are trusted and always listening. Our MSP security checklist treats every privileged remote tool as something to justify, not something to collect.
Session logging for compliance: where bundling quietly wins
Clients increasingly ask who connected to their machines, when and why. Insurers and auditors ask too. Session logging is where standalone tools often look complete on a datasheet and prove awkward in practice.
A standalone tool can log that a session happened. What it cannot easily do on its own is tie that session to the ticket that justified it, the technician's time entry and the device's alert history. You end up reconciling two audit trails by timestamp, which is a guess wearing a spreadsheet's clothes.
When remote access lives in the same platform as ticketing, the log answers the question an auditor actually asks: this session, on this device, by this technician, for this ticket. Look for:
- Per-session records with start, end, technician identity and target device.
- Linkage to tickets or alerts, so every session has a reason attached.
- Optional recording for sensitive clients, with retention you control.
- End-user consent prompts where the client's policy requires them, and a clear record of whether they were used.
That joined-up trail is also useful evidence for frameworks like Cyber Essentials, which we cover in evidencing the five controls with tooling you already run.
Cost per technician: do the arithmetic yourself
Standalone remote tools are usually priced per technician or per concurrent session, with the useful features, such as mass deployment or unattended access at scale, often reserved for higher tiers. Bundled access is priced into the RMM, which may be per endpoint, per technician or flat.
The sum is simple enough to do on the back of a ticket:
- Take your annual remote access invoice and divide it by the number of technicians who actually use it.
- Check what your RMM already includes. If it ships remote access you are not using, you are paying for the same capability twice.
- Add the hidden cost of maintaining the second agent: deployment, updates, and the occasional ticket where the remote tool broke and the RMM did not.
If step two comes back positive, the separate bill needs a specific justification, not a general feeling that it is more reliable. Our breakdown of add-ons and hidden fees vendors leave off the pricing page shows how often remote access is sold as an extra even inside RMM platforms, so check your own contract before assuming it is included.
What browser-based access changes for a technician working anywhere
Browser-based remote access removes the installed viewer from the technician's side of the connection. That sounds minor. It is not.
- Any machine becomes a workstation. A borrowed laptop, a client's spare PC or a home machine can reach an endpoint without installing anything, which matters when the on-call technician is away from their usual kit.
- No viewer versions to keep in step. Mismatched client versions are a surprisingly common reason a session fails at the worst moment.
- Access follows identity, not device. Permissions sit with the technician's account and its MFA, so revoking a leaver is one change rather than a hunt for installed clients.
The same logic applies whether the machines belong to clients or to your own organisation. An internal IT team gets the same freedom, which we discuss further in RMM for internal IT teams.
Where dedicated tools still win
A fair comparison has to say where the standalone products are genuinely better. They are, in a handful of cases:
- Multi-monitor heavy workflows. If you regularly work across three remote displays at once, dedicated clients handle monitor switching, spanning and scaling more smoothly than most browser sessions.
- Graphics-intensive endpoints. Design, video and engineering workstations benefit from mature codecs and hardware acceleration.
- Ad-hoc support for unmanaged machines. Helping a client's home PC or a one-off visitor device, where you will never install an RMM agent, is exactly what quick-join standalone tools are built for.
- Specialist features. Some teams rely on things like remote printing, drag-and-drop file transfer at scale or mobile device screen sharing that a bundled tool may not match yet.
Keep the specialist tool for the specialist job, not as a default for every session.
Failure modes: what goes wrong either way
| Choice | Typical failure |
|---|---|
| Standalone only | Second agent drifts out of date, sessions unlinked from tickets, licence paid for technicians who rarely use it |
| Bundled only | Designers and multi-screen users frustrated, no tidy answer for unmanaged devices |
| Both, by default | Paying twice, patching twice, auditing two trails that never quite agree |
| Bundled, plus a small specialist licence | Usually the fewest failures, provided the specialist use is written down and reviewed |
Rule of thumb: if you cannot name the specific sessions your separate remote tool handles better, and roughly how often they happen, the bill is habit rather than need.
Where this fits with Helios
Helios includes browser-based remote access in the same platform as monitoring, patching, ticketing and time tracking, so sessions start from the device you are already looking at and land in the ticket history automatically. There is no second agent, and it is on every plan rather than sold as an add-on. It will not beat a dedicated tool for three-monitor CAD work or quick support on a machine you do not manage, and if those make up a meaningful share of your week, keeping a small specialist licence is sensible. Most of this decision is arithmetic and discipline, not tooling. You can see how the plans compare on our pricing page.
Helios: AI-native RMM and PSA in one platform, with flat published pricing. 14-day trial and no feature gating. Start free.