RDP Hardening Guide: How to Secure Remote Desktop Protocol with NLA, Firewall Rules, and Gateway Without Locking Out Your Users
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
If port 3389 is reachable from the internet without a VPN or gateway in front of it, the host is being scanned and brute-forced right now. The fix is not complicated: NLA enforcement, an account lockout policy, firewall rules restricting 3389 to management networks only, and an RDP Gateway for external access. This guide covers each control in order of impact, with exact Group Policy paths and verification steps.
Enforce Network Level Authentication (NLA)
NLA forces clients to authenticate before a full remote desktop session is established. Without NLA, the Windows authentication screen is served unauthenticated -- every CVE that reaches the pre-authentication phase of the RDP handshake (including BlueKeep) requires NLA to be disabled.
Group Policy path:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
Settings to configure:
- Require use of specific security layer for remote (RDP) connections: Set to
SSL (TLS 1.0)or higher. Do not leave onNegotiate. - Require user authentication for remote connections by using Network Level Authentication: Set to
Enabled. - Set client connection encryption level: Set to
High Level.
Verify via registry:
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' |
Select-Object SecurityLayer, UserAuthentication, MinEncryptionLevel
# SecurityLayer = 2 (SSL/TLS)
# UserAuthentication = 1 (NLA required)
# MinEncryptionLevel = 3 (High)
Client-side requirement: NLA requires CredSSP support. All Windows Vista and later clients support it. Older clients (XP, Server 2003) cannot connect to NLA-required hosts -- if you have these, address the legacy OS problem separately.
Firewall Rules: Restrict TCP 3389 to Management Networks
NLA should not be the only control. TCP 3389 should not be reachable from the internet at all, or from general user networks. The firewall rule set:
Windows Firewall GPO (inbound rules):
Rule name: Block RDP from internet
Protocol: TCP
Port: 3389
Scope (Remote): 0.0.0.0/0 (any)
Action: Block
Rule name: Allow RDP from management network
Protocol: TCP
Port: 3389
Scope (Remote): 10.0.0.0/24 (your management VLAN CIDR)
Action: Allow
Group Policy path:
Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules
Perimeter firewall/NSG: Create an equivalent deny-all / allow-management-only rule at the network boundary. Windows Firewall GPO alone is not sufficient -- a domain admin can disable it. Defense in depth means the perimeter rule cannot be overridden from the endpoint.
For Azure VMs:
# Deny RDP from internet at NSG level
az network nsg rule create \
--resource-group rg-name \
--nsg-name vm-nsg \
--name DenyRDPInternet \
--priority 100 \
--direction Inbound \
--access Deny \
--protocol Tcp \
--destination-port-ranges 3389 \
--source-address-prefixes Internet
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Deploy an RDP Gateway for External Access
Instead of punching TCP 3389 through the firewall for external admins, deploy Remote Desktop Gateway. RDP Gateway tunnels RDP over HTTPS (TCP 443) and enforces authentication at the gateway before proxying connections to internal hosts.
Minimum viable RDP Gateway setup:
- Install the Remote Desktop Gateway role on a Windows Server in the DMZ:
Install-WindowsFeature RDS-Gateway -IncludeManagementTools
-
Configure a valid TLS certificate from your internal CA or a public CA (not a self-signed cert -- clients will get certificate warnings and users will click through them).
-
Create Connection Authorization Policies (CAP) and Resource Authorization Policies (RAP):
- CAP: defines who can connect through the gateway (AD group membership, MFA requirement if using NPS extension)
- RAP: defines which internal hosts they can reach
- For MFA on RDP Gateway connections, add the NPS extension for Azure MFA:
- Install the NPS extension on the Gateway server
- Every connection through the gateway triggers an MFA prompt before the RDP session is established
Client connection string format:
mstsc /v:rdp-gateway.yourdomain.com
# Or configure the gateway in mstsc Advanced > Settings > Use these RD Gateway server settings
For cloud-only or hybrid environments: consider Azure Virtual Desktop or Bastion instead of a self-managed gateway, depending on scale.
Replace Self-Signed RDP Certificates
By default, Windows generates a self-signed certificate for RDP TLS. This triggers a certificate warning every time users connect, and users click through it -- training them to ignore certificate errors. It also means you have no way to verify you are connecting to the right host.
Replace with your internal CA:
# Create a certificate template in your CA for RDP
# Template EKU: Server Authentication (1.3.6.1.5.5.7.3.1)
# Subject: CN=<FQDN of server>
# Via Group Policy, configure auto-enrollment:
# Computer Configuration > Windows Settings > Security Settings >
# Public Key Policies > Certificate Services Client - Auto-Enrollment
# Set: Enabled, renew expired certs, update certs that use cert templates
# Force RDP to use the auto-enrolled cert:
# Computer Configuration > Administrative Templates >
# Windows Components > Remote Desktop Services > RDS Session Host > Security
# "Server authentication certificate template": <your template name>
Verify the cert in use:
# Check the thumbprint configured for RDP
(Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp').SSLCertificateSHA1Hash
# Compare with your CA-issued cert thumbprint
Account Lockout, Session Timeouts, and Idle Disconnect
Account lockout prevents brute force. Session timeouts prevent abandoned sessions from persisting as live attack surfaces.
Account lockout (Fine-Grained Password Policy or Default Domain Policy):
- Account lockout threshold: 5 invalid attempts
- Observation window: 30 minutes
- Account lockout duration: 30 minutes (or admin reset -- avoid auto-unlock shorter than 15 minutes)
RDP session timeouts (Group Policy):
Path: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits
- Set time limit for active but idle Remote Desktop Services sessions: 15 minutes
- Set time limit for disconnected sessions: 2 hours (adjust based on workflow)
- End session when time limits are reached: Enabled
Audit logon events to detect brute force:
Event ID 4625 (failed logon) with Logon Type 10 (RemoteInteractive)
# Alert if count > 5 from same source IP in 5 minutes
Restrict who can RDP (least privilege):
# Remove Users group from Remote Desktop Users if not needed
# Only specific AD groups should be in the Remote Desktop Users local group
# GPO: Restricted Groups or Local Users and Groups preference
The bottom line
RDP hardening in priority order: enforce NLA first (closes pre-auth exploits and provides TLS), restrict TCP 3389 at both the Windows Firewall and perimeter levels (eliminates internet exposure), deploy RDP Gateway for any external access with MFA (provides an audit point and MFA enforcement), replace self-signed certs (eliminates user-trained certificate warning bypass), and set session timeouts with an account lockout policy. All five controls together reduce RDP's attack surface from a globally-accessible credential-stuffing target to a network-restricted, authenticated, and audited administrative channel.
Frequently asked questions
Is RDP safe to expose to the internet if I use NLA?
No. NLA eliminates the pre-authentication RCE class of vulnerabilities and prevents unauthenticated fingerprinting, but it does not stop credential brute force or password spray attacks. Internet-exposed RDP with NLA enabled is still scanned, still attacked with credential lists, and still used as an initial access vector by ransomware operators daily. The correct posture is: NLA enforced, AND TCP 3389 not reachable from the internet without a VPN, RDP Gateway, or Bastion service in front of it.
What is the difference between NLA and SSL security layer in RDP?
SSL security layer (also called TLS in newer Group Policy labels) encrypts the RDP transport channel with TLS but still presents the Windows logon screen unauthenticated. NLA goes further: the client must authenticate via CredSSP before a full session is established, meaning the Windows logon screen is never reached until credentials are verified. For maximum security, set both: security layer to SSL/TLS for encryption, and NLA for pre-authentication. Setting only TLS without NLA still leaves you exposed to BlueKeep-class vulnerabilities.
Does RDP Gateway replace a VPN?
For RDP access specifically, yes. RDP Gateway tunnels connections over HTTPS (TCP 443) and enforces authentication at the gateway before proxying to internal hosts. Users only need TCP 443 outbound, which is almost always permitted. However, RDP Gateway only covers Remote Desktop connections -- it does not provide general network access to other internal services the way a VPN does. For organizations that need only RDP access for remote administration, Gateway alone is sufficient. For broader remote access to internal resources, Gateway and VPN serve different purposes.
Should I change the RDP port from 3389 to something else?
This is security through obscurity and is not a recommended control. Changing the port reduces automated scanner noise but provides no real protection because port scanners discover non-standard RDP ports within minutes. The time investment is better spent on NLA enforcement, firewall rules, and account lockout policies. If you do change the port as an additional layer, document it carefully -- it frequently causes self-inflicted outages during incidents when responders cannot reach systems over RDP.
How do I detect RDP brute force in my event logs?
Event ID 4625 (failed account logon) with Logon Type 10 (RemoteInteractive) is the primary indicator. Alert on five or more 4625 events with Logon Type 10 from the same source IP within a five-minute window. Also monitor Event ID 4624 with Logon Type 10 for successful logins from unexpected source IPs or at unusual hours. Event ID 1149 in the Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational log records RDP authentication attempts and is useful for correlating source IPs before Windows auth events are generated.
What is RDP Gateway and when should I use it instead of VPN for remote access?
RDP Gateway (also called Remote Desktop Gateway or RD Gateway) is a Windows Server role that proxies RDP connections over HTTPS (port 443). Remote users connect to the gateway via HTTPS, and the gateway tunnels the RDP session to the target server on the internal network. The advantages over direct VPN: the target server's RDP port is never exposed to the internet (only the gateway's HTTPS is exposed), the gateway enforces authentication before establishing the RDP tunnel (providing an additional authentication chokepoint), and gateway policies can restrict which users can connect to which internal servers. RD Gateway is appropriate when: you need clientless or lightweight remote access without requiring a full VPN client, you want to enforce connection policies at the RDP layer rather than the network layer, or you need to provide external support vendors access to specific servers without full network access. For organizations already using a mature zero trust access solution (Zscaler Private Access, Cloudflare Access for SSH/RDP), the gateway functionality is typically provided by the ZTA platform rather than a dedicated RD Gateway.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.