Is It Safe to Expose RDP to the Internet? (2026 Guide)

No. Exposing RDP directly to the internet is not safe. When Sophos set up an RDP honeypot, the first brute force attempt arrived in about one minute. Over the next 15 days, they recorded more than 2 million failed login attempts from 999 unique IP addresses using 137,500 different usernames.

That is what happens every time port 3389 goes live on a public IP. But if you are reading this, you probably already suspect the answer is "no" — and you need to know what to do about it.

What happens when port 3389 is open to the internet?

The moment your RDP port is reachable from the internet, automated scanners find it. Not in hours. Not in days. In minutes.

The Sophos honeypot data paints a clear picture. The username "administrator" alone was tried 866,862 times in those 15 days. Attackers used massive credential lists, cycling through common usernames and leaked passwords around the clock.

Changing the port does not solve the problem either. The same honeypot showed that moving RDP to a non-standard port only delayed discovery briefly — scanners found it anyway.

The scale is staggering. Shodan scans consistently show millions of RDP servers exposed to the internet — the number peaked above 4.5 million during the 2020 remote-work surge. In October 2025, GreyNoise documented a coordinated botnet of over 100,000 IPs from more than 100 countries targeting US RDP services. Within days, the botnet grew to approximately 300,000 IPs.

This is not theoretical risk. According to the Sophos 2025 Active Adversary Report, RDP was involved in 84% of the managed detection and incident response cases examined in the report — primarily for lateral movement within networks once attackers gained initial access. It remains the single most abused legitimate tool in real-world breaches.

Why do people still expose RDP?

Because they need remote access, and RDP is already there.

RDP is built into every Windows Server and Pro desktop. It costs nothing extra. There is no license to buy, no hardware to install, no client software to deploy. For a small business with five employees who need to reach the office server from home, RDP is the obvious answer.

Many of these setups started during the COVID-era scramble to get people working remotely. A quick port forward on the router, and suddenly the team could work from home. The "temporary" setup became permanent.

Others have real constraints. Legacy line-of-business applications that cannot move to the cloud. No IT staff to set up and maintain a VPN. Managed service providers who need quick access to dozens of client environments. Budget limitations that make enterprise solutions unrealistic.

This is not stupidity. It is a practical response to real business needs. But it does come with serious risk — and that risk needs to be managed.

What do CISA and Microsoft say?

Both are unambiguous: do not expose RDP directly to the internet.

CISA recommends blocking TCP port 3389 at the enterprise perimeter firewall and accessing RDP only through a VPN with multi-factor authentication or a zero-trust gateway. They also advise enforcing account lockout policies and auditing all RDP sessions.

Microsoft's guidance says to use Remote Desktop Gateway (RD Gateway) with SSL instead of exposing RDP directly. They also recommend Network Level Authentication (NLA), MFA, and restricted admin mode for helpdesk scenarios.

The official answer is clear. But if you cannot follow it today, you still have options to reduce your risk significantly.

What if you must expose RDP anyway?

If removing RDP from the internet is not possible right now, layer these protections. No single step is enough on its own, but together they make a meaningful difference.

1. Enable Network Level Authentication (NLA)

NLA requires users to authenticate before a full Remote Desktop session starts. This blocks many automated tools that rely on reaching the login screen directly. It is a built-in Windows setting and costs nothing to enable.

2. Use strong passwords and configure account lockout

The Sophos honeypot showed "administrator" targeted 866,000 times. Default account lockout policies on many Windows Server versions are not configured — meaning an attacker can try passwords indefinitely. Set a lockout threshold (for example, lock the account for 30 minutes after 5 failed attempts). This is a built-in feature that many administrators never turn on.

3. Rename or disable the default Administrator account

If every automated script tries "administrator" first, do not have an account with that name. Rename it to something non-obvious or disable it entirely and use a different admin account.

4. Change the default port

Moving RDP off port 3389 will not stop a determined attacker, but it does eliminate the bulk of automated scanning traffic. Think of it as reducing noise, not as real security. It takes five minutes and makes your logs much quieter.

5. Restrict access by IP where possible

If you know which IP addresses need RDP access — your office, your home, your MSP — use your firewall to allow only those. There is no reason the entire internet should be able to reach your Remote Desktop service.

6. Add automated brute force protection

Tools that monitor failed login attempts and automatically block offending IPs close the gap between an attack starting and a response. BruteFence is one option in this category — it watches for repeated failed RDP logins and blocks the source IP in real time, installs in about five minutes, and runs entirely on your server with no cloud dependency. You can read more about how it works in the documentation. It is not a replacement for the other steps on this list, but it adds a practical layer when you cannot avoid having RDP exposed.

7. Keep your systems patched

BlueKeep (CVE-2019-0708) demonstrated that RDP vulnerabilities can allow remote code execution without any authentication at all. Newer RDP-related vulnerabilities continue to surface. Patching is not optional.

8. Monitor your logs

Failed RDP login attempts are recorded in Windows Event Logs. If you are not watching them, you will not know you are under attack until something breaks. Set up alerts for unusual patterns — spikes in failed logins, off-hours access attempts, or logins from unexpected locations.

For more background on how these attacks work, see our guide on what an RDP brute force attack is and why it matters.

Better alternatives worth considering

If you have even a small budget or some technical flexibility, these options remove RDP from direct internet exposure entirely.

VPN + RDP behind the firewall. The classic approach. RDP never touches the public internet — users connect to a VPN first. Requires some setup and maintenance, but it is the most proven option. WireGuard and OpenVPN are solid free choices if cost is a concern.

Remote Desktop Gateway (RD Gateway). A Windows Server role that tunnels RDP traffic over HTTPS. If you already run Windows Server, this is built in. It adds SSL encryption and allows you to restrict who connects and when.

Tailscale or Cloudflare Tunnel. Modern alternatives that are especially practical for small businesses. Tailscale creates a private mesh network with minimal configuration (the free Personal plan supports up to 3 users for non-commercial use). Cloudflare Tunnel lets you expose services through Cloudflare's network without opening inbound ports (the free tier supports up to 50 users).

Any of these is a significant step up from direct RDP exposure. If you can adopt one, you should.

The bottom line

Exposing RDP to the internet is not safe. The data is clear, the official guidance is unanimous, and the attacks are constant and automated.

But millions of businesses do it because they need remote access and the alternatives feel out of reach. If that is your situation, the hardening steps above are not perfect — but they are far better than leaving port 3389 open with default settings.

If you can move RDP behind a VPN or gateway, do it. If you cannot do it today, layer your defenses and make a plan to get there. And either way, know what is happening on your server. BruteFence offers a free 7-day trial that will show you exactly how often your RDP service is being tested — the numbers tend to make the case for better security on their own.