Remote Access - Who do you trust

Remote access software sits in an awkward category: essential for IT support, managed services, home working, and server administration, but also one of the fastest ways to hand an attacker the keys if it is deployed carelessly. In 2026 the market is crowded with well-known names, newer challengers, open-source options, and specialist enterprise platforms, all promising convenience, performance, and security. The problem for buyers is that the sales pitch is usually much simpler than the real risk profile.

The biggest concern is unattended access. Once a device is configured so that somebody can connect without a person on the other end explicitly approving each session, that tool becomes part of your permanent attack surface. If credentials are stolen, a vendor environment is compromised, a vulnerability is exposed, or security settings are left weak, unattended remote access can turn a routine support product into a direct path to sensitive systems. For consumers this may mean personal files, banking sessions, or saved passwords. For businesses it can mean domain compromise, ransomware deployment, data theft, and an incident response exercise that costs far more than the software licence ever did.

That does not mean remote access tools are inherently unsafe. It means they should be treated with the same seriousness as VPNs, identity platforms, and endpoint protection. Buyers should be asking how access is authenticated, whether MFA is enforced, what logging is available, how quickly vendors respond to security issues, whether the product can be self-hosted or segmented, and what the company's real-world security track record looks like when things go wrong.

Disclaimer: the table above is a point-in-time summary compiled from publicly reported information available at the time of writing (July 2026). "Breach history" refers to vendor-side incidents that have been publicly disclosed or credibly reported; it is not a measure of a vendor's current security posture, and the absence of an entry means only that no publicly verified vendor breach was found, not that none has occurred. Product names, ownership, and incident details change over time, and readers should verify the current position with each vendor directly before making a procurement decision. GEN has no commercial affiliation with the vendors listed, other than as a customer where stated.

The table above is not a league table of winners and losers, and it should not be read that way. A previous breach does not automatically make a product untrustworthy, just as a clean public record does not prove a vendor is risk-free. What it does show is that remote access providers operate in a high-value, high-pressure environment where security failures, development system compromises, exploited vulnerabilities, and third-party knock-on effects are all realistic concerns. Buyers who only compare price or ease of use are ignoring the factor that matters most once a remote support tool is embedded in daily operations.

Some names on the list remain broadly reputable and, at the time of writing, do not have a publicly verified vendor breach attached to them in the same way as others in the table. Splashtop, RealVNC, and RemotePC stand out on that narrow measure, while RustDesk appeals to organisations that prefer open-source transparency and greater hosting control, albeit with a different trust and operational model. That should not be mistaken for a blanket endorsement. Procurement decisions should still include architecture review, regulatory fit, support quality, default security posture, and whether the vendor's ownership base and operating model align with your own risk appetite.

Convenience vs Security

There is a harder truth underneath the brand comparison above: no always-online remote support tool, from any vendor, with any track record, will ever be as secure as a tightly scoped WireGuard mesh with posture checks, carrying local access protocols such as NoMachine, VNC, or RDP inside the tunnel. That is not a criticism of any one product; it is a structural property of the architecture itself.

An always-online tool works by keeping a persistent agent on every endpoint, holding an outbound connection open to the vendor's cloud broker so that a session can be established on demand, from anywhere, through any firewall or NAT. Every one of those conveniences is also an attack property. The device is permanently reachable by anyone who can satisfy the broker's authentication: the same mechanism that lets your technician connect from a phone lets an attacker attempt a connection from anywhere on the internet. The vendor's authentication service, session brokering, key management, and update pipeline all sit inside your trust boundary whether you invited them there or not, and as the table above demonstrates, vendor-side compromise is a recurring event rather than a theoretical one. A single phished portal account, or a single vendor incident, can cascade into interactive control of every enrolled machine, because it is the account that is being authenticated, not the device.

A tightly scoped WireGuard mesh inverts that model. Identity is cryptographic: peers authenticate with key pairs, so there is no password to phish, reuse, or reset via email, and an attacker presenting an unknown key receives cryptographic silence; the daemon simply does not respond, leaving nothing to brute-force and nothing for a scanner to fingerprint. Scoping is enforced at the crypto layer rather than by firewall convention: AllowedIPs defines precisely which hosts and subnets each peer may reach, so a compromised peer grants only its narrow slice of the network rather than a directory listing of every machine you own. Revocation is a deleted peer line, effective immediately, and no third party sits in the traffic path able to decrypt, broker, or be breached on your behalf.

Posture checks raise the bar further. Access can be made conditional not merely on possessing a valid key, but on the connecting device being healthy and managed (disk encryption enabled, patches current, endpoint protection running, enrolment verified), enforced at provisioning or connection time through the mesh's orchestration layer, or through MDM-gated key issuance for a hand-rolled deployment. A stolen key on an unmanaged, compromised laptop then yields nothing. Hosted support tools generally authenticate the account and occasionally flag the session; they have no equivalent interest in the state of the device doing the connecting.

The final layer is what runs inside the tunnel. With the mesh in place, RDP, VNC, or NoMachine listeners are bound to the tunnel interface or reachable only from the mesh subnet, and simply do not exist as far as the public internet is concerned; an attacker cannot probe a service they cannot route to. That removes entire classes of attack at a stroke: no internet-facing RDP to brute-force, no standing exposure to the next remotely exploitable protocol flaw, no vendor broker to subvert. Reaching a desktop then requires two independent credentials from two separate trust domains (the WireGuard key and the operating system login), while the traffic itself never transits anyone else's infrastructure, and the session logs stay where you can see them.

The trade-off is real, and it is the reason the hosted market exists. A self-managed mesh costs you provisioning discipline, key lifecycle management, and your own NAT traversal and uptime, and it does not offer the login, click and go simplicity that makes support of unattended devices painless. Where that capability is genuinely required, the compensating controls carry full weight: enforced MFA, unattended access restricted to proven need, IP allowlisting where offered, and regular log review. But for your own estate, the servers and workstations you administer every day, convenience is not a feature worth renting risk for. The always-online agent is not a shortcut around building the mesh; it is a standing invitation that the mesh was built to make unnecessary.

This is precisely the gap that GENAccess, our fully managed WireGuard service, was built to close. GENAccess delivers the architecture described above without the operational burden: device posture checks, tightly scoped access policies, geolocking, full auditing, and MFA as standard, with provisioning, key lifecycle, NAT traversal, and uptime handled by us rather than by your team. Your engineers get NoMachine, VNC, or RDP access to exactly the systems their role requires, and everything else gets cryptographic silence.

The fixed-point-in-time nature of this article matters. A vendor that looks clean today may disclose an incident tomorrow; a vendor with a previous breach may now have a much stronger security posture than less-tested competitors. The sensible conclusion is not to pick a brand on familiarity alone, but to choose deliberately: do your research, enable MFA, restrict unattended access to genuine business need, review logs regularly, and assume that convenience without security controls is a liability waiting to mature.

Finally, it is only fair to state how we handle this ourselves. GEN uses hosted remote support tools of the kind listed above strictly for ad-hoc support of client devices: a session is requested, the work is completed, and the tool is then removed, leaving nothing resident on the device, nothing left on the network, and nothing left to exploit once the session has ended. We previously used ConnectWise ScreenConnect for this purpose, but transitioned to Splashtop following their security incident, a decision reinforced by the platform becoming effectively unusable after we were locked out for 'security' reasons on several occasions. Products in this category have their place, but that place is a temporary, attended session rather than a permanent presence on your network.