I use Remote Desktop from anywhere, but only after making these security changes

When I’m using my Microsoft Windows Servers remotely, I still use the built-in Remote Desktop Protocol (RDP) that ships with Windows. That’s because it’s fast, I can pass through my mic and sound, and it’s as close to a native experience as I can get with Windows.

The big problem with using RDP alone is that, unlike SSH or RDP with a VPN, it’s not really considered a very secure solution for public-facing servers. I wanted to keep using RDP but make it safe enough to leave my servers running without losing sleep after getting attacked.

That meant changing a few things, like adding MFA, moving RDP off the default port, and tightening some accounts.

I still use RDP for Windows Server, but I don’t trust it

Remote Desktop is convenient but needs proper security

RDP gets a bad rap, especially in cybersecurity circles. But I think this classic Windows app is still one of the best ways to control Windows boxes remotely. It’s native, fast, and already supported without having to pay a subscription or install another remote access client. It also handles everything I need, like audio passthrough, microphone redirection, clipboard and drive sharing, and it can use all of my screens. Now, these are all supported by other tools, but they feel clunky and require a bunch of extra steps.

So, the problem isn’t RDP itself, but treating it like a simple on/off switch definitely is. The standard RDP port 3389 is one of the most widely recognized remote service ports and is constantly scanned. If all I do is enable Remote Desktop and rely on a password, I would essentially be putting a Windows Login screen on the internet.

For this setup, I wanted to see how far I could harden direct RDP access for a small server at home without losing any of the convenience.

First, I removed the obvious targets

I removed the accounts and settings attackers expect to find

Before touching MFA, I needed to disable the all-powerful default Administrator account. That meant creating three new accounts:

1. A normal account for RDP login and daily access.
2. A new administrator account for maintenance.
3. A break-glass account that (hopefully) I’ll never need to touch.

The daily RDP user doesn’t need administrator rights. It only needs permission to sign in via Remote Desktop. I added that user to the Remote Desktop Users group using lusrmgr.msc MMC (Win + R -> lusrmgr.msc). I then created the second user and, again, using lusrmgr.msc, added that user to the Administrators group.

Because members of the Administrators group get RDP access by default, I used local group policy to deny remote access login to that account completely.

The local group policy setting to do so is found here:

Win + R -> secpol.msc -> Security Settings -> Local Policies -> User Rights Assignment -> Deny log on through Remote Desktop Services -> Add the new administrator user.

After that, I forced a group policy update with the command in an elevated command prompt:

gpupdate /force.

Before I disabled the local Administrator and guest accounts, I checked that the new administrator account worked for UAC elevation. Finally, I made sure Network Level Authentication was turned on in Settings > Remote Desktop > Advanced Settings.

I added MFA to make RDP feel way less exposed

Adding an OTP for authentication is the next best step

Password-only authentication is one of the biggest problems I have with RDP. Without an additional layer of authentication, the server is just a Windows password prompt with a publicly routable address. It’s really not ideal.

Adding One-Time Password (OTP) authentication is one of the best Multi-Factor Authentication (MFA) methods for securing RDP logins without over-engineering it. I used the free and open-source multiOTP to hook into the local Windows logon and RDP as a credential provider. That way, even if my username and password were used to log in, without the code from an authenticator app, a malicious user couldn’t get any further.

I installed the multiOTP Credential Provider from their GitHub, chose the local-only setup, and configured it to require OTP for RDP only. I enrolled my non-administrator user from earlier by opening an elevated command prompt in C:\Program Files\multiOTP and created a Time-based One-Time Password (TOTP) token:

cd C:\Program Files\multiOTPmultiotp -fastcreatenopin rdp-usermultiotp -qrcode rdp-user rdp-user.png

I found using fastcreatenopin was the most straightforward way to provide OTP MFA for RDP login because it doesn’t require a prefix PIN on the username. It meant I could still use saved Windows credentials on the machine initiating the connection. The last command above created a QR code that I put into Google Authenticator, though any 2FA app can be used for this step.

After enrolling, it was simply a matter of trying an RDP login, which worked perfectly from the first attempt. Now, I have a Windows Server with an extra layer of security, and hopefully a better night’s sleep.

I changed the port to something less interesting

It cuts down the log noise but not the risk

Because everyone out there who knows how to use Nmap also knows port 3389 is the default RDP port, leaving your Remote Desktop running through this port is going to create a lot of noise from port scanners and leave your server more exposed. So, I changed the RDP port from 3389 to a service port that’s a little less popular: 49291.

The number was random, but I made sure it was between 40000 and 55000, just because these are ports that aren’t regularly scanned by attackers looking for open remote access ports. This doesn’t mean that no one will ever find my Remote Desktop service, but it does create a lot less noise for my network monitoring systems.

Changing the port just meant enabling script execution in PowerShell and running this script in an elevated PowerShell ISE session:

$newPort = 49291 Set-ItemProperty -Path “HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” -Name PortNumber -Value $newPort New-NetFirewallRule -DisplayName “RDP Custom Port” -Direction Inbound -Protocol TCP -LocalPort $newPort -Action Allow Restart-Service TermService -Force

After running the script, I initiated the Remote Desktop session from my PC using:

hostname/IP:49291

After I was sure it was working correctly, I disabled the old 3389 firewall rule in Windows Firewall.

The last things I changed will help you recover your server

Backups, snapshots, and break-glass accounts

My server is otherwise not accessible from the internet, so I created a break-glass user in case anything happened with the primary account. This is one of a few steps I did to make sure the server was always recoverable (but still secure) in the event of something breaking RDP access.

Since a bad MFA setup is a one-way road to locking yourself out, I always made sure I still had access in case anything broke via the break-glass account. As I was using a Virtual Machine in ESXi, I was also able to take a snapshot of the server before making any changes. If the server was hosted as a Virtual Private Server (VPS), then I could have also used the built-in hypervisor’s console, KVM, or VNC access provided by the platform to gain access via the Administrator account.

My rule when working with any remote server is to never close a working session until I’m sure the new one works. Beyond this, I always make sure to keep the server updated and monitor for any failed login attempts in the Event Viewer or by using this PowerShell script I created to display anything recent:

Get-WinEvent -FilterHashtable @{LogName = “Security” Id = 4625 StartTime = (Get-Date).AddDays(-1)} | Select-Object TimeCreated, Message | Format-List

Finally, I adjusted the lockout thresholds for account lockout using secpol.msc -> Account Policies -> Account Lockout Policy. Here, I set the number of invalid login attempts to 3, and increased the lockout time to 60 minutes.

Remote Desktop still has a place on my Windows server

MFA, account limits, and recovery options reduced the risk

I still use Remote Desktop because it’s fast and familiar, but I also believe the default security Windows comes with for RDP is completely inadequate. MFA made the biggest difference of all, but changing the port only kept the port scanners at bay for a few days before the logs filled up again with failed login attempts on the new port.

The separate accounts and lockout rules gave me some confidence for my small home server. However, I would still place any important and publicly facing Windows Server behind a VPN or allow-list my IP address to create a more secure setup.