Remote Access Security Checklist: Hardening, Session Recording and Backups

This checklist is for sysadmins, help-desk leads and MSP technicians who run remote desktop and remote support tools on real networks. Remote access software is internet-facing, runs with high privileges, and one stolen technician login opens every machine. The short answer is the same for every product: keep the tool patched, never publish RDP or VNC directly, require MFA wherever a session starts, give technicians only the rights they need, record what happens, and back up the servers that broker your sessions so you can rebuild them in an afternoon.

Still picking a product? Start with our comparison of free remote desktop software or the guide to self-hosted remote access.

The short list

Patch the remote tools before anything else

One bug in a remote tool bypasses every other control. Recent vendor bulletins:

• ScreenConnect. In February 2024 the authentication bypass CVE-2024-1709 was widely exploited on unpatched on-premises servers. In September 2026 version 26.6.5 fixed CVE-2026-84869 (CVSS 9.9), allowing unauthorised file transfer and execution through an active session; on-premises servers had to update or remove the TransferFiles permission meanwhile.
• TeamViewer. Bulletin TV-2026-1010 lists five high-severity flaws (CVSS 7.0–8.8) in the Full client and Host, fixed in 15.82 and in patched legacy builds. No exploitation was reported, but Host installs on servers should be updated now.
• Sunlogin. Sunlogin Remote (AweSun) builds older than 11.0.0.33 carry remote code execution flaws (CNVD-2022-10270, CNVD-2022-03672) that attackers used to drop RATs and cryptominers.
• AnyDesk. After its February 2024 production-system compromise, AnyDesk revoked the old code-signing certificate; installers saved before then should be replaced.
• Dameware. Old MRC agents had published vulnerabilities such as CVE-2019-3980; 12.2.x reaches end of life on 24 October 2026.
• RustDesk Server. OSS 1.1.16 closed an unauthenticated UDP punch-hole issue that could be abused for reflection and amplification. OpenVPN 2.7.7 is likewise mainly a security release.

Find out what is actually installed. Remote tools arrive through one-off sessions and scammer calls, not only through your deployment system:

Get-ItemProperty HKLM:SoftwareMicrosoftWindowsCurrentVersionUninstall*,
  HKLM:SoftwareWOW6432NodeMicrosoftWindowsCurrentVersionUninstall* |
  Where-Object { $_.DisplayName -match 'ScreenConnect|TeamViewer|AnyDesk|RustDesk|Sunlogin|AweSun|Wayk|DameWare' } |
  Select-Object DisplayName, DisplayVersion

Keep one approved tool per job, remove the rest, and block unapproved ones in application control. Wayk Now and Wayk Bastion get no security fixes since 2021: uninstall the agents, close their firewall rules and move to Devolutions Gateway, RustDesk Server or MeshCentral.

Never publish RDP or VNC directly

An open TCP 3389 or 5900 is found by scanners within hours and brute-forced around the clock. Put one of these in front instead:

• A VPN. WireGuard stays silent to unauthenticated packets, so a scan does not even reveal it. OpenVPN works over TCP 443 and supports certificate revocation with crl-verify. Push only the management subnet, not a full tunnel.
• A gateway. Apache Guacamole exposes only an HTTPS login page and keeps guacd (TCP 4822) on localhost. Microsoft RD Gateway carries RDP over HTTPS on 443. Devolutions Gateway, the successor to Wayk Bastion, listens on 7171 for web sessions; 8181 only needs to be reachable if native clients connect from outside.
• An SSH jump host. Royal TS Secure Gateway tunnels RDP and VNC through SSH, so 3389 and 5900 stay closed outside.

On the Windows hosts themselves, keep Network Level Authentication on and allow RDP only from the VPN or gateway subnet:

Disable-NetFirewallRule -DisplayGroup "Remote Desktop"
New-NetFirewallRule -DisplayName "RDP from VPN only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 10.20.0.0/24 -Action Allow

Require MFA wherever a session can start

Every login that leads to a remote session needs a second factor: the vendor account, the self-hosted console and the VPN.

• TeamViewer: enable two-factor authentication on every account and assign devices to the company account instead of sharing permanent passwords.
• AnyDesk: protect Unattended Access with a unique password plus two-factor authentication on the remote device.
• Guacamole: install the TOTP or Duo extension, or sign in through SAML or OpenID Connect, before the login page is reachable from the internet.
• MeshCentral: force 2FA for every account and stop self-registration in config.json:

"domains": {
  "": {
    "newAccounts": false,
    "passwordRequirements": { "force2factor": true }
  }
}

WireGuard has no user accounts: whoever holds a private key is in, so protect key files and remove peers the day someone leaves. OpenVPN can add username and password checks through LDAP or RADIUS plugins on top of certificates. Remote Desktop Manager Free supports MFA on its local vault, which matters because that vault holds every server password you use.

Apply least privilege to technicians and agents

• Role-based access. In ScreenConnect, give technicians roles limited to their session groups rather than full control of every agent, and grant file transfer and command permissions only to those who need them. MeshCentral rights are set per device group and per user; Guacamole users only see connections assigned to their group.
• Know the OSS limits. RustDesk Server OSS has no user accounts or access control: anyone with your server address and key can register devices. Treat the key as internal; control roles and audit logs come with Server Pro.
• Scope network rules. Allow the Dameware MRC agent (TCP 6129) only from the help-desk subnet in the Domain profile; narrow WireGuard AllowedIPs to the ranges each person needs.
• Unique local admin passwords. Use Windows LAPS so one leaked local password does not unlock the whole fleet.
• Shared lists, not shared passwords. Royal TS references credentials by name, so a team document carries no secrets; RDM Free links sessions to one credential entry you rotate in one place.
• Low-privilege services. Run the MeshCentral server under a dedicated user, as its docs recommend; this disables self-update, so schedule manual updates.

