How to Secure Remote Desktop on a Windows VPS

The short answer

Remote Desktop (RDP) is how most people work on a Windows VPS, and it is also the first door attackers try. Automated scanners sweep the internet for Remote Desktop on TCP port 3389 and throw common usernames and leaked passwords at whatever answers. No single setting fixes that. What works is a few layers: limit who can reach RDP at all, make every sign in hard to guess, lock out repeated failures, keep Windows patched, and read the logs.

This guide walks through those layers on a Windows Server VPS in the order we recommend doing them. It builds on our Windows VPS for small business guide, which covers when Windows is the right call and how to size it.

Before you change anything: keep a second way in

Firewall changes made over a Remote Desktop session can cut off that same session. Before you tighten anything, confirm you have another way to reach the server that does not depend on RDP, such as a console from your hosting provider, and note your current settings so you can put them back. If you are not sure which console option your plan includes, ask us before you start.

Step 1: Limit who can reach Remote Desktop

The biggest single improvement is making RDP unreachable for everyone except the people who need it.

Best: put RDP behind a VPN. Your team connects to the VPN first, and Remote Desktop only accepts connections from VPN addresses. Nothing on the open internet ever sees the RDP port.
Good: allow only known IP addresses. If your office has a static IP, scope the built in Windows Defender Firewall rules for Remote Desktop to that address and nothing else.
For larger teams: Remote Desktop Gateway. RD Gateway carries Remote Desktop inside HTTPS on port 443 and gives you one place to control who connects.

To scope the built in rules with PowerShell, run it as Administrator and replace the example address with your own (you can list several, separated by commas):

Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 203.0.113.10
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter

The second command shows which remote addresses each rule now accepts. You can make the same change by hand in Windows Defender Firewall with Advanced Security: open each Remote Desktop inbound rule, go to the Scope tab, and add your addresses under Remote IP address.

If your team works from home connections whose IP changes, a VPN is a better fit than chasing addresses in firewall rules.

What about changing the port? Moving RDP off 3389 cuts down noise from the laziest scanners, but anyone who scans every port will still find it. Treat a new port as tidying, not as protection.

Step 2: Keep Network Level Authentication on

Network Level Authentication (NLA) makes a user prove who they are before Windows builds a full remote session. That keeps unauthenticated connections from reaching the sign in screen and saves the server work on junk connections.

To check it, open System Properties (run sysdm.cpl), go to the Remote tab, and make sure Allow connections only from computers running Remote Desktop with Network Level Authentication is selected. Current Remote Desktop clients on Windows, macOS, iOS, and Android support it, so there is rarely a reason to turn it off.

Step 3: One person, one account, least access

Give every person their own login. A shared Administrator password cannot be revoked from one person without changing it for everyone, and the logs cannot tell you who did what.
Retire the default Administrator name. Scanners try the name Administrator first. Once your own named admin account is confirmed working, disable the built in Administrator account or give it a long random password that nobody uses day to day.
Not everyone needs to be an admin. People who only run a business app can be added to the local Remote Desktop Users group, which lets them sign in over RDP without full control of the server.
Use long, unique passwords stored in a password manager. Reused passwords are what credential stuffing attacks feed on.
Remove access the day someone leaves. Disable the account first, then clean up their files once nothing depends on them.

Step 4: Lock out repeated failures

Account lockout turns password guessing from a numbers game into a dead end. Open Local Security Policy (run secpol.msc), then go to Account Policies and Account Lockout Policy. There are three settings:

Account lockout threshold: how many failed attempts before the account locks.
Account lockout duration: how long it stays locked.
Reset account lockout counter after: how long before failed attempts are forgotten.

A common starting point is 10 failed attempts with a 15 minute lockout and a 15 minute reset. That is generous to a person who mistypes and painful for a bot. Lockout is also a reason to have individual accounts and a second way in: if someone hammers one account, everyone else can still work.

Step 5: Add a second factor where you can

A standalone Windows Server does not ask for a second factor on Remote Desktop by default. The usual ways to add one are a VPN that requires multi factor sign in, Remote Desktop Gateway paired with a multi factor service, or a multi factor agent installed on the server for Windows sign in. Pick the one that matches how your team already signs in to other tools, so it actually gets used.

Step 6: Patch on a schedule

Some of the most serious Windows vulnerabilities of recent years have been in Remote Desktop itself, BlueKeep in 2019 being the best known. A locked down configuration helps, but it does not replace updates. Set a maintenance window, let Windows Update install and restart inside it, and sign in afterward to confirm your business app still starts. Our Windows VPS guide covers patch windows in more detail.

Step 7: Read the sign in logs

Windows records every sign in attempt in Event Viewer under Windows Logs and then Security. Three events matter most:

4625: a failed sign in.
4624: a successful sign in. Remote Desktop sessions show logon type 10.
4740: an account was locked out.

To see the most recent failures from PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20

A steady stream of failures from addresses you do not recognize means Remote Desktop is still reachable from the internet. Go back to Step 1. A successful sign in at an hour nobody works deserves a closer look the same day.

Quick checklist

A second way into the server that does not depend on RDP
Remote Desktop reachable only through a VPN, known IP addresses, or RD Gateway
Network Level Authentication on
Named accounts for every person, no shared Administrator login
Non admins in the Remote Desktop Users group instead of Administrators
Account lockout policy set
A second factor wherever your setup supports one
A regular patch window with a check after each reboot
A weekly look at failed sign ins

How GlassHosting fits

Windows on KVM: GlassVPS KVM runs full virtual machines, with Windows among the operating system choices. Our KVM vs LXC guide explains why Windows needs KVM.
Managed infrastructure: if you would rather not own Remote Desktop security, patching, backups, and monitoring yourself, see our services overview and how our MSP model works.

Running a Windows server with Remote Desktop open to the world and not sure where to start? Tell us what you run or email sales@glasshosting.com, and we will help you lock it down without locking yourself out.