How to Harden RDP Without Disabling It
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.
RDP exposed to the internet on the default port 3389 is continuously scanned by automated tools operated by ransomware groups, cryptocurrency miners, and credential resellers. When a scanner finds open RDP, it attempts known username/password combinations from breach databases at machine speed.
Disabling RDP solves the problem only if nobody in your organization needs remote access: which is rarely true. The alternative is hardening RDP so that it remains accessible to authorized users while eliminating the exposure that automated scanners exploit.
Control 1: Enable Network Level Authentication (NLA)
Network Level Authentication requires the connecting client to provide valid credentials before a Remote Desktop session is established. Without NLA, an attacker can reach the Windows login screen: which is itself a vulnerability (it exposes the OS version, any accessibility features, and creates an attack surface for session-level exploits). With NLA, authentication must succeed at the network layer before any desktop is presented.
Enable via Group Policy:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require use of specific security layer for remote connections → Set to Negotiate or SSL
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication → Enabled
Enable via PowerShell:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'UserAuthentication' -Value 1
Enable via System Properties (GUI): System Properties > Remote tab > Select 'Allow connections only from computers running Remote Desktop with Network Level Authentication'
NLA is the single highest-impact RDP hardening step that maintains full functionality. Enable it on every machine before any other RDP hardening.
Control 2: Restrict RDP to Trusted Source IPs
If RDP is only used by IT staff from specific locations (office network, VPN subnet, specific jump host), restrict RDP access at the Windows Firewall to those source IP ranges. This eliminates all access from the mass-scanning infrastructure that ransomware groups operate from.
Windows Firewall rule via PowerShell:
# Remove existing permissive RDP rule
Remove-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)" -ErrorAction SilentlyContinue
# Create restricted RDP rule allowing only trusted sources
New-NetFirewallRule `
-DisplayName "RDP - Trusted Sources Only" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 3389 `
-RemoteAddress @("10.0.1.0/24", "192.168.100.50", "203.0.113.10") `
-Action Allow `
-Profile Any
Replace the RemoteAddress values with your actual trusted IP ranges: your VPN subnet, your office NAT IP, and any jump hosts or bastion servers.
If RDP must be internet-accessible: Place it behind a VPN or Remote Desktop Gateway rather than exposing port 3389 directly. An RD Gateway presents only HTTPS (port 443) to the internet and requires authentication before proxying the RDP connection: eliminating direct exposure of the RDP protocol to the internet.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Control 3: Change the Default Port
Automated scanners target port 3389 explicitly. Changing RDP to a non-standard port (commonly 3388, 33890, or any high port in the 49152-65535 range) eliminates traffic from automated tools that do not perform full port scans: which is most of the opportunistic scanning RDP faces.
Note: This is security through obscurity: it reduces noise but does not stop a determined attacker who performs full port scans. Combine it with the IP restriction in Control 2, not as a replacement.
Change via registry:
$port = 33890 # choose your non-standard port
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name 'PortNumber' -Value $port
# Update Windows Firewall to allow the new port
New-NetFirewallRule -DisplayName "RDP Custom Port" -Direction Inbound -Protocol TCP -LocalPort $port -Action Allow
# Remove the default 3389 rule
Remove-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"
After the registry change, restart the Remote Desktop Services service or reboot. Document the new port: authorized users will need to specify it when connecting (mstsc /v:server.example.com:33890).
Control 4: Account Lockout Policy for RDP Brute Force Prevention
Without an account lockout policy, an attacker can try millions of password combinations against an RDP endpoint without any throttling. Configure a lockout policy that disables an account temporarily after a small number of failed attempts.
Via Group Policy: Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy:
- Account lockout threshold: 5 invalid logon attempts (lower for high-security environments)
- Account lockout duration: 15 minutes (auto-unlock; avoids help desk burden for legitimate lockouts)
- Reset account lockout counter after: 15 minutes
Monitoring lockouts: Windows Security Event ID 4740 fires when an account is locked out. Configure a SIEM alert for multiple 4740 events from the same source IP: this indicates an active brute force attempt.
The lockout-vs-DoS tradeoff: An attacker who knows your lockout policy can intentionally lock accounts by trying the wrong password, creating a denial-of-service for legitimate users. This is less likely than opportunistic brute force but worth considering for accounts that should have longer lockout windows: or consider lockout on IP rather than account for internet-facing RDP.
Control 5: MFA on RDP Sessions
Even with NLA enabled, a stolen password still grants RDP access. Requiring MFA on RDP sessions means a stolen credential alone is not sufficient.
Option A: Remote Desktop Gateway with MFA (recommended for enterprise): Microsoft Remote Desktop Gateway (RD Gateway) proxies RDP connections and can be configured to require Azure MFA before establishing sessions. This requires Windows Server with RDS role: configuration instructions are in Microsoft's RD Gateway documentation.
Option B: Duo Security or similar third-party MFA agent: Duo, Silverfort, and several other vendors provide Windows login MFA agents that intercept the logon process and require a second factor via push notification or TOTP before completing authentication. These agents work for both console and RDP logons.
Option C: VPN with MFA as the RDP front-door: Require VPN connection (with MFA) before RDP access is permitted. The VPN's MFA acts as the first factor; Windows authentication is the second. Combined with Control 2 (restricting RDP to VPN subnet IP range), this prevents any RDP access without a valid VPN session.
Monitoring RDP authentications: Enable Windows Security audit logging for logon events. Key Event IDs for RDP monitoring:
- 4624 Logon Type 10: Remote interactive logon (RDP connection established)
- 4625 Logon Type 10: Failed RDP authentication
- 4778: RDP session reconnected
- 4779: RDP session disconnected
Alert on high volumes of 4625 Type 10 events from a single source IP: this indicates brute force before lockout triggers.
The bottom line
RDP hardening requires five controls in combination: NLA (highest single-control impact, enable first), source IP restriction to trusted networks, port change from 3389 to reduce automated scanner traffic, account lockout to prevent brute force, and MFA to require a second factor beyond the password. No single control is sufficient: the combination eliminates the attack surface that ransomware groups scan for while preserving legitimate remote administration. Start with NLA and IP restriction; add MFA as the highest-priority follow-on.
Frequently asked questions
How do I make RDP secure without disabling it?
Enable Network Level Authentication (NLA) first: this requires valid credentials before a desktop session is established. Then restrict RDP access to specific trusted source IPs via Windows Firewall, set an account lockout policy to prevent brute force, change the default port from 3389, and enforce MFA through an RD Gateway or third-party agent.
Is changing the RDP port enough to secure it?
No. Changing the port from 3389 reduces automated scanner traffic but does not stop a determined attacker who performs full port scans. Changing the port should be combined with Network Level Authentication, source IP restrictions, account lockout, and MFA: not used as a standalone security measure.
How do I add MFA to RDP without a VPN?
Microsoft's Entra ID (Azure AD) Application Proxy supports MFA-gated RDP for organizations using Entra ID. On-premises options include Duo Security's Authentication Proxy (integrates with Windows NPS for RADIUS-based MFA on RDP), and Silverfort (agentless MFA for RDP and other protocols). If you cannot implement any of these, the minimum acceptable control is restricting RDP access to VPN-sourced IPs only: require VPN first, then RDP. RDP exposed to the internet without MFA is the single most common initial access vector for ransomware deployments.
What RDP logging should I enable for security monitoring?
Enable these audit policies for RDP security monitoring: Audit Logon/Logoff (both success and failure) for Event IDs 4624, 4625, and 4634; Audit Other Logon/Logoff Events for Event ID 4778 (session reconnected) and 4779 (session disconnected); enable Remote Desktop Services logging in Applications and Services Logs for additional session detail. Ship these logs to your SIEM or Sentinel and alert on: successful RDP logons from external IPs, account lockouts on the RDP-accessible account, and logons outside business hours from the RDP service account.
Should I use RD Gateway to secure RDP access?
Yes, Remote Desktop Gateway (RD Gateway) is a Windows Server role that provides HTTPS-encapsulated RDP access without requiring VPN. It acts as an SSL/TLS proxy for RDP connections, allowing source IP restrictions, NPS-based authentication policies, and centralized logging. The benefits over raw RDP: only port 443 needs to be exposed (not 3389), authentication can be integrated with Network Policy Server for RADIUS-based MFA, and all sessions traverse a single choke point with logging. RD Gateway is included with Windows Server licensing at no additional cost.
What RDP-specific attack techniques should detection rules target beyond brute-force login attempts?
RDP brute force is the most-discussed threat, but several RDP attack patterns produce distinct signatures that detection rules should target. BlueKeep (CVE-2019-0708) and DejaBlue exploit pre-authentication memory corruption -- network-layer detection via IDS signatures for malformed RDP PDUs remains relevant for unpatched legacy systems. RDP session hijacking (tscon.exe abuse): attackers with SYSTEM access use tscon.exe to take over disconnected sessions without credentials, producing no logon event. Detect with process creation monitoring: tscon.exe spawned by non-admin processes or from unexpected parent processes (cmd.exe, PowerShell). RDP tunneling: attackers use RDP over SSH tunnels or HTTP proxies to evade firewall rules -- detect via network flow analysis showing RDP protocol signatures on non-standard ports. Clipboard hijacking via RDP: malicious files copied through the RDP clipboard channel appear in the destination filesystem without a network transfer event -- monitor for file creation events in the user's temp directory during active RDP sessions. Silver ticket attacks against RDP: an attacker with a service account hash for TERMSRV/hostname can forge a Kerberos service ticket for RDP without domain authentication -- detect via Kerberos ticket anomalies (Event ID 4769 for unusual service ticket requests).
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.