How to Harden RDP on a Windows VPS: 8 Settings That Stop Brute-Force Attacks

Every Windows VPS that exposes Remote Desktop on the default port 3389 gets hit by brute-force attempts — usually within hours of deployment. The Windows event log on a fresh, unprotected instance routinely shows hundreds of failed logon events per day, most of them from botnets cycling through username/password lists. The good news is that a small set of configuration changes, none of them requiring third-party software, stops the overwhelming majority of these attacks. Here are eight RDP hardening settings that actually work on a Windows VPS.

1. Enable Network Level Authentication (NLA)

NLA requires the client to authenticate before a full RDP session is established, which means unauthenticated scanners and most automated attack tools are rejected at the door instead of consuming a session. It is enabled by default on Windows Server 2022 and 2025, but verify it on older images: open System Properties → Remote and confirm “Allow connections only from computers running Remote Desktop with Network Level Authentication” is checked. NLA also reduces the server load from connection floods, since the CPU-heavy session initialization only happens for authenticated users.

2. Enforce an Account Lockout Policy

Account lockout is the single most effective defense against password guessing. Open Local Security Policy → Account Policies → Account Lockout Policy and set a threshold of 5 failed attempts with a 15-minute lockout duration. This turns a botnet that can try thousands of passwords per minute into a botnet that locks the account after five tries. The trade-off is that legitimate users can also lock themselves out, which is why a lockout duration of 10–15 minutes is the sweet spot — long enough to deter attackers, short enough not to annoy your team.

3. Change the Default RDP Port

Port 3389 is the first thing every RDP scanner probes. Moving RDP to a high, non-standard port (for example, 54389) requires a registry change under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp and a matching firewall rule, plus clients that specify the new port. This is security by obscurity — a determined attacker can discover the port with a full scan — but it filters out the vast majority of opportunistic botnet traffic, which only targets 3389. It costs ten minutes and eliminates most of the noise in your event log.

4. Restrict RDP by Source IP in the Firewall

If your team connects from a static office IP or through a VPN endpoint, add an inbound Windows Defender Firewall rule that only allows RDP from those addresses and blocks it from everywhere else. This is stronger than any authentication setting, because the attack never reaches the RDP service at all. If your provider offers a network-level firewall or security group in its control panel, apply the same allowlist there — filtering at the network edge protects you even if the Windows firewall is ever misconfigured or disabled.

5. Disable the Built-In Administrator Account

Brute-force scripts almost always try Administrator as the username first, because it exists on every Windows system. Rename it via Local Users and Groups, and — more importantly — disable it once you have a second account with administrator rights. Create a dedicated admin user with a non-obvious name, use that for daily administration, and keep the renamed built-in account disabled. This single change removes the most common username from every automated attack list in existence.

6. Require Strong Passwords and Disable Blank Passwords

Windows Server enforces password complexity by default, but legacy images and manually created accounts can slip through with weak or blank passwords. Run net accounts to verify the password policy, and confirm that “Limit blank passwords to console logon only” is disabled in Local Security Policy. For extra protection on servers facing the internet, consider a 14+ character minimum — modern GPU-based cracking tools can exhaust 8-character NTLM hashes in hours, while 14+ character passphrases remain impractical to brute-force.

7. Put RDP Behind a VPN or RD Gateway

The most secure configuration is to not expose RDP to the public internet at all. Run a VPN server (WireGuard or OpenVPN) on the same VPS and require clients to connect to the VPN before they can reach the RDP port, or deploy Remote Desktop Gateway, which fronts RDP with an HTTPS endpoint that supports MFA. This is more setup work, but it changes your exposure model completely: instead of defending a public login service, you defend a VPN endpoint with authenticated, encrypted tunnels. For teams of more than a handful of users, the RD Gateway route is the professional standard.

8. Audit Failed Logons and Set Up Alerts

Hardening without monitoring leaves you blind. Enable auditing of logon events (Event ID 4625 for failures, 4624 for successes) via Local Security Policy → Advanced Audit Policy, then check the count periodically with PowerShell: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} | Measure-Object. A sudden spike in failed logons is your early-warning signal that something is probing the box. Free tools like RDPGuard or Windows Defender Firewall’s built-in IP filtering can auto-block IPs after a threshold of failures, adding an automated response on top of your manual monitoring. If you are setting this up across multiple servers, providers with snapshot and template features make it easy to replicate the same hardened baseline — compare Windows VPS plans on our comparison table to see which hosts offer them.

Putting It Together

Settings 1, 2, 5, and 6 take about 20 minutes total and eliminate the vast majority of automated attacks by themselves. Settings 3, 4, and 7 add layers for anyone connecting over the public internet. And setting 8 makes sure you notice if anything slips through. When you are evaluating providers, check whether they offer network-level firewalls, DDoS protection, and snapshots — features that make RDP hardening dramatically easier — and compare Windows VPS plans on our comparison table to see which hosts include them.

For an affordable test environment to practice these settings on, InterServer’s Windows VPS is available for $0.01 for the first month with code TRYINTERSERVER. If you need a production box with hourly billing for quick iteration, Vultr’s Windows instances are a solid choice. Whichever you pick, apply these eight settings before you do anything else — the brute-force attempts will start arriving long before you finish reading this article.