The remote support tool your help desk uses to fix a laptop is the same kind of tool attackers persuade your staff to install. CISA advisory AA23-025A described help-desk-themed phishing and callback campaigns in which criminals had victims run portable remote support executables, with no installation and no admin rights, and then used the session for fraud. The joint CISA, NSA, FBI, MS-ISAC and INCD Guide to Securing Remote Access Software (June 2023) explains why this works: these tools are often signed with valid certificates, are not flagged by security products, and can run as portable executables that bypass some software controls. This vendor-neutral buyer's guide covers attended help desk support and screen sharing: session consent, technician authentication, logging, allowlisting and abuse prevention. Privileged access for vendors and administrators to servers is a different category, covered in the Privileged Remote Access Buyers Guide.
Key takeaways
- Pick one tool and block the rest. An approved tool only reduces risk if application control stops every other remote support tool, including portable versions.
- Bind sessions to your identities. Technicians should sign in through your identity provider with phishing-resistant MFA, and users should be able to see who is connecting and why.
- Consent and visibility must be on by default. The user should approve each session and see when control or file transfer starts.
- Logs belong to you. Session metadata, recordings and admin changes should flow to your SIEM, beyond the reach of tool administrators.
- Self-hosted servers are internet-facing infrastructure. An authentication bypass in a self-hosted remote support server was added to CISA's Known Exploited Vulnerabilities catalogue in February 2024 with known ransomware use, so patch speed is a selection criterion.
Define requirements
- Use cases: attended support for staff (user present), unattended access to kiosks or shared devices, support for customers outside your estate, and simple screen sharing in meetings. Each carries different risk; many organisations need only the first.
- Platforms: Windows, macOS, Linux, iOS, Android and whether elevated actions (UAC prompts) must be handled.
- Who connects: internal help desk, outsourced service desk or managed service provider. CISA's guide says to treat MSP accounts that reach customer environments as privileged and to require contracts that oblige providers to log activity and notify incidents.
- Deployment model: vendor cloud or self-hosted server, and who patches it.
- Help desk process: how the caller's identity is verified before a session starts. See the Account Recovery and Help Desk Security Guide.
- Regulatory constraints: recording consent, data residency for recordings, and screens that show regulated data.
Capability areas
| Area | What to look for | Abuse it prevents |
|---|---|---|
| Technician authentication | SSO via SAML or OIDC, enforced phishing-resistant MFA, no local accounts, deprovisioning through SCIM or the identity provider | Stolen technician credentials (ATT&CK T1078 Valid Accounts) |
| Session initiation | Sessions started by a technician from a ticket, short-lived codes, binding to the managed device, no inbound sessions from unknown accounts | Attacker-initiated sessions to staff devices |
| User consent and visibility | Mandatory consent prompt showing technician name and organisation, visible session banner, separate consent for control, file transfer and elevation, one-click end | Silent or misrepresented access |
| Tenant restriction | Agent that only accepts sessions from your tenant; ability to stop the client connecting to other organisations' accounts or free accounts | Callback scams using the same product under an attacker account |
| Granular permissions | Role-based rights: view only, control, file transfer, clipboard, scripting, unattended access, per device group | Over-privileged technicians; CISA recommends reduced-privilege roles |
| Scripting safeguards | Approval for scripts and mass actions; step-up MFA when one account acts on many devices | Mass deployment from a compromised console |
| Logging and recording | Session start, end, technician, device, IP, actions, file transfers; optional recording; export to SIEM; logs that tool admins cannot delete | Undetected misuse; CISA asks developers for audit logs that are hard to delete or alter |
| Deployment hygiene | Signed MSI or PKG packages, central policy, no portable mode allowed on managed devices, published allowlisting identifiers (publisher, hashes, domains) | Portable executables that bypass installation controls |
| Vendor security | Patch cadence for self-hosted servers, vulnerability disclosure, signing key protection and a plan for certificate revocation | Supply chain compromise of the tool itself |
Cloud or self-hosted
Vendor cloud removes the internet-facing server you would otherwise patch, but your sessions depend on the vendor's own security. Self-hosting gives control over data location and network paths, and makes you responsible for patching an exposed service quickly. Small organisations without a dedicated infrastructure team usually do better with cloud. Large or regulated organisations that self-host should publish the server only through approved routes, which matches CISA's advice to permit remote access software only from inside the network or through a VPN or VDI. See the Secure Remote Access Beyond VPN Guide.
Evaluation criteria
| Criterion | Minimum acceptable | Strong |
|---|---|---|
| Identity | SSO and enforced MFA | Phishing-resistant MFA, no local accounts, automatic deprovisioning |
| Consent | User prompt for attended sessions | Per-capability consent, technician identity shown, policy cannot be disabled by technicians |
| Tenant lock | Managed agents tied to your account | Client blocks connections from any other tenant or free account on managed devices |
| Least privilege | Technician and admin roles | Per-capability, per-device-group rights; unattended access as a separate approval |
| Audit | Session history in console | Full session metadata to SIEM in near real time, tamper-resistant, optional recording |
| Allowlisting support | Signed binaries | Documented publisher, paths and domains so all other tools can be blocked |
| Vendor assurance | Security attestation | Fast patching record, disclosure programme, clear signing key incident process |
Questions to ask vendors
- Can we enforce SSO and phishing-resistant MFA for every technician, with no local or break-glass accounts outside our control?
- Can our managed devices be restricted so the client only accepts sessions from our tenant?
- Which consent prompts can technicians or admins turn off, and is that change logged and alerted?
- What exactly is logged per session, how quickly does it reach our SIEM, and can a tool admin delete it?
- Do you offer a portable or run-once client, and can we block it on our devices while still supporting customers?
- How do you detect and stop abuse of free trials and free accounts, which CISA notes are often exploited?
- What is your average time to release a fix for a critical vulnerability in the self-hosted server?
- If your code signing key were compromised, how would we be told and how would we replace agents?
Red flags
- Technician accounts managed only inside the tool, with optional MFA.
- Unattended access enabled by default on every agent.
- Consent prompts that technicians can suppress without an admin policy.
- Session logs that are only viewable in the console, or can be purged by any admin.
- No way to stop your staff's devices joining sessions from other organisations.
- Slow or opaque disclosure of vulnerabilities in self-hosted servers.
Proof of concept
- Integrate SSO and MFA, then disable a technician in the identity provider and confirm sessions end and sign-in fails.
- Run attended sessions on Windows and macOS and check the consent prompts, technician identity display and session banner.
- From a separate free or trial account of the same product, try to connect to a managed device. The correct result is a block.
- Apply application control (for example WDAC or AppLocker on Windows) to allow the approved client and block other remote support tools, including portable executables, then test a few common alternatives in audit mode first.
- Stream session logs to the SIEM and build alerts for unattended sessions out of hours, file transfers and one technician touching many devices. See the MITRE ATT&CK T1219 Remote Access Tools for detection ideas.
- Run a help desk social engineering exercise and confirm caller verification happens before any session. Use the Help Desk Social Engineering Incident Playbook for the response path.
How NHI Mgmt Group can help
We provide independent requirements and evaluation support for identity, privileged access and endpoint programmes, including technician identities and the agent credentials that remote tools rely on. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Privileged Remote Access Buyers Guide · MITRE ATT&CK T1219 Remote Access Tools · Recognising Tech Support Scams Guide · Vishing and Help Desk Social Engineering Awareness Guide