Microsoft's Remote Desktop Protocol is an essential tool for managing servers and working remotely with Windows computers , but its exposure to the internet carries risks that shouldn't be overlooked. If RDP isn't configured properly, it can become a perfect entry point for malicious actors and malware.
In this practical and technical guide, I explain how to reduce the attack surface of RDP, which settings are mandatory today (NLA, MFA, TLS, firewalls, RD Gateway, VPN, among others), how to manage patches, and which policies to apply to block brute-force attacks and unauthorized access . We also review RDS compatibility by version, GPU acceleration, SSO, and tools that enhance your defenses.
Real risks and why RDP is so attractive to attackers
RDP opens a window for remote administration that, if not properly secured, becomes a highly profitable target. Its widespread adoption and the possibility of complete remote system control make it an active target for cybercriminals.
What makes it so appealing?
When a service is ubiquitous and readily accessible via the internet, attackers can bypass layers of perimeter defense if they find valid credentials or a misconfiguration. With RDP, a single compromised machine can serve as a pivot point for lateral movement across the network and the deployment of ransomware.
Most common vulnerabilities and attack vectors
- brute force attacksUse of automated tools to try usernames/passwords until successful. Weak passwords and unlimited attempts significantly increase the risk.
- Man in the Middle (MitM): intercepting the channel between client and server. Without proper encryption, the traffic can be read or manipulated.
- Default port exposure: 3389 is well-known and easy to scan; thus, bots discover RDP services in minutes.
- BlueKeep (CVE-2019-0708): critical flaw in older versions of Windows that allowed remote code execution without authentication. Unpatched systems remain at risk.
Impact of a compromised RDP session
Unauthorized access can lead to data theft, mass encryption with ransomware, exfiltration, or the use of the server as a springboard for further intrusions. The result is operational downtime, forensic costs and penalties , in addition to reputational damage.
Empirical evidence reinforces the danger: in one month, an experiment using default RDP honeypots recorded 4,3 million attempts, with the first attack occurring just 1 minute and 20 seconds after exposure. Within 15 hours, all honeypots had been compromised. Default user accounts (administrator, admin, user, AWS ssm-user) were tested, and the attacks focused primarily on weak passwords.
Furthermore, with search engines like Shodan, anyone can list hosts with port 3389 open, filter by country (for example, "ES"), and even view screenshots of remote desktops, which already constitutes a data leak. Automation with botnets and dictionaries does the rest.
Essential measures to protect RDP
Network Level Authentication (NLA)
NLA requires user authentication before establishing a graphical session, reducing resource consumption and preventing many brute-force attacks. On Windows hosts, you can enforce this via policy in "Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Session Host > Security" by enabling "Require Network Level Authentication ," or from System Properties > Remote.
Strong passwords and MFA
Enforce complexity and rotation policies from Active Directory and add multi-factor authentication (e.g., Duo, Microsoft Authenticator, or smart cards). It's preferable to use code or push applications instead of SMS, which is more vulnerable . MFA is the barrier that makes all the difference when credentials have already been exposed.
Keeping everything up to date: patches and scans
Automate with WSUS or equivalent solutions and apply Group Policy Objects (GPOs) for automatic updates on client machines. Complement this with regular vulnerability scans (Nessus, OpenVAS), off-peak scheduling, and reports to prioritize remediation. Integrating findings with your patch manager ensures that critical vulnerabilities are closed promptly.
Firewalls, allowlists, and IDS
Restrict RDP access to only specific IPs or ranges using firewall rules. Add an IDS/IPS that alerts you to spikes in failed attempts, brute-force patterns, or other anomalies. And implement tiered account lockout policies to prevent mass retries.
Changing the port: helpful, but not definitive
Changing port 3389 to something else reduces noise from basic scanners, but it's not a solid defense: attackers can identify the service by its response. If you decide to do this, change the "PortNumber" value in "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" and adjust firewall and NAT rules.
RD Gateway and VPN
RD Gateway encapsulates RDP over HTTPS, centralizes access, enforces policies, and facilitates auditing. Install the role, configure all external connections to use the gateway, and restrict access by group, time, and IP address. Add a VPN for a pre-encrypted tunnel, but be aware: a simple VPN only provides channel privacy ; true security is achieved by adding MFA, certificates, segmentation, and least privilege. A zero-trust approach is ideal.
Practical setup and troubleshooting
First, enable Remote Desktop on the target computer (Windows 10/11: Settings > System > Remote Desktop) and note the computer name. Check that the firewall allows the Remote Desktop application on both private and public networks and, if necessary, create specific rules for each IP address.
Control who logs in: From System > Remote Configuration > "Select Users," add only the necessary accounts, avoiding generic users. Another best practice is to review the local policy to see who can "Allow logon through Remote Desktop Services" and remove default groups to add users one by one.
Strengthen security via Group Policy under "Remote Desktop Session Host > Security": set the encryption level to High, enforce secure RPC communication, require the use of a specific security layer in SSL/TLS, and enable NLA. This combination makes Man-in-the-Middle attacks more difficult and ensures strong end-to-end encryption.
Typical mistakes and remedies:
“Remote desktop cannot connect to the remote computer”
It's usually a network, firewall, or incorrect name issue. Verify that the computer is powered on and accessible, that RDP is enabled, that the port (3389 by default or the new one you define) is open on the router/firewall, and that you are using the correct IP address or FQDN. If NAT is enabled, adjust port forwarding.
“The credentials used are incorrect”
Verify username, password, and, if applicable, domain. With NLA enabled, the account must have remote login permissions. If you're using MFA, verify that the second factor is operational and that the RADIUS/IdP provider is responding correctly.
“Remote Desktop connection exhausted”
This indicates blocking or excessive latency. Check end-to-end connectivity, review the port in the firewall, adjust client timeouts if necessary, and evaluate link quality.
“The remote desktop session has ended”
This could be due to network instability, remote computer suspension, or resource/connection limits. Prevent suspension/hibernation, monitor CPU/RAM/SESSIONS, and verify that there are no policies that prematurely terminate inactive sessions .
“The remote device cannot be authenticated”
This is usually a certificate issue. Use a certificate from a trusted CA on the RDP server (install it via MMC > Certificate Snap-in) and configure TLS on the session host. If you trust the server, you can accept the warning, but the correct procedure is to sanitize the certificate.
RDS on Windows Server: Versions, GPUs, and SSO
Version interoperability matters. For the infrastructure (Web Access, Gateway, Connection Broker, and Licenses), it's recommended to keep it on the latest version available for the environment, as this offers compatibility with components from previous versions, but not always the other way around. For example, a 2022 Session Host can communicate with a 2025 Connection Broker , but not necessarily vice versa.
In collections, all session hosts must be at the same OS level, although you can have multiple collections with different versions (one with 2019 and another with 2025). Remember that the license server only processes CALs of its version or earlier; if you upgrade hosts to 2025, update the license server. In high availability, Connection Brokers must be aligned at the same level.
GPU and performance: RDP can use hardware GPUs for all sessions, supports hardware H.264/AVC encoding when the GPU allows it, and since Windows Server 2019 has offered multi-GPU load balancing, bandwidth optimizations, and 4K support. In VDI, Windows 10 added hardware H.264 encoding starting with version 1703 and optimizations/load balancing/4K support starting with version 1803. Keep in mind WHQL driver requirements, potential GPU vendor licensing, and that non-Microsoft platforms or hypervisors must provide signed drivers.
If you require graphics virtualization, scenarios using RemoteFX vGPU in Hyper-V guests and Discrete Device Allocation (DDA) for physical GPUs on hosts running Windows Server 2016 or later are supported. For VDI with RDVH, supported guests include Windows 11 Enterprise and Windows 10 Enterprise, covering most enterprise use cases.
SSO: There are two main experiences. On the client (Windows, iOS, Android, Mac), you can securely store credentials depending on the system. For web SSO, you must use Remote Desktop Web Access with Forms Authentication, a Gateway with Password Authentication, and the "Use Gateway Credentials..." deployment property enabled. Supported web SSO requires a connection from Internet Explorer; other combinations are not officially supported.
Proxy publishing: RDS works with Microsoft Entra Application Proxy, but not with Web Application Proxy. This is an interesting way to expose Web Access and Gateway while maintaining centralized and modern control.
Tools that enhance RDP security
Defense in depth relies on specialized software. Suites like RDS-Tools add two-factor authentication, strong session encryption, granular permission control (applying the principle of least privilege), secure desktops, access time slots, and endpoint protection. Deployment is quick: features such as brute-force detection , homeland access lists, and blocking of known malicious IPs are activated in just a few clicks.
For visibility and responsiveness, RDS-Tools Server Monitoring offers real-time session monitoring, configurable thresholds, and customizable reports. This telemetry allows you to detect unauthorized access, resource saturation, or abuse, and provide instant notifications.
Customized access policies are key: limiting attempts, defining allowed IP ranges, enforcing schedules, denying unnecessary escalations, and enabling endpoint protection consistent with your hardening. The more precise the rules, the smaller the attack surface and the better the traceability.
In remote support, "Remote Support" solutions with self-hosted servers enhance privacy and performance by maintaining routing control. Adding these layers to Microsoft's built-in security reduces deployment effort in cloud, on-premises, or hybrid models, integrating seamlessly with existing infrastructure.
Other market alternatives, such as TSplus or Chrome Remote Desktop , provide gateways, MFA, encryption, and additional controls for RDP environments, focusing on ease of deployment and policy hardening. These are options to consider when you're looking to strengthen your RDP perimeter without extensive reconfiguration.
If you prefer to avoid exposing RDP, an alternative is to use a dedicated remote access solution like AnyViewer, which uses elliptic curve encryption (ECC) and simplifies unattended connections. Its typical workflow involves installation on both machines, registering an account, logging in, and controlling the remote device with a single click. Advanced plans allow you to assign more devices, group them for bulk management, use a privacy mode to block screen/input, monitor multiple endpoints in a single window, and deploy at scale.
If you take care of the fundamentals (NLA, MFA, TLS, firewall, gateway, patches, visibility) and rely on security tools, RDP ceases to be an Achilles' heel and becomes a robust service. With a well-tuned layered strategy, brute-force attacks become less effective, vulnerabilities are patched in time, and sessions are kept under control and secure.
