Expose a Windows Server’s RDP port to the internet and you will see brute-force attempts within minutes \u2014 typically 5,000 to 20,000 failed logins per day on a plain 3389 endpoint. The good news: three settings neutralize the overwhelming majority of those attacks, and all three are built into Windows Server with no third-party software. This article covers Network Level Authentication (NLA), RDP server certificates, and account lockout policies \u2014 what each one actually stops, and the exact settings to apply.<\/p>\n\n
NLA forces the client to authenticate before<\/em> a full remote desktop session is created. With NLA off, an attacker completes the RDP handshake and reaches the Windows logon screen, which historically enabled the “BlueKeep”-class vulnerabilities and lets attackers hammer the credential prompt with far less noise. With NLA on, the connection is rejected unless the client presents valid credentials up front.<\/p>\n\n NLA is enabled by default on Windows Server 2022\/2025, but templates and imaging pipelines occasionally disable it. Verify it two ways:<\/p>\n\n If your RDP client is older than Windows 8 \/ macOS 10.12, NLA will refuse it \u2014 that is a feature, not a bug; those clients are exactly what you want to keep out.<\/p>\n\n By default the RDP service uses a self-signed certificate, which means the client cannot verify it is talking to your server and not a machine-in-the-middle. Certificate pinning fixes that: install a certificate trusted by your clients (from an internal AD CS, or a public CA) and force the RDP service to use it.<\/p>\n\n For fleets, do this with Group Policy: Computer Configuration \u2192 Policies \u2192 Administrative Templates \u2192 Windows Components \u2192 Remote Desktop Services \u2192 Remote Desktop Session Host \u2192 Security \u2192 “Server authentication certificate template” \u2014 set it to a template issued by your CA. Renew before expiry; an expired pinned cert silently breaks RDP for everyone.<\/p>\n\n Lockout policies stop password guessing at the source. Apply these via Group Policy \u2192 Computer Configuration \u2192 Windows Settings \u2192 Security Settings \u2192 Account Policies \u2192 Account Lockout Policy:<\/p>\n\n Two more cheap wins: (1) change the RDP port from 3389 \u2014 cosmetic against port scans but it kills most automated noise; (2) restrict source IPs in the firewall\/security group to your office or VPN range, which is the single most effective control of all. Watch for lockout denial-of-service: an attacker who knows your admin account can lock it repeatedly, so keep a second break-glass account outside the policy and monitor Event ID 4740 (account locked out).<\/p>\n\n One more layer worth naming: routing RDP through a VPN or RD Gateway instead of exposing 3389 at all. An RD Gateway terminates TLS on 443, hides the session host, and lets you enforce MFA at the gateway \u2014 the settings above still apply, but the attack surface shrinks from “the whole internet” to “your gateway’s TLS endpoint.” For single servers, a WireGuard or SSTP VPN with RDP bound to the VPN interface only is the strongest configuration you can build with built-in tools, and it makes the lockout policy almost redundant in practice.<\/p>\n\n NLA removes the pre-auth attack surface, certificate pinning defeats interception, and lockout policy makes guessing impractical \u2014 together they convert a screaming-open port into a boring one. Apply all three before the server ever gets a public IP, and you can skip most of the “RDP honeypot” anxiety. When you are choosing where to run that server, our Windows VPS comparison table<\/a> flags providers that include firewall and DDoS protection in the base plan, and the feature list on our Windows VPS page<\/a> shows which plans let you set security groups per IP \u2014 worth having when 3389 has to face the internet.<\/p>","protected":false},"excerpt":{"rendered":"HKLM\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp<\/code> \u2014 UserAuthentication<\/code> should be 1<\/code> and SecurityLayer<\/code> should be 2<\/code> (TLS).<\/li><\/ul>\n\n2. RDP server certificates<\/h2>\n\n
$cert = Get-ChildItem Cert:\\LocalMachine\\My | Where-Object {$_.Subject -like \"*your-server-dns*\"}; (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\\cimv2\\TerminalServices -Filter \"TerminalName='RDP-tcp'\").SetSSLCertificate($cert.Thumbprint)<\/code><\/li>qwinsta<\/code> (no effect) and on the client: the certificate name should match the server and show as trusted, with no “identity cannot be verified” warning.<\/li><\/ol>\n\n3. Account lockout and access restriction<\/h2>\n\n
Setting<\/th> Recommended value<\/th> Why<\/th><\/tr><\/thead> Account lockout threshold<\/td> 5 failed attempts<\/td> Below 5, typos lock people out; above 10, brute force gets too many tries<\/td><\/tr> Account lockout duration<\/td> 15\u201330 minutes<\/td> Short enough to not disrupt work, long enough to stall distributed attacks<\/td><\/tr> Reset account lockout counter<\/td> 15 minutes<\/td> Prevents “slow drip” guessing over hours<\/td><\/tr> RDP access list<\/td> Only the “Remote Desktop Users” group<\/td> Administrators are not automatically excluded \u2014 remove them or gate via a separate group<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Monitoring and verification<\/h2>\n\n
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 | Select TimeCreated, @{n='User';e={$_.Properties[5].Value}}<\/code><\/li>Get-ItemProperty \"HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\" | Select UserAuthentication, SecurityLayer<\/code><\/li><\/ul>\n\nPutting it together<\/h2>\n\n