RDP is the most attacked service on a Windows VPS. Expose port 3389 to the internet and automated scanners start guessing passwords within minutes; leave it wide open and a dictionary attack will eventually find a weak credential. The genuinely hard part of securing RDP is not knowing which settings to apply — it is applying them in an order that does not end with you locked out of your own server. This guide sequences each hardening step, flags the lockout trap that comes with it, and shows how to keep an escape route open the whole time.<\/p>\n\n\n\n
Before touching a single setting, confirm that your provider’s browser console (VNC or KVM) actually works. That console bypasses RDP entirely and is your safety net if you misconfigure the firewall, break authentication, or trigger a lockout. Also verify you have a second local account with administrative rights, or a second administrator account, so a mistake on one credential does not strand you. Five minutes of setup here prevents hours of provider-ticket pain later.<\/p>\n\n\n\n
Strong passwords are the first line of defense. Enforce minimum length and complexity, and enable account lockout so repeated failures freeze the account instead of allowing unlimited guesses:<\/p>\n\n\n\n
# 5 failed attempts, 30-minute lock, 30-minute window\nnet accounts \/lockoutthreshold:5 \/lockoutduration:30 \/lockoutwindow:30<\/code><\/pre>\n\n\n\nThe trap:<\/strong> lockout is a denial-of-service vector. An attacker who knows your usernames can deliberately trigger five failures on your admin account and lock you out remotely. Mitigate this three ways: keep the threshold at 5–10 (not 3), keep the lockout duration short (15–30 minutes), and always have the provider console as a fallback that bypasses RDP entirely. Set the Security log to overwrite events as needed so you keep the Event ID 4625 records that tell you who is knocking.<\/p>\n\n\n\nTurn on Network Level Authentication<\/h2>\n\n\n\n
Network Level Authentication requires the client to authenticate before a full RDP session is created. It blocks the resource-exhaustion attacks that open hundreds of half-established sessions and stops some credential-harvesting tricks. On Windows Server 2022 and 2025 it is on by default, but verify:<\/p>\n\n\n\n
# 1 = NLA required\nSet-ItemProperty -Path \"HKLM:\\SYSTEM\\CurrentControlSet\\Control\\Terminal Server\\WinStations\\RDP-Tcp\" -Name \"UserAuthentication\" -Value 1<\/code><\/pre>\n\n\n\nNLA is safe to enable and rarely causes lockouts. The one compatibility note: very old RDP clients (pre-Windows 7 era) cannot connect with NLA enforced, which is rarely a concern in 2026.<\/p>\n\n\n\n
Firewall RDP to trusted sources<\/h2>\n\n\n\n
The single most effective control is restricting who can reach port 3389 at all. In Windows Defender Firewall, scope the built-in Remote Desktop inbound rule to your office or home IP ranges, or create a new rule with -RemoteAddress<\/code> set to your CIDR block. If your provider offers an external firewall, apply the same restriction there — it stops the scan traffic before it ever reaches the server, which also quietens the Security log. Keep the provider console handy when you change firewall rules: a bad rule is the classic way to lock yourself out of RDP.<\/p>\n\n\n\nCreate a dedicated admin account<\/h2>\n\n\n\n
Create a named account (for example svc-admin<\/code>), add it to the Administrators and Remote Desktop Users groups, log in with it once from a fresh session, and only then disable the built-in Administrator account. The trap:<\/strong> disabling or renaming Administrator before the new account is proven is the fastest route to a locked box. Renaming helps against scripts that target the well-known name, but account lockout and a strong password do the real work.<\/p>\n\n\n\nTest before you log out<\/h2>\n\n\n\n
The golden rule: never close your only session before verifying the next one works. Keep two RDP sessions open, change one setting at a time, and reconnect from a second device or session after each change. If a change breaks access, the still-open session and the provider console are your recovery paths. This discipline is what separates a smooth hardening pass from a support ticket titled “I locked myself out.”<\/p>\n\n\n\n
What to do if you still get locked out<\/h2>\n\n\n\n
Open the provider’s browser console, log in locally, and reverse the last change: re-enable the account, reset the password, or re-allow the firewall rule. Then review the Security log for 4625 (failed logon) and 4740 (account locked out) events to confirm whether the lockout was an attack or your own change. If you disabled the only admin account, most provider consoles include a password reset that re-enables it. After recovery, continue hardening from the console instead of over RDP.<\/p>\n\n\n\n
Bottom line<\/h2>\n\n\n\n
Securing RDP is a sequence, not a checklist of independent toggles: escape route first, then NLA and lockout, then firewall scoping, then accounts, testing every step. Follow that order and the “without locking yourself out” part takes care of itself. If your current plan does not give you a reliable console or enough room for a second admin account, it may be time to switch — compare providers in our Windows VPS comparison table<\/a> and see the plans on our comparison page<\/a>.<\/p>\n\n\n\nFor a fresh start with full console access, InterServer’s Windows VPS plans<\/a> (promo code TRYINTERSERVER<\/strong>, penny first month) and Vultr’s Windows instances<\/a> both include out-of-band console access for exactly this kind of recovery.<\/p>\n","protected":false},"excerpt":{"rendered":"