How to Secure Remote Desktop (RDP) Against Brute-Force Attacks

Remote Desktop is the single most attacked service on a public Windows server. Botnets scan the internet for port 3389 around the clock, and ransomware operators routinely buy stolen RDP credentials or break in through brute force themselves — Microsoft’s own analyses have repeatedly listed RDP as one of the top entry vectors for ransomware. The good news: brute-force attacks are noisy, and Windows Server ships with the controls to stop almost all of them. This guide walks through how the attacks work and the layered settings that shut them down. If you are about to order a server, compare Windows VPS providers on our comparison table so you start with a plan that has the resources for proper hardening.

How an RDP brute-force attack actually works

A brute-force attack is a guessing game at scale. The pattern is consistent:

• A scanner finds your server because port 3389 responds. No prior knowledge of your IP is needed; the whole IPv4 range is swept continuously.
• The attacker tries common usernames (Administrator, admin, user, test) against dictionaries of leaked passwords and default credentials.
• Smart attackers throttle to a few attempts per minute per IP to stay under lockout thresholds, spreading the load across hundreds of botnet machines.
• One successful login — even to a low-privilege account — is enough to start reconnaissance, install persistence, and move laterally.

The important consequence: single-IP defenses are not enough, because the traffic comes from thousands of addresses. You need controls that make the attempts fail, not just one source.

The settings that stop most attacks

Setting	Recommended value	Where to change it
Account lockout threshold	5–10 failed attempts	Account Lockout Policy (Local Security Policy or Group Policy)
Lockout duration	15–30 minutes	Same policy
Network Level Authentication	Required	System Properties > Remote; or GPO under Remote Desktop Session Host > Security
RDP source restriction	Your IP range only	Windows Defender Firewall rule scope (Remote IP address)
Default RDP port	Changed from 3389	Registry: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber
Built-in Administrator account	Renamed or disabled	Local Users and Groups, or Security Policy
Empty-password accounts	None allowed	Account policy; audit with net user

Configure the account lockout policy

Windows Server 2016 and later apply a default lockout policy to local accounts (10 attempts, 10 minutes). Verify or tighten it: open secpol.msc and go to Account Policies > Account Lockout Policy. A threshold of 5, a lockout duration of 30 minutes, and a reset counter of 30 minutes is a sensible baseline for a single server. On domain-joined machines the domain policy wins, so set it in Group Policy at the appropriate OU instead. From an elevated prompt the equivalent one-liner is:

net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30

Note that lockout applies per account, not per source IP — which is exactly why the firewall restriction below matters: attackers rotating IPs can still rack up attempts against one account until the threshold trips.

Enforce Network Level Authentication

NLA requires the client to complete a CredSSP authentication before the login screen is even presented. Most botnet scanners never complete that handshake, so NLA alone filters out a large share of automated traffic. Enable it under System Properties > Remote > “Allow connections only from computers running Remote Desktop with Network Level Authentication,” or force it via Group Policy (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > “Require user authentication for remote connections by using NLA”). Older clients, such as unpatched Windows 7 machines, need the TLS 1.2 and CredSSP updates to pass NLA — worth checking before you flip it on.

Restrict RDP to known IP addresses

If your admin machines have static or predictable IP addresses, scope the firewall rule. In Windows Defender Firewall, open the inbound rule “Remote Desktop (TCP-In)” and, under Scope, set Remote IP address to your office or home ranges. PowerShell does the same:

Set-NetFirewallRule -DisplayName "Remote Desktop (TCP-In)" -RemoteAddress 203.0.113.0/24,198.51.100.7

Traffic from anywhere else is dropped before it reaches the RDP stack. If your IP changes often, pair this with a VPN or a Remote Desktop Gateway instead of opening the rule to the world.

Use the RDP brute-force protection in Windows Server 2025

Windows 11 24H2 and Windows Server 2025 ship with built-in RDP brute-force protection. After a configurable number of failed attempts, the feature applies a temporary lockout and can also account for geolocation and the account lockout policy. Enable it via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > “Enable RDP Brute Force Protection.” On older server versions, third-party tools or an RD Gateway fill the same role.

Put RDP behind a Remote Desktop Gateway

The most effective structural fix is to stop exposing 3389 entirely. A Remote Desktop Gateway listens on HTTPS (443) with a proper certificate and brokers connections to internal machines, so attackers cannot reach the RDP stack at all. Gateways also integrate with MFA: the Azure AD MFA NPS extension or third-party RADIUS providers (Duo, for example) require a second factor at the gateway before any session starts. For a small fleet this is the single biggest reduction in attack surface. When you size the server for gateway duty, see the full specs and pricing — the gateway itself is lightweight, but it should not compete with your workload for RAM.

Detect and respond: watch Event ID 4625

Every failed logon writes Event ID 4625 to the Security log, with Logon Type 10 marking RDP interactive attempts. A quick PowerShell query shows where the pressure is coming from:

Get-WinEvent -FilterHashtable @{LogName='Security';Id=4625} -MaxEvents 500 |
  ForEach-Object { $_.Properties[18].Value } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 10

Sustained 4625 floods from foreign IPs confirm you are being targeted and tell you whether the lockout policy is actually engaging. Pair the query with a scheduled task that emails you when the failure rate spikes, and review successful Logon Type 10 events (4624) periodically so you know every account that has ever logged in over RDP.

If you do not need RDP, remove it

RDP is optional for most administrative work. PowerShell remoting (WinRM) over HTTPS, Windows Admin Center in a browser, and OpenSSH on Windows all cover day-to-day administration without exposing the richest attack surface Windows has. If nothing on the box requires an interactive desktop, disable RDP entirely:

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -Value 1

Baseline hardening checklist

• Account lockout: threshold 5–10, duration 15–30 minutes.
• NLA enforced, and clients verified to support it.
• Firewall rule for RDP scoped to your IP range.
• Built-in Administrator renamed or disabled; no empty passwords.
• RDP port changed from 3389 (defense in depth, not a substitute for the above).
• Event ID 4625 monitored with an alert on spikes.
• RD Gateway with MFA in front of RDP, or RDP disabled entirely.

No single setting stops brute force; the combination does. Lockout blunts guessing, NLA filters scanners, the firewall scopes who can even reach the port, and monitoring tells you when someone is trying anyway. Applied together, these controls turn RDP from the most attacked service on the box into a non-event. If you are evaluating hosts while you harden, review the current Windows VPS plans on our homepage to match the plan to the workload — and to the defense you want to run on top of it.