)
)
Introduction
An effective RDP hardening strategy begins by asking whether Remote Desktop Protocol should be enabled at all. When RDP is required, administrators should limit where connections originate, protect credentials, reduce session privileges and verify that every control works as intended across workstations, standalone servers, domain environments and Remote Desktop Services deployments.
What Is RDP Hardening?
RDP hardening is the process of reducing the attack surface associated with Remote Desktop Protocol while preserving the access legitimate users and administrators need. It combines Windows configuration, network controls, identity protection, session restrictions, patching and monitoring.
Hardening is not limited to changing port 3389 or enabling a firewall rule. Administrators must evaluate which systems accept connections, where users connect from, which accounts are permitted, how authentication works and which resources can move through a session.
CISA recommends disabling risky and unnecessary services , including RDP, where they are not required. The first hardening decision is therefore whether a device genuinely needs to expose it.
What Should an RDP Hardening Checklist Include?
Use this checklist as a quick audit before reviewing each control in detail. The exact configuration should reflect the system role, user population and network architecture.
| Priority | RDP hardening control | Expected state |
|---|---|---|
| Critical | Disable RDP where unnecessary | Only approved systems accept remote sessions |
| Critical | Prevent direct internet exposure | Connections use a gateway, VPN, bastion or allowlist |
| Critical | Strengthen authentication | NLA and MFA protect remote access |
| Critical | Restrict RDP users | Only approved accounts and groups can connect |
| High | Protect traffic and credentials | Trusted TLS certificates and suitable credential controls are used |
| High | Limit session capabilities | Redirection, idle time and disconnected sessions follow policy |
| High | Harden the Windows host | Systems are patched, segmented and minimally privileged |
| High | Monitor RDP activity | Logs are centralized and suspicious behaviour generates alerts |
| Operational | Test and review the baseline | Access, blocking, recovery and configuration drift are validated |
These controls form a layered baseline. The following sections explain how to implement and validate each area.
How Should You Reduce RDP Exposure?
Disable RDP on Systems That Do Not Need It
Do not leave Remote Desktop enabled merely because it may become useful later. Workstations, backend servers and application hosts that are not administered through RDP should not accept remote sessions.
Use Group Policy to prevent new incoming connections:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections > Allow users to connect remotely by using Remote Desktop Services
After disabling RDP, remove obsolete firewall rules, NAT mappings, cloud security-group entries and port-forwarding configurations. A local check can identify an active listener:
Get-NetTCPConnection -LocalPort 3389 -State Listen -ErrorAction SilentlyContinue
An empty result does not prove the host is unreachable from every network. Validate the change with external scanning and firewall reviews.
Avoid Publishing Port 3389 Directly to the Internet
A public RDP listener can be discovered and targeted with password spraying, credential stuffing and vulnerability scanning. Strong passwords and Network Level Authentication improve security, but they do not remove the risk created by an unrestricted internet-facing service.
A practical Remote Desktop risk score can help administrators rank exposed services, weak authentication and overly broad access before selecting corrective controls.
Place external access behind an appropriate control layer, such as:
- RD Gateway
- A properly secured VPN
- A bastion or jump host
- A Zero Trust access service
- A browser-based remote access gateway
- Just-in-time firewall access
- A strict source-IP allowlist
Fixed administrative locations may suit an allowlist, while mobile staff usually need an identity-aware gateway. RD Gateway can provide a managed entry point and integrate with Network Policy Server and Microsoft Entra multifactor authentication, keeping internal RDP hosts from being published directly.
Restrict the RDP Firewall Rule
An inbound firewall rule should not accept traffic from every address unless another effective restriction exists in front of it. Limit internal administration to management networks, VPN pools or designated jump hosts.
For cloud systems, review both Windows Firewall and the provider’s network controls. A restrictive Windows rule can still be undermined by broader exposure elsewhere.
RDP commonly uses TCP and may use UDP for improved transport performance. When changing the listening port, create corresponding TCP and UDP rules and test every supported connection path.
Should You Change the Default RDP Port?
Changing port 3389 can reduce basic scanning noise, but it does not improve authentication, encryption or authorisation. A determined scanner can still discover the service.
Treat a custom port as an optional operational measure. Document the new value, update monitoring and firewall rules, and test all clients. Microsoft stores the listener setting under:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
A restart is required after changing the
Port Number
value.
How Should You Harden RDP Authentication?
Enable Network Level Authentication
Network Level Authentication requires users to authenticate before Windows creates a full remote session. This reduces unauthenticated resource consumption and places an authentication barrier before the interactive logon screen.
Enable the following policy:
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
NLA should normally remain enabled. Temporary disabling may help controlled troubleshooting, but replacing obsolete clients is preferable to weakening the baseline permanently.
Require Multifactor Authentication
NLA is not multifactor authentication. It moves authentication earlier in the connection process but may still rely on a username and password.
MFA should protect externally accessible RDP paths and privileged remote administration. The implementation depends on the architecture. Traditional RDS environments commonly enforce MFA through RD Gateway, Network Policy Server, Microsoft Entra ID and the NPS extension. Other environments may use a server agent, Zero Trust gateway or remote access platform.
Plan MFA around enrollment, recovery, service accounts, outages, logging and a protected break-glass process. Emergency accounts should remain tightly controlled.
Limit Who Can Log On Through RDP
Use dedicated groups instead of granting access broadly through local Administrators membership. Review these policies:
Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment
The two most relevant settings are:
- Allow log on through Remote Desktop Services
- Deny log on through Remote Desktop Services
The deny policy takes precedence. Review assignments carefully to avoid blocking legitimate administrators.
List local memberships with:
Get-LocalGroupMember -Group "Remote Desktop Users" Get-LocalGroupMember -Group "Administrators"
On domain-joined systems, review nested groups and remove former employees, temporary vendors, service accounts, and broad groups that no longer need interactive access.
Separate Administrative and Standard Accounts
Administrators should not use privileged identities for email, browsing or daily work. Provide separate accounts for RDP administration and restrict where those identities can log on.
Domain Admin and equivalent accounts should not be used across ordinary member servers and workstations. If a lower-trust host is compromised, credentials or access tokens from an administrative session may support lateral movement.
Windows LAPS can manage and back up unique local administrator passwords on supported Windows systems. This avoids reusing one privileged password across multiple machines.
Protect Credentials with Remote Credential Guard
Remote Credential Guard protects credentials during supported direct RDP connections by redirecting Kerberos requests to the client device. Credentials and their derivatives are not sent to the remote host, reducing the risk of theft from a compromised destination.
This control requires Kerberos and supported Windows clients and hosts. It is not supported for connections through RD Gateway or Remote Desktop Connection Broker, so administrators must validate compatibility with the actual access path.
Use Modern Password and Lockout Policies
Accounts that can open RDP sessions need strong, unique passwords. Current NIST guidance emphasizes long passwords, compromised-password screening and changes after suspected compromise rather than arbitrary composition rules and routine rotation. Combine long passphrases, MFA, secure storage and the removal of shared or default credentials.
Configure lockout thresholds and durations as part of an RDP brute-force protection strategy that slows automated guessing without creating an easy denial-of-service condition. Base the settings on attack volume, monitoring capacity and support requirements.
How Should You Secure RDP Encryption and Certificates?
Require a Suitable Security Layer
RDP can use Transport Layer Security to authenticate the server and protect the connection. According to Microsoft Learn, certificates secure Remote Desktop Services deployments and the connections between RDS server roles.
Review this policy:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require use of specific security layer for remote connections
Use a certificate whose subject or subject alternative name matches the hostname users enter. Clients should trust the issuing certificate authority and should not be trained to ignore identity warnings.
The client connection encryption level policy applies to native RDP encryption, not sessions protected with SSL/TLS. Monitor certificate renewal and binding because an expired or incorrectly assigned certificate can make a hardened listener or gateway unavailable.
Which RDP Session Features Should You Restrict?
Disable Unnecessary Device and Resource Redirection
RDP can redirect local resources into a remote session. These features improve productivity but also create paths for malware, file transfers and data loss.
Review whether users genuinely need clipboard access, local drive mapping, printers, USB devices, audio recording, cameras, smart cards or web authentication redirection.
Policies are located under:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Device and Resource Redirection
Microsoft provides controls for drive mapping and directional clipboard transfer. For example, administrators can permit plain text while blocking richer content or disable transfer in one direction.
Do not disable every feature without testing. An application delivery server may require printer redirection, while a privileged jump host may need no clipboard or drive transfer.
Prevent Password Saving Where Appropriate
Saved RDP credentials increase exposure on administrator workstations and shared endpoints. Use the client policy:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Do not allow passwords to be saved
When enabled, the password-saving option is disabled and saved passwords are removed from RDP files. Pair this control with an approved credential-management process.
Configure Idle and Disconnected Session Limits
Closing an RDP window does not necessarily log the user off. Applications may remain active and the session may be resumed later.
Configure limits under:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Session Time Limits
Set appropriate values for idle sessions, disconnected sessions, maximum active duration and RemoteApp logoff. Avoid one aggressive timeout across every workload, because forced logoff can interrupt jobs or unsaved work.
Privileged systems usually justify shorter limits than application servers that support long-running business processes. Newer Windows policies can also disconnect remote sessions when the session is locked.
How Should You Harden the Windows Host?
Keep RDP Servers and Clients Patched
RDP security depends on both sides of the connection. A patched server may still be accessed from a compromised administrator workstation, while an outdated client can be exposed when connecting to a malicious host.
A wider endpoint posture review should also cover local administrator scope, saved credentials and active endpoint protection before a host is approved for remote access.
Maintain supported versions of Windows, Windows Server, Remote Desktop clients, RDS roles, identity components, access gateways and endpoint-security agents. Prioritise updates affecting remote code execution, authentication and credential handling.
Test updates against representative applications, printing, redirection and authentication workflows. Compatibility testing should not become a reason to leave critical systems indefinitely unpatched.
Segment RDP Systems
An authenticated RDP session should not automatically provide access to every internal subnet. Use network segmentation and host firewalls to control what an RDP server can reach after login.
Separate administrative jump hosts, RD Session Hosts, domain controllers, file servers, database servers, backup infrastructure, management interfaces and user workstations where appropriate.
Apply outbound restrictions when the server role permits them. If an attacker compromises an RDP session, segmentation can limit lateral movement, access to backups and communication with external command infrastructure.
Remove Unnecessary Software and Privileges
Every service, application and management tool installed on an RDP host expands the environment that must be patched and monitored.
Remove obsolete applications, unused Windows features and abandoned agents. Restrict software installation, PowerShell, command-line tools and administrative interfaces according to the server role.
For multi-user application servers, application control and tightly scoped filesystem permissions can prevent one user from accessing another user’s data or launching unapproved executables.
How Should You Monitor RDP Activity?
Enable and Centralize Windows Auditing
Local logs are useful for troubleshooting but are not sufficient if an attacker can alter or delete evidence after compromising the server. Forward important events to a SIEM, Windows Event Collector or another protected logging platform.
Collect at least:
- Successful and failed logons
- Account lockouts
- Group membership changes
- New or modified user accounts
- Remote session creation and disconnection
- Firewall changes
- Service installation
- Privilege assignment
- Endpoint security alerts
Security events 4624 and 4625 record successful and failed logons. For RDP analysis, inspect the logon type, account, workstation and source network information. Remote interactive logons are commonly identified as logon type 10.
Terminal Services operational logs add session context, while event 4779 records disconnection from a Windows station.
Alert on Behaviour, Not Only Individual Failures
A single failed password may be a user mistake. Detection rules should look for patterns such as many failures from one address, one source testing multiple usernames, failures across several servers or a successful login after repeated failures.
Useful signals also include access from a new country, privileged use outside normal hours, dormant-account activity, new group membership followed by RDP, security-tool disablement or unusual file encryption. An advanced security solution can help centralise these detections and automate responses to suspicious RDP behaviour. Thresholds must reflect normal behaviour and the organisation’s operating model.
Prepare an RDP Incident-Response Procedure
Hardening cannot guarantee that no account or server will be compromised. Administrators need a documented response process before an alert occurs.
The procedure should cover isolation, hostile-IP blocking, account resets, session revocation, log preservation, neighbouring-system checks, persistence review, trusted recovery and baseline revalidation.
Maintain a console, cloud control plane or out-of-band recovery path. Otherwise, an incorrect firewall or Group Policy change may leave administrators unable to reach the server during an incident.
How Can You Validate an RDP Hardening Baseline?
A setting is not implemented merely because it appears in a Group Policy Object. Confirm that the intended policy reaches the target device and produces the expected result.
Useful commands include:
gpresult /h C:\Temp\RDP-Policy.html
Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
Select-Object DisplayName, Enabled, Direction, Action
Get-LocalGroupMember -Group "Remote Desktop Users"
Test-NetConnection server.example.com -Port 3389
Validation should cover successful and unsuccessful cases. Confirm that approved users can connect, unauthorized users and sources are blocked, MFA appears, certificates are trusted, redirection restrictions remain active and session limits work.
Verify that central logging receives successful and failed attempts and that administrators can use the recovery route. Test restrictive changes on a representative system, and record exceptions with an owner and expiry date.
How often should you review the RDP hardening checklist?
Review the baseline after major Windows updates, network changes, identity migrations, new RDS deployments and security incidents. Schedule formal reviews according to the organisation’s risk profile.
Between reviews, watch for configuration drift, including RDP being re-enabled, new public firewall rules, added Remote Desktop Users, disabled NLA, expired certificates, unmonitored servers, MFA exclusions, newly enabled redirection and obsolete vendor accounts.
Automated configuration management can detect these deviations more reliably than occasional manual checks.
Strengthen RDP Protection with TSplus
Native Windows controls provide the foundation for RDP hardening. TSplus Advanced Security adds centralized protections for Windows and Remote Desktop servers, including automated brute-force blocking, geographic restrictions, ransomware protection, trusted-device controls, working-hours policies and malicious-IP protection.
These controls can reinforce the baseline by responding automatically to hostile behaviour and narrowing where, when and how remote users connect. They do not replace Windows hardening, but they can simplify enforcement and monitoring across multiple systems.
Conclusion
A secure RDP deployment starts by removing unnecessary listeners and avoiding direct internet exposure. Systems that still require RDP should combine NLA, MFA, limited user rights, trusted TLS certificates, credential protection, restricted redirection, patching, segmentation and centralised monitoring.
The final baseline must match the role of each system. An internal administration server, cloud virtual machine, multi-user RD Session Host and contractor access environment do not require identical controls. Document the chosen configuration, test it against real workflows and review every exception regularly.
)
)
)
