What Is a Remote Support Appliance and What Can It Reach?

A remote support appliance is the server that brokers help desk sessions between your technicians and the machines they fix. Products such as BeyondTrust Remote Support (formerly Bomgar) run it as a self-hosted appliance or as SaaS. It holds technician accounts, persistent agents on endpoints and often stored credentials, so whoever controls the remote support appliance can reach every system it supports. That reach is why attackers target it.

What is a remote support appliance?

A remote support appliance is a central server that authenticates support staff, relays their screen and file sessions to end-user or server endpoints, and records what happened. Technicians connect to it, and endpoints connect to it, so it sits in the middle of every support session.

Most products ship it in three forms: a hardware appliance, a virtual appliance you run in your own hypervisor or cloud account, or a vendor-hosted SaaS instance. The self-hosted forms are usually exposed to the internet, because remote users and the endpoints they support have to reach it from outside the office.

What does a remote support appliance hold?

It holds the keys to every machine it can open a session on: accounts, endpoint agents, access roles and often stored passwords.

In the BeyondTrust model, which the CVE-2026-102764 investigation describes in detail, that includes:

• Administrative accounts for two separate portals: the /appliance interface that manages the box itself and the /login interface that manages users, policies and sessions.
• Jump Clients and Jumpoints: agents installed on endpoints, or relay points inside a network, that let an authorized technician start a session without anyone at the other end clicking "accept".
• Jump Items and roles: the list of machines a user can reach and what they can do there. A role change from "No Access" to "Administrator" is a single setting.
• A credential vault (Remote Support Vault) and optional integration with an enterprise password manager, used to inject credentials into sessions.
• API accounts, directory bind accounts and SAML signing keys that connect the appliance to your identity systems.
• Integration secrets for SMTP, syslog and ticketing connectors.
• Session recordings and file transfer history, which often contain whatever a technician typed or copied during a fix.

Put together, the appliance is an access broker for a large share of your fleet. If you already classify identity systems and backup servers as tier-0, this belongs on the same list. We made the same argument in why your backup server is a tier-0 target.

How do attackers use a compromised remote support appliance?

They use it the way your technicians do. Once they control it, they can open sessions to downstream endpoints with legitimate tooling, which blends into normal help desk traffic.

The ARMORY CASTLE intrusion that Google Threat Intelligence Group reported in October 2026 followed that pattern. After a web shell gave them a foothold, the operators escalated to root on the appliance, tried to dump the credential vault with the product's own secrets utility, then logged into the admin portal with a stolen Administrator account. They raised a local account's Jump Item and Team roles to Administrator, started support sessions to internal machines and used the built-in file transfer feature to collect documents. They also tunneled traffic through the appliance's own HAProxy front end and deleted logs as they went.

None of the downstream activity required malware on the endpoints. The appliance already had the access.

Why are remote support appliances hard to inspect?

Vendors lock down the underlying operating system, so customers cannot audit the file system or run their own endpoint agent on it. You see the application's logs and settings, not the host.

That has two consequences. First, an attacker with root on the host can delete local logs and leave persistence that survives reboots and configuration resets, as GTIG observed. Second, your evidence has to come from outside the box: forwarded syslog, reverse proxy and WAF logs, firewall logs and exported session reports. If you are not forwarding those today, you will have little to work with after an incident. Our guide on how to audit remote support logs for role escalation covers what to collect and what to look for.

Self-hosted versus SaaS

SaaS moves patching to the vendor. In the CVE-2026-102764 case, BeyondTrust patched every SaaS tenant on 9 October 2026, before public disclosure, while self-hosted customers had to apply patch BT26-05-RS themselves. One of the two known victims was a vendor-hosted instance, though, so SaaS is not immune; it just shortens the patch gap.

Either way, the data inside the appliance is yours to protect. Credential rotation, role review and session review apply to both models.

How to reduce what the appliance can expose

GTIG's hardening guidance for BeyondTrust maps well to any remote support product:

1. Keep the admin portals off the internet. Only the technician console, customer portal and Jump Client traffic need to be reachable from outside. Restrict /login and /appliance to administrative networks.
2. Use SSO with phishing-resistant MFA for every portal user, and remove local accounts except one vaulted break-glass account that alerts on use.
3. Default to no access. Set the default Jump Item role in every group policy to "No Access" and grant roles through policy, not per user.
4. Keep privileged credentials out of the appliance. Store them in an external vault with credential injection, and keep only non-interactive service account credentials on the box.
5. Filter egress. Allow outbound traffic only to the vendor's update and licensing endpoints plus your own syslog and directory servers.
6. Forward logs off the appliance to a SIEM over TLS, with retention long enough to cover a multi-month exposure window.

These controls do not replace patching, but they shrink what an attacker gets on the day a new zero-day lands. When that day comes, the order you rotate secrets in matters, which we explain in why you rotate credentials only after the rebuild.