Remote Desktop Protocol (RDP) is one of the most scanned-for and most-attacked services on the internet. Security researchers consistently find millions of RDP servers directly exposed to the internet with weak credentials, and ransomware groups routinely use RDP as the initial access vector for their most damaging corporate attacks. Within minutes of an RDP port becoming accessible on the internet, automated scanners will identify it and begin credential testing. Studies have shown newly-exposed cloud instances receive their first login attempt within seconds and thousands of attempts within hours. You’ll find the complete rundown in our Complete Guide to Online Security and Privacy.
At the same time, remote desktop is an irreplaceable tool for IT administrators, remote workers, and anyone who needs to access a computer at another location. The challenge is making remote desktop access secure without eliminating the convenience it provides.
Why default RDP is dangerous
Windows enables RDP as a service listening on port 3389, accepting connection attempts from anywhere, relying entirely on the account password for authentication. This default configuration fails against:
Tightening that exposure with firewall scoping is the right move, but it is also a common way people end up locking themselves out — if after hardening you find a firewall is blocking Remote Desktop, the fix is to scope the rule to your own IP rather than removing it.
- Automated credential stuffing (no rate limiting on authentication attempts)
- Brute force campaigns (unlimited attempts without lockout)
- Username enumeration (failed login responses differ between non-existent and wrong-password accounts)
- Protocol-level exploits (BlueKeep, DejaBlue — unauthenticated code execution through RDP patched by Microsoft but actively exploited against unpatched systems)
The most serious failure mode: ransomware deployment. Groups specifically target weakly-secured RDP because an authenticated administrator session allows disabling antivirus, deleting backups, encrypting all network-accessible storage, and demanding ransom — all in one session. These attacks regularly cost small businesses and hospitals millions of dollars and weeks of operational disruption.
The step-by-step secure configuration
- Never expose RDP directly to the internet. This is the single most important principle. If any computer on the network has RDP enabled and the router forwards port 3389 from the internet to that computer, it is directly exposed. Remove any port forwarding rules for port 3389 from the router immediately.
- Use a VPN as the access gateway. The correct architecture places a VPN in front of RDP: remote users connect to the VPN first (authenticating at the network level), then access RDP through the private VPN tunnel. RDP remains on port 3389 internally but is inaccessible from the internet without first establishing the VPN connection. This single architectural change eliminates the majority of automated RDP attacks by removing internet exposure entirely. Our guide on setting up a VPN on Windows 11 covers the configuration. For home users, many Asus, Netgear, and Synology routers include built-in OpenVPN or WireGuard server functionality — VPN-gated RDP access without cloud service dependency.
- Enable Network Level Authentication (NLA). NLA requires authentication before the RDP session is established — as opposed to the default where the session initiates before authentication, exposing the RDP login screen to unauthenticated callers. Enable NLA: System Properties → Remote tab → check “Allow connections only from computers running Remote Desktop with Network Level Authentication.”
- Enable account lockout policy. Configure Windows to block login attempts after a small number of failures (5–10 attempts) for a period (30 minutes). Without lockout, an automated attack can try thousands of passwords per second indefinitely. Group Policy → Computer Configuration → Windows Settings → Security Settings → Account Policies → Account Lockout Policy.
- Restrict which accounts can use RDP. System Properties → Remote tab → Select Users → explicitly list only the accounts that need remote access. Do not allow the default Administrator account to connect via RDP. Create a dedicated non-administrator account for RDP access — gaining administrative access through UAC prompts after connection rather than arriving with administrator rights.
- Restrict RDP source IPs in Windows Firewall. If remote access comes from a predictable set of IP addresses (home ISP, a corporate office, VPN exit node), configure the Windows Firewall RDP rule to allow connections only from those specific addresses. Firewall → Inbound Rules → Remote Desktop → Properties → Scope → restrict remote IP addresses.
- Change the RDP port from 3389 (supplementary). Changing to a non-standard port (e.g., 52841) reduces automated scanning hits. This is security through obscurity — not a sufficient defence alone, but filters out scanners that only probe port 3389. Registry: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp → PortNumber. Update the firewall rule to match.
Step 2 — VPN-gated access — is the most important step because it fundamentally changes the attack surface. Every other step reduces risk while RDP remains at least partially accessible; VPN gating eliminates the direct exposure entirely.
Alternatives to RDP that are architecturally safer
| Tool | Architecture | Best for | Considerations |
| Tailscale | WireGuard mesh VPN — no exposed ports on either end | Personal remote access, small teams, home-to-office | Free for up to 100 devices; requires enrollment on both devices; simplest secure setup |
| Chrome Remote Desktop | Tunnels through Google infrastructure | Personal access, IT support scenarios | Google account dependency; no MFA on connection itself; appropriate for personal use |
| TeamViewer / AnyDesk | Managed service via vendor infrastructure | IT support, managed service providers | Commercial licensing; vendor dependency; appropriate for professional support scenarios |
| Windows 365 / Azure Virtual Desktop | Cloud-hosted managed VM | BYOD remote workers in enterprise environments | Corporate network inside; personal device provides only display/input — strongest architecture for BYOD |
Tailscale for home users is worth highlighting specifically. Install Tailscale on the home computer and the remote device → sign in to the same account on both → enable RDP on the home computer → from the remote device, connect using RDP to the home computer’s Tailscale IP address (shown in the Tailscale app as the 100.x.x.x address). Total setup time: approximately 15 minutes. The result: a secure remote desktop connection with no ports exposed to the internet, no external scanning reaching the RDP service, and authentication required at both the Tailscale level and the Windows account level. Safer than most corporate RDP deployments, with zero infrastructure cost.
Monitoring and audit
Implementing secure remote desktop controls is the first step; monitoring their effectiveness is the ongoing practice. Windows Event Logs record every RDP authentication event:
- Event ID 4625 (failed login) with Logon Type 10 (remote interactive) — shows volume of failed attempts, usernames being targeted (attackers commonly try “Administrator,” “admin,” “user,” “guest”), and source IP addresses
- Event ID 4624 (successful login) with Logon Type 10 — verify every successful login is legitimate
Access: eventvwr.msc → Windows Logs → Security → filter by Event IDs 4625 and 4624. High volume of 4625 events indicates automated scanning or brute force. Unfamiliar source IPs on 4624 events indicates a potential unauthorised successful login.
For proactive detection: Windows Defender’s attack surface reduction rules — specifically the rule blocking credential theft from LSASS (the process RDP uses for authentication) — prevent the most common post-compromise actions even if an attacker gains initial RDP access through a valid credential.
Our guide on protecting against ransomware covers the backup strategy that makes RDP compromise a survivable incident, and our guide on VPN configuration on Windows 11 covers the VPN setup that gates RDP access. For Tailscale’s zero-port-forwarding security architecture documentation, Tailscale’s architecture documentation explains why the mesh VPN model eliminates exposure that traditional VPN + RDP doesn’t fully address.
BYOD remote work — the hardest secure remote desktop scenario
For organisations that must support remote desktop for employees working from home on personal computers, the secure remote desktop challenge is more complex because IT cannot enforce device-level security controls on personal machines.
The recommended architecture: Virtual Desktop Infrastructure (VDI) or cloud desktop solutions (Windows 365, Azure Virtual Desktop) where employees connect to a managed virtual machine rather than directly to the corporate network. The virtual machine sits inside the corporate security perimeter, managed and patched by IT; the employee’s personal device provides only the display and input — it has no direct access to corporate data or systems.
This “remote-in, display-out” model provides a fundamentally more secure architecture for BYOD environments than allowing personal devices to connect directly to corporate machines through RDP. Additional cost of VDI or cloud desktop licensing is typically justified by the security risk reduction and simplified endpoint management for distributed workforces.
RDP hardening checklist
| Control | How to configure | Priority |
| Remove port 3389 forwarding from router | Router admin panel → Port forwarding → remove any 3389 rules | Critical — do immediately |
| VPN before RDP | VPN server on router or separate device; Tailscale as simplest option | Critical |
| Enable NLA | System Properties → Remote → require NLA checkbox | High |
| Account lockout policy | Group Policy → Account Lockout Policy → 5-10 attempts, 30 min lockout | High |
| Restrict RDP accounts | System Properties → Remote → Select Users → limit to specific accounts | High |
| Firewall source IP restriction | Windows Firewall → Remote Desktop inbound rule → Scope → specific IPs | Medium |
| Non-standard port (supplementary) | Registry edit → PortNumber; update firewall rule to match | Low (supplementary only) |
| Event log monitoring | Event Viewer → Security log → filter for 4625 and 4624 with Logon Type 10 | Ongoing |
Work through this checklist from top to bottom — the critical items at the top address the attacks causing the majority of RDP-enabled ransomware compromises. The medium and low items add layers that reduce residual risk after the critical controls are in place. An RDP setup with the critical controls all implemented is orders of magnitude more secure than the default configuration and eliminates the most common attack vectors that ransomware groups exploit for initial access.
RDP on macOS and Linux — different considerations
This guide focuses on Windows RDP, but remote access on other platforms has its own security considerations:
macOS Screen Sharing (VNC-based): macOS uses Screen Sharing rather than RDP. System Settings → General → Sharing → Screen Sharing. The same principles apply: never expose VNC (port 5900) directly to the internet; use VPN or SSH tunneling; restrict access to specific users. macOS Screen Sharing over a Tailscale connection provides a simple secure architecture equivalent to the Windows RDP + Tailscale approach.
SSH for Linux: SSH is the standard remote access protocol for Linux systems. Securing SSH follows similar principles: disable password authentication in favour of SSH key authentication (edit /etc/ssh/sshd_config: PasswordAuthentication no; PubkeyAuthentication yes), change the default port (Port 22) to a non-standard port, restrict access to specific IP addresses in firewall rules, and use fail2ban to automatically block IPs with repeated failed authentication attempts. SSH tunneling can also provide secure remote access to other protocols running on the remote machine (VNC, RDP, web interfaces) without exposing those ports directly.
Secure remote desktop — on any platform — ultimately comes down to the same principle: the attack surface determines the risk, and the attack surface is primarily determined by what’s exposed to the internet. Taking the remote access service off the internet (through VPN gating, Tailscale’s zero-port-forwarding model, or SSH tunneling) eliminates the majority of attacks before any other controls need to operate. The controls that remain — credential strength, NLA, account lockout, event monitoring — then apply to an access path that’s already significantly constrained compared to direct internet exposure. See also Keep Your Phone Secure for a related case.