Record sessions and keep audit logs

Decide what to record, where files go and how long you keep them.

• ScreenConnect has audit logs and optional session video recording (extended auditing); recordings need extra disk on on-premises servers.
• Guacamole records any connection when you set recording-path and create-recording-path = true in its parameters. guacd writes the files, so in Docker mount a volume into the guacd container. Convert recordings to video with guacenc.
• MeshCentral records by protocol (1 terminal, 2 desktop, 5 files) with a retention limit:

"sessionRecording": {
  "filepath": "/srv/mesh-recordings",
  "index": true,
  "maxRecordingDays": 90,
  "protocols": [1, 2, 5]
}

• Devolutions Gateway records sessions it proxies; LogMeIn Resolve includes session recording, and AnyDesk offers it depending on the plan.
• RDM Free keeps a local activity log you can export to CSV; central audit trails need its paid editions.

Ship logs and recordings off the server. An attacker with admin on the broker can delete local evidence.

Harden the self-hosted servers

• MeshCentral has no default login: the first account created becomes administrator, so create it before the server is reachable from the internet.
• Guacamole’s database schema creates guacadmin / guacadmin; change or replace it at first sign-in and keep port 8080 behind an HTTPS reverse proxy.
• RustDesk Server needs only TCP 21115–21117 and UDP 21116; open 21118–21119 only for the web client.
• Tell users to accept sessions only from your own ScreenConnect instance and never to install TeamViewer or AnyDesk for an unsolicited caller.

Back up and test-restore your remote-access stack

If the broker dies, you lose access to everything at the moment you need it most. A lost RustDesk key means reconfiguring every client; a lost MeshCentral data folder means rebuilding the console and re-enrolling agents. Know exactly what to save:

Typical jobs:

# RustDesk Server (Docker): stop briefly for a consistent SQLite copy
docker compose stop hbbs hbbr
tar czf /backup/rustdesk-$(date +%F).tgz data
docker compose start hbbs hbbr

# Guacamole with PostgreSQL
docker compose exec -T postgres pg_dump -U guacamole_user guacamole_db 
  > /backup/guacamole-$(date +%F).sql

MeshCentral can back itself up; backupOtherFolders adds the files and recordings folders, and external databases need pgDumpPath, mysqlDumpPath or mongoDumpPath:

"settings": {
  "autoBackup": {
    "backupIntervalHours": 24,
    "keepLastDaysBackup": 14,
    "backupPath": "/srv/meshcentral-backup",
    "backupOtherFolders": true,
    "zipPassword": "store-this-in-your-vault"
  }
}

The checklist for jobs, reports and test restores:

1. List every file above for each server; private keys go only into encrypted backups.
2. Run a daily job, then copy it off the host with Restic or Borg to storage the server cannot delete.
3. Back up before every upgrade, especially ScreenConnect, MeshCentral and RDM, which change often.
4. Alert on failure and on silence: a job that has not reported in two days is a failed job.
5. Review a weekly report of sizes and dates; a backup that suddenly shrinks is missing data.
6. Verify the repository itself, for example restic check --read-data-subset=1/10 on a rotating subset.
7. Test-restore each quarter onto a clean VM: start the service, confirm a client connects without reconfiguration (same key, same certificate), log in with MFA and play back one recording.
8. Write down how long the restore took and what you had to fix, then update the runbook.

How to choose

1. List who connects to what: technicians to user PCs, admins to servers, contractors to one application.
2. For user PCs, prefer a tool with roles and audit logs (ScreenConnect, LogMeIn Resolve, RustDesk Server Pro or MeshCentral) over shared IDs and passwords.
3. For servers, use a VPN or gateway plus a connection manager such as RDM Free or Royal TS; do not install a consumer-style remote tool on every server.
4. If sessions must stay on your infrastructure, self-host, and accept that patching, TLS and backups become your job.
5. Before signing off, confirm MFA, recording, a working restore and a named owner who reads the security bulletins.

FAQ

Is it safe to expose RDP to the internet with a strong password?

No. Exposed RDP is scanned and brute-forced constantly, and password strength does not help against protocol vulnerabilities. Put it behind a VPN such as WireGuard or OpenVPN, or a gateway such as Guacamole or RD Gateway, and keep NLA on.

How do I enable session recording in Apache Guacamole?

Set recording-path to a directory guacd can write and create-recording-path to true in the connection parameters. Recordings can be played back or converted to video with guacenc.

What do I need to back up on a RustDesk server?

The key pair id_ed25519 and id_ed25519.pub, plus db_v2.sqlite3. Without the keys every client must be reconfigured with a new key.

Do TeamViewer and AnyDesk support two-factor authentication?

Yes. TeamViewer supports 2FA on accounts, and AnyDesk supports two-factor authentication for unattended access. Turn both on for any machine reachable without a user present.

Is self-hosted remote access more secure than a cloud tool?

Not by default. Self-hosting keeps sessions on your infrastructure, but you inherit patching, TLS, MFA and backups. A cloud tool patched by the vendor with MFA enforced can be safer than a forgotten MeshCentral or ScreenConnect server.

How often should I test-restore remote access servers?

At least quarterly, and after every major upgrade. A test counts only if a real client connects to the restored server without reconfiguration.

Last updated: 1 October 2026 · CtrlRemote editorial team. Licence, version and platform details are checked against each developer's official documentation.