What Is the Remote Desktop Protocol?
The Remote Desktop Protocol (RDP) is a proprietary protocol developed by Microsoft that enables a user to connect to and control a remote computer over a network connection. When you open an RDP session, your keyboard strokes and mouse movements travel to the remote machine, while the remote machine’s display output streams back to your device. The result feels like sitting in front of the machine itself, even if it is in a data center on the other side of the planet.
RDP listens on TCP port 3389 by default and is built into every modern edition of Windows. IT administrators rely on it to manage servers, support teams use it to troubleshoot employee workstations, and remote workers use it to reach office desktops from home. Beyond Microsoft’s own implementation, many third-party remote desktop software tools — including open-source options like xRDP and FreeRDP — support the protocol, making RDP one of the most widely deployed remote access technologies in the world.
That ubiquity is exactly why remote desktop protocol security deserves careful attention. Any technology installed on millions of machines and exposed to the internet becomes a high-value target. In recent years, security researchers have repeatedly found that exposed RDP endpoints rank among the most common entry points for ransomware and credential-theft attacks. A protocol this powerful needs to be hardened deliberately, not left on default settings.
Why Remote Desktop Protocol Security Matters in 2026
Remote desktop software sits at a unique point of risk: it is designed to give complete control of a computer to a remote user, which means an attacker who compromises an RDP session gains complete control too. Unlike a web application vulnerability that might expose a database, a breached remote desktop session hands over a fully interactive machine — files, applications, network access, and sometimes the keys to the entire corporate network.
The threat landscape facing RDP
Several trends have made RDP a prime target. First, automated scanners constantly probe the internet for systems listening on port 3389, and brute-force tools can test thousands of username and password combinations per hour against weakly protected endpoints. Second, ransomware operations routinely use compromised RDP credentials as their initial access vector: once inside one machine, they move laterally through the network until they can encrypt the most valuable systems. Third, credential stuffing — reusing passwords leaked from other breaches — remains effective because many organizations still allow simple or reused passwords on remote access accounts.
None of this means RDP is inherently broken. When configured according to modern remote desktop protocol security best practices, RDP sessions use strong encryption, authenticate both parties, and can be layered behind additional defenses. The problem is almost always deployment, not the protocol itself. Default configurations that prioritize convenience — the standard port, password-only logins, no lockout policy, direct internet exposure — are what turn a useful tool into a liability.
Who needs to care
If your organization uses remote desktop software in any capacity, this guide is for you. That includes:
- IT administrators managing Windows servers and virtual desktops over RDP
- Small business owners who enabled remote access so staff could work from home
- MSP and helpdesk teams connecting to client machines for support
- Developers and power users running Windows-based build, test, or trading environments in the cloud
- Anyone who has ever opened port 3389 on a router “just to try it out”
The good news is that securing RDP does not require expensive products. Most of the defenses in this guide are built into Windows and free to enable. They just require someone to turn them on deliberately.
Remote Desktop Protocol Security Best Practices
The following practices are ordered roughly by impact: the first few eliminate the majority of real-world attacks, while the later ones add defense in depth. Implement them all for a genuinely hardened deployment.
1. Never expose RDP directly to the internet
The single most important rule of remote desktop protocol security is this: an RDP server should never be reachable from the public internet on its own. Every day, automated bots scan entire IPv4 ranges for open port 3389. Any directly exposed endpoint will be found within hours and subjected to continuous login attempts.
Instead of direct exposure, place RDP behind one of these:
- A VPN — users connect to the corporate VPN first, then reach RDP over the private network. This reduces the RDP attack surface to authenticated VPN users only.
- Remote Desktop Gateway (RD Gateway) — Microsoft’s role service that tunnels RDP over HTTPS (port 443) and applies authorization policies before the session is even established. An RD Gateway lets external users connect without a VPN while keeping RDP servers off the public internet.
- A zero-trust network access (ZTNA) broker — modern alternatives that verify user identity and device posture before granting per-application access, without placing the user on the network at all.
If you discover that any of your machines accept RDP from the public internet today, treat removing that exposure as your highest-priority action — ahead of everything else in this guide.
2. Require Network Level Authentication (NLA)
Network Level Authentication requires the connecting user to authenticate before a full remote desktop session is established. Without NLA, an attacker can open a session handshake with the server and begin probing it; with NLA, the connection is refused unless valid credentials are presented up front.
NLA also enables Credential Security Support Provider (CredSSP) protections that help guard against credential relay attacks. On modern Windows systems, NLA is enabled by default, but it is worth verifying — especially on older servers or machines configured years ago. You can check and enforce it in System Properties under Remote settings, or through Group Policy at 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.”
3. Enforce multi-factor authentication on every session
Passwords alone are no longer sufficient for remote desktop protocol security. Leaked credentials, phishing, and credential stuffing all defeat password-only authentication, and remote access is precisely where stolen credentials cause the most damage.
Multi-factor authentication (MFA) for RDP can be deployed in several ways:
- Through the RD Gateway, which integrates with Azure AD / Microsoft Entra MFA or RADIUS-based MFA providers
- Through the VPN or ZTNA broker sitting in front of RDP, so MFA is enforced before the user ever reaches the desktop
- With third-party RDP MFA agents that add a second-factor prompt to the Windows logon on the target machine
Security guidance such as NIST’s authentication standards treats two distinct factors as the baseline for remote access to enterprise resources and recommends phishing-resistant options where available. Whatever mechanism you choose, the policy should be absolute: no remote desktop session without a second factor, for every user, including administrators.
4. Use strong passwords and account lockout policies
Even with MFA, password hygiene matters. Enforce long, complex passwords through Group Policy, and — critically — configure account lockout thresholds so that brute-force attempts are cut off after a small number of failures. A common configuration locks an account for 30 minutes after five failed attempts within 15 minutes.
Also disable or rename the built-in Administrator account where practical, and never allow the default “Administrator” username to be reachable over RDP. Attackers always try it first; removing it from the equation forces them to guess both the username and the password.
5. Apply the principle of least privilege
Only users who genuinely need remote desktop access should be members of the Remote Desktop Users group on any given machine. Review membership regularly and remove stale accounts — especially those of former employees and contractors. Service accounts should not have interactive RDP logon rights unless strictly necessary.
For servers, separate administrative RDP access from user access. Administrators should connect with dedicated admin accounts rather than their daily-use accounts, so that a compromise of a workstation does not hand over domain-admin credentials on a silver platter.
6. Change the default RDP port — with realistic expectations
Moving RDP from port 3389 to a non-standard port is a frequently recommended step, and it does reduce noise: most automated scanners target 3389 specifically, so changing the port cuts down on opportunistic brute-force traffic dramatically. It is a worthwhile hardening step for small deployments.
However, treat it as camouflage, not armor. A determined attacker will port-scan the full range and find the listening service regardless. Never rely on a changed port as a substitute for MFA, NLA, or keeping RDP off the public internet. Defense in depth means every layer adds something; obscurity alone adds almost nothing against a targeted attack.
7. Keep systems patched and updated
RDP has had its share of serious vulnerabilities over the years — including remotely exploitable “wormable” flaws that required no authentication at all. The only reliable defense is a disciplined patching cadence for both the RDP server components and the underlying Windows operating system.
Enable automatic security updates where possible, and make RDP-facing systems part of a fast-track patch group rather than the general monthly cycle. Equally important: update your RDP clients. Older clients may negotiate weaker encryption or lack NLA support, dragging the security of the whole session down to their level.
8. Enforce strong encryption for the session
Modern RDP supports TLS-based encryption that protects the session against eavesdropping and tampering. In Group Policy, set the security layer to SSL (TLS 1.0+) or negotiate with the highest available encryption level, and configure the encryption level to “High” or FIPS-compliant where your compliance requirements demand it.
For RD Gateway deployments, ensure the gateway presents a valid, trusted certificate from a public certificate authority — not a self-signed one that trains users to click through warnings. Certificate warnings that users routinely ignore are a social-engineering opportunity for attackers running machine-in-the-middle attacks.
9. Log, monitor, and alert on RDP activity
You cannot defend what you cannot see. Enable auditing of logon events on every RDP-accessible machine and forward the logs to a central SIEM or log management system. Pay particular attention to:
- Event ID 4625 — failed logon attempts; bursts of these from one source indicate brute-forcing
- Event ID 4624 (logon type 10) — successful RDP logons; review for logons at unusual hours or from unexpected locations
- Event ID 1149 — Remote Desktop Services successful network authentication events
Build alerts for patterns that indicate active attacks: dozens of failed logons in minutes, successful logons following failed bursts, logons from new geographies, and RDP sessions on machines that should never have them. A modest amount of monitoring effort here catches the majority of in-progress RDP compromises.
10. Restrict access with host-based firewalls and network segmentation
Even behind a VPN or gateway, restrict which systems can initiate RDP connections using Windows Firewall rules and network security groups. Limit inbound 3389 to the IP ranges of your VPN concentrators, gateway servers, or jump hosts — never the whole internal network if you can avoid it.
Network segmentation adds another layer: place RDP-accessible servers in a dedicated segment so that even if one session is compromised, the attacker cannot freely reach databases, domain controllers, or backup infrastructure from it. Jump hosts (bastion servers) — hardened machines through which all RDP sessions must pass — give you a single, well-monitored choke point.
11. Disable RDP where it is not needed
The most secure RDP server is one that does not exist. Audit your environment for machines with remote desktop enabled that no longer need it — decommissioned servers, former employee workstations, test VMs that were never cleaned up. Every unnecessary RDP endpoint is an unnecessary target.
On Windows, you can check enablement remotely with a simple PowerShell query against the fDenyTSConnections registry value, and disable it fleet-wide through Group Policy. Make this audit a recurring task, not a one-time cleanup.
Building a Secure Remote Desktop Architecture
Individual hardening steps matter, but the architecture around your remote desktop software determines your overall resilience. Here is how the common deployment models compare from a security perspective.
RD Gateway deployments
An RD Gateway is Microsoft’s purpose-built answer to safe internet-facing RDP. It encapsulates RDP traffic in HTTPS, authenticates users against Active Directory, and applies connection authorization policies (who may connect) and resource authorization policies (which machines they may reach). Combined with MFA, a properly configured gateway is the baseline recommendation for organizations that need RDP reachable from outside the office.
VDI vs. session-based remote desktops
For larger fleets, Virtual Desktop Infrastructure (VDI) gives each user an isolated virtual machine, while Remote Desktop Session Host (RDSH) shares one Windows Server among many users. From a security standpoint, VDI’s isolation limits the blast radius of a compromised session — malware in one user’s desktop cannot easily reach another’s. RDSH is cheaper and lighter but means a single compromised session shares an operating system with everyone else on the host. High-risk users and workloads justify VDI; general office workloads are often fine on hardened RDSH.
Zero-trust approaches
The direction the industry is moving is zero-trust remote access: verify identity and device health for every connection, grant the minimum access needed, and never trust a session just because it originates from inside the network. ZTNA brokers apply this model to remote desktops by publishing individual applications or desktops to authenticated users without exposing network ports at all. If you are planning a refresh of your remote access stack, evaluate whether a zero-trust broker fits better than a traditional VPN-plus-RDP design.
Common RDP Attack Vectors — and How to Block Them
Understanding how attackers actually break in helps you prioritize. Here are the most common vectors mapped to the defenses from this guide:
- Brute-force and password spraying — thousands of login guesses against exposed port 3389. Blocked by: no direct internet exposure, account lockout policies, MFA.
- Credential stuffing — replaying passwords leaked from unrelated breaches. Blocked by: MFA, unique strong passwords, monitoring for anomalous logons.
- Exploiting unpatched RDP vulnerabilities — attacks against the protocol implementation itself. Blocked by: aggressive patching, NLA (which prevents pre-authentication exploitation in many cases).
- Man-in-the-middle attacks — intercepting sessions on untrusted networks. Blocked by: TLS encryption, valid certificates, VPN or gateway tunneling.
- Lateral movement after an initial breach — using legitimate RDP to hop between machines once inside. Blocked by: least privilege, network segmentation, jump hosts, monitoring type-10 logons.
- Social engineering of helpdesk staff — tricking support into enabling or approving remote sessions. Blocked by: strict verification procedures, session approval workflows, user training.
Remote Desktop Protocol Security Checklist
Use this checklist as a quick audit of any RDP deployment:
- RDP is not directly reachable from the public internet (VPN, RD Gateway, or ZTNA in place)
- Network Level Authentication is required on all RDP hosts
- Multi-factor authentication enforced for every remote desktop session
- Account lockout policy configured (e.g., 5 failures → 30-minute lockout)
- Only authorized users in the Remote Desktop Users group; membership reviewed regularly
- Default port changed (as a noise-reduction measure, not a primary defense)
- Security patches applied promptly, including on RDP clients
- TLS encryption enforced with valid, trusted certificates
- Logon auditing enabled with centralized logging and alerts
- Firewall rules restrict RDP sources; network segmentation in place
- Unneeded RDP endpoints disabled
Frequently Asked Questions
Is RDP safe to use over the internet?
RDP is safe over the internet only when it is not directly exposed — that is, when accessed through a VPN, an RD Gateway with MFA, or a zero-trust broker. An RDP server listening directly on the public internet will be discovered and attacked automatically, regardless of how strong the password is.
Does changing the default RDP port make it secure?
No. Changing the port from 3389 reduces automated scanning noise but provides no real protection against a targeted attacker who will simply scan all ports. Treat it as a supplementary step alongside MFA, NLA, and proper network placement.
What is the difference between RDP and a VPN?
A VPN creates an encrypted tunnel that places your device on a private network; RDP is a protocol for remotely controlling a computer’s desktop. They are complementary: a VPN secures the path, and RDP provides the desktop. Many secure architectures run RDP inside a VPN tunnel or behind an RD Gateway.
Should small businesses worry about RDP security?
Yes — arguably more than large enterprises, because small businesses rarely have dedicated security teams yet face the same automated attacks. The basics (no direct internet exposure, MFA, patching, lockout policies) are free to implement and eliminate the vast majority of risk.
Conclusion
Remote desktop protocol security is not about any single magic setting. It is about layering sensible, mostly free defenses: keep RDP off the public internet, require Network Level Authentication, enforce multi-factor authentication, patch promptly, grant the minimum access necessary, and watch the logs for signs of attack. Each layer is simple on its own; together they transform RDP from one of the most attacked services on the internet into a well-defended, trustworthy part of your remote access strategy.
If you take one action from this guide, make it the first: verify today that none of your machines accept RDP connections directly from the internet. Everything else builds on that foundation. In 2026, with remote and hybrid work firmly established, securing the protocols your people rely on every day is not optional maintenance — it is the core of keeping your organization safe.