Remote Desktop is the tool every Windows admin reaches for, and it’s also one of the most attacked services on the internet. A server with port 3389 open to the world starts getting login attempts within minutes, and RDP exposed this way has been a well-documented foothold for ransomware crews. The protocol isn’t the weak point — the way it’s deployed usually is.
Securing RDP isn’t one setting. It’s a short stack of controls, each of which closes a different door: prove the user before a session starts, encrypt and validate the connection, limit who can connect and from where, and keep the service off the open internet entirely. None of them is hard. Skipping any of them is where servers get owned.
This guide works through that stack in order of impact, with the settings and commands for each.
Don’t expose RDP to the internet
Start here because it’s the control that prevents the most damage. Raw RDP on a public IP — even on a changed port — is a target. The fix is to make sure the only way to reach RDP is through something that authenticates first.
Two standard approaches:
- VPN. Users connect to the VPN, then RDP to the server over the internal network. Port 3389 is never exposed publicly. Simple and effective for staff who already use a VPN.
- RD Gateway. The Remote Desktop Gateway role tunnels RDP inside HTTPS (443) and authenticates users at the edge. It’s the right choice when you need to give controlled remote access without a full VPN, and it gives you a single audited entry point.
Microsoft’s own guidance is explicit that Remote Desktop should only be enabled on trusted networks, because turning it on opens a port that makes the machine reachable. Plan the access path before you flip the switch.
Enforce Network Level Authentication
Network Level Authentication (NLA) makes the client prove who they are before the server builds a full session. Without it, the server allocates a session to anyone who connects and presents a login screen — burning resources and giving an attacker something to interact with. With NLA, an unauthenticated connection never gets that far.
NLA is on by default on modern Windows Server, but confirm it. In System Properties > Remote, the option reads Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended) — that box should be ticked.
To enforce it across many servers, use Group Policy:
Computer Configuration > Policies > Administrative Templates > Windows Components
> Remote Desktop Services > Remote Desktop Session Host > Security
> Require user authentication for remote connections by using Network Level Authentication = EnabledYou can also set it with PowerShell on a single host:
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" `
-Name "UserAuthentication" -Value 1A value of 1 requires NLA; 0 turns it off. Leave it at 1.
Use TLS and a real certificate
By default, RDP on Windows Server uses a self-signed certificate. The connection is encrypted, but the client can’t verify it’s talking to the right server, so users get a certificate warning and learn to click through it — which trains them to ignore exactly the warning that would catch a man-in-the-middle.
Two things to set:
- Force the TLS security layer so the server is authenticated, rather than falling back to the older RDP Security Layer.
- Bind a trusted certificate issued by your internal CA (for internal servers) or a public CA (for an internet-facing RD Gateway).
The security layer is a Group Policy setting in the same Security node:
... Remote Desktop Session Host > Security
> Require use of specific security layer for remote (RDP) connections = SSL (TLS 1.0)Issue a certificate with the server’s FQDN from your CA, install it in the computer’s Personal store, and bind it to RDP. The Remote Desktop Services certificate documentation covers binding for the full RDS roles (Web Access, Gateway, Connection Broker); for a standalone session host you can set the thumbprint directly:
$cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -like "*server01.corp.local*" }
$tsSettings = Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace "root\cimv2\TerminalServices" -Filter "TerminalName='RDP-tcp'"
Set-WmiInstance -Path $tsSettings.__PATH -Argument @{ SSLCertificateSHA1Hash = $cert.Thumbprint }After binding, clients validate the server’s identity and the warning disappears — so a real warning later actually means something.
Restrict who can connect, and from where
Encryption and NLA protect the connection. Now limit who’s allowed to use it.
Membership. Only administrators and members of the local Remote Desktop Users group can sign in over RDP. Keep that group lean — add the specific people or a dedicated group, not “Domain Users.” Audit it periodically.
# See who can currently RDP in
Get-LocalGroupMember -Group "Remote Desktop Users"User right. The Allow log on through Remote Desktop Services right backs the group up. Set it through Group Policy so it’s consistent, and pair it with Deny log on through Remote Desktop Services for sensitive accounts that should never RDP anywhere — domain admins are a common candidate, to limit credential exposure on member servers.
Computer Configuration > Policies > Windows Settings > Security Settings
> Local Policies > User Rights Assignment
> Allow log on through Remote Desktop Services
> Deny log on through Remote Desktop ServicesSource IPs. Scope the firewall rule so RDP only answers connections from the management subnet or jump host, not from everywhere:
Set-NetFirewallRule -DisplayGroup "Remote Desktop" `
-RemoteAddress 10.10.50.0/24 -Enabled TrueThat single change stops the entire internet — and most of your internal network — from even reaching the RDP listener.
RDP hardening controls and what each one stops
| VPN / RD Gateway | Removes direct internet exposure — the biggest single risk |
|---|---|
| Network Level Authentication | Blocks unauthenticated connections before a session is built |
| TLS + trusted certificate | Authenticates the server and prevents man-in-the-middle |
| Restricted Remote Desktop Users | Limits which accounts can sign in at all |
| Firewall source scope | Limits which networks can reach the RDP listener |
| Account lockout policy | Slows password-guessing against the accounts that can connect |
Back it with lockout, patching, and logging
A few supporting controls round out the picture.
A sensible account lockout policy slows brute-force attempts against the accounts that can RDP in — set it the same way you’d set any domain lockout policy. Our guide on configuring account lockout policy with Group Policy walks through the threshold and duration choices.
Patching matters because RDP has been the subject of serious remote vulnerabilities. Keep the OS current so a known exploit can’t do the work an attacker would otherwise have to brute-force.
Logging gives you a trail. Watch the Security log for logon events (4624/4625) and the Remote Desktop Services operational logs for connection activity. If RDP is internet-adjacent through a gateway, review those logs regularly rather than only after an incident.
RDP hardening checklist
- RDP is reachable only through a VPN or RD Gateway, never raw 3389 on a public IP
- Network Level Authentication is required (UserAuthentication = 1)
- TLS security layer is enforced with a CA-issued certificate bound to RDP
- Remote Desktop Users contains only the accounts that genuinely need access
- Deny log on through RDS is set for accounts that should never RDP (e.g. domain admins on member servers)
- Firewall scopes RDP to the management subnet or jump host
- Account lockout policy is in place
- The server is patched and RDP logon events are monitored
Wrapping up
Securing RDP is about layering a handful of controls, not finding one magic switch. Keep it off the open internet behind a VPN or RD Gateway, require Network Level Authentication, enforce TLS with a real certificate, tighten who can connect and from where, and back it with lockout, patching, and logging. Each layer closes a door an attacker would otherwise walk through.
If you only do two things, do these: get RDP off direct internet exposure, and confirm NLA is enforced. Those two remove the bulk of the risk that makes RDP such a popular target in the first place.
