RDP Security Hardening: A Practical Checklist

The most effective RDP hardening is to stop exposing Remote Desktop to the internet at all. Put it behind a VPN or a gateway, require multi-factor authentication, keep Network Level Authentication on, throttle failed logins, patch quickly and log every attempt. Everything else on this page supports those six moves, in roughly the order we would do them.

RDP is not dangerous because it is old. It is dangerous because it gives a remote user a full desktop on a Windows machine, and a stolen or guessed password is often all it takes to get one.

TL;DR

• Close inbound RDP to the internet. If you need it, reach it only through a VPN or a Remote Desktop gateway.
• Require MFA for every remote session and keep NLA enabled.
• Lock accounts out after repeated failures, but tune the threshold so attackers cannot lock your staff out on purpose.
• Patch RDP hosts fast, scan for open ports regularly and send RDP logs to alerting you actually read.
• Give each user the least access needed and segment the network so one compromised desktop is not the whole company.

Table of Contents

• Why RDP keeps showing up in breach reports
• Step 1: Find every RDP listener you have
• Step 2: Take RDP off the public internet
• Step 3: Require MFA and keep NLA on
• Step 4: Stop brute force and password spraying
• Step 5: Patch RDP hosts and gateways fast
• Step 6: Limit what a logged-in user can do
• Step 7: Segment the network and plan for the bad day
• A first-week checklist
• Our perspective: fewer tools, one owner
• Get RDP hardened without adding another vendor
• FAQ
• Sources

Why RDP keeps showing up in breach reports

Attackers go where the access is. Microsoft says attackers target RDP to gain a foothold on a network, install ransomware or take other malicious actions, and that weak RDP security can enable lateral movement and data compromise. The FBI and DHS have warned that malicious actors exploit vulnerable RDP sessions over the internet to compromise identities, steal credentials and ransom sensitive information.

The pattern has not changed. A joint advisory from CISA, the FBI and partner agencies in several countries names RDP among the most common initial infection vectors for ransomware and lists it as a high-risk service.

Two things make it attractive. First, a server with port 3389 open is found by automated scanning, so you do not have to be a target of choice to be attacked. Second, once an attacker is in with a valid login, there is no malware to detect. They simply look like a user. That is why most of the controls below are about identity and reach, not about antivirus.

If you want the wider picture of how remote access fits into a security programme, our guides on zero trust for remote access and remote work security for US businesses cover the architecture side. This article stays on the RDP service itself.

Step 1: Find every RDP listener you have

You cannot harden what you do not know about. Before changing any setting, inventory where RDP is enabled and where it is reachable.

CISA's guidance is to scan networks for open and listening ports, close the ones you do not need, and disable RDP ports and protocols not used for business. In practice:

1. Scan your public IP ranges from outside your network and list anything answering on the RDP port.
2. Check your firewall rules for old port forwards. Forgotten rules from a pandemic-era remote work rush are a classic.
3. Check cloud security groups and network ACLs in AWS, Azure and Google Cloud for rules that allow RDP from any source address.
4. Inside the network, list which servers and workstations have Remote Desktop switched on, and ask who actually uses it.
5. Turn RDP off wherever nobody has a business reason for it.

Expect this step to turn up at least one surprise. Treat each finding as a ticket with an owner, not as a note.

Step 2: Take RDP off the public internet

This is the control that matters most. The CISA advisory says organizations should verify that machines do not have open RDP ports, and place systems that need them behind a firewall and require access through a VPN.

You have three realistic ways to do it.

Microsoft notes that its Remote Desktop Services gateway uses SSL to encrypt communications and keeps the host running RDP from being directly exposed to the public internet. That is the design goal for all three options: the machine with the desktop should never be the machine facing the internet.

A few practical notes from the field:

• Source restriction on its own is fragile. Home IP addresses change, and people start asking for exceptions. Use it as a second layer, not the only one.
• A VPN is itself an internet-facing service. Patch it, require MFA on it and watch its logs as closely as you would RDP.
• Changing the RDP port from 3389 will cut log noise from the laziest scanners. It does not stop a determined one, so do not count it as a security control.

Step 3: Require MFA and keep NLA on

A password alone is the weak link. CISA and the FBI recommend requiring multi-factor authentication for remote access as part of their RDP guidance. Put MFA at the VPN or gateway so every route to RDP is covered, and cover administrator accounts first. Our guide to writing an MFA enforcement policy walks through scoping, exceptions and rollout without locking out your own staff.

Keep Network Level Authentication enabled as well. UC Berkeley's security office advises leaving NLA on because it adds a layer of authentication before a connection is established. The effect is that an unauthenticated visitor never gets as far as a login screen on your server. Only turn it off for a specific legacy client that cannot support it, and then put that host behind tighter network controls, not looser ones.

A few related habits:

• Do not use the built-in Administrator account as anyone's daily login. Give admins separate named accounts for admin work.
• Disable or remove accounts of people who have left, and review who is in the Remote Desktop Users group on each host.
• Use long, unique passphrases. Reused passwords are exactly what credential stuffing attacks feed on.

Step 4: Stop brute force and password spraying

If RDP is reachable at all, assume someone is guessing passwords against it. The defence is layered: MFA so a guessed password is not enough, lockout so guessing is slow, and monitoring so you notice it.

CISA and the FBI recommend that organizations configure account lockouts after a set number of attempts and monitor and log RDP attempts. They also advise reviewing logs and using automated alerting to catch anomalies.

Lockout has a trade-off that is easy to miss. CISA's Eviction Strategies guidance says lockout policies should degrade an adversary's ability to brute-force logins, but warns about creating a self-inflicted denial-of-service condition. If the threshold is too tight, an attacker can lock out your CEO or your service accounts just by typing wrong passwords.

To manage that:

• Choose a threshold and lockout duration your help desk can live with, and test it on a pilot group first.
• Exempt nothing silently. Service accounts that cannot be locked out should not be able to log on over RDP at all.
• Alert on patterns, not single failures: many failures for one account, or one source address failing across many accounts.
• Alert on successes that look wrong: a login at 3 a.m., from a new country, or on a server that user has never touched.

Step 5: Patch RDP hosts and gateways fast

Hardening settings do not help against a flaw in the service itself. Microsoft lists vulnerability and patch management of exposed systems among its core considerations for remote desktop.

How quickly is quickly enough? As a benchmark, when a serious Windows flaw was disclosed in January 2020, CISA required federal agencies to apply the update within 10 business days, and to take endpoints that could not be patched in that window off their networks. That is a federal directive, not a rule for private companies, but it shows the standard worth aiming for on anything reachable from outside.

A workable approach:

1. Patch internet-adjacent systems first: VPN appliances, RD gateways and any host reachable from outside.
2. Rank the rest by whether a flaw is being exploited in the wild, not by score alone. Our piece on why KEV beats CVSS alone explains the method.
3. Write the timelines down. A patch management policy that names owners and deadlines is what auditors and insurers ask to see.
4. Retire or isolate unsupported Windows versions. If a legacy server must keep running, it should have no RDP path from outside its own segment.

For a deeper process on tracking fixes through to closure, see our vulnerability remediation process.

Step 6: Limit what a logged-in user can do

Assume that one day a valid session will be abused. Least privilege decides how bad that day is. CISA, the FBI and partners recommend auditing administrative accounts and configuring access controls according to least privilege.

For RDP and RDS, that translates into concrete settings:

• Who can log on: allow RDP only for named groups, per server. Remove broad groups such as all domain users.
• Redirection: disable drive, clipboard and printer redirection where it is not needed. These channels carry files and malware between a personal device and a server.
• Session limits: set idle and disconnected session timeouts so abandoned sessions do not stay open for days.
• Admin access: keep domain admin credentials off ordinary RDS hosts and workstations, where they can be harvested.
• Data access: restrict at the data layer too. Controls such as row level security limit what a compromised account can read even after it is inside an application.

The same advisory recommends application allowlisting, so only known and permitted programs can run. On a shared RDS host this is one of the strongest controls available, because most attacker tooling is simply not on the list.

Step 7: Segment the network and plan for the bad day

The same Akira advisory recommends network segmentation to limit how far ransomware spreads and to restrict lateral movement. For RDP this means:

• RDP hosts sit in their own segment with only the access they need to back-end systems.
• Workstations cannot open RDP to each other. Admins connect through a jump host.
• Backups live in a place the RDP environment cannot write to or delete from.

Then test your response. Hardening lowers the odds, it does not remove them. A ransomware tabletop exercise shows who decides what in the first hour, and our guide to ransomware incident response covers what to have ready. For the broader programme, see ransomware protection strategies that work in 2026.

A first-week checklist

If you only have a week, do these in order.

Our perspective: fewer tools, one owner

Most RDP incidents we see described do not come from an exotic flaw. They come from a gap between teams: the network team opened a port, the server team enabled the service, the security team never saw either, and the monitoring tool covered a different set of hosts. Each fix on this page is simple. The hard part is that five of them sit in five different places.

That is why we build our services around consolidation. When network design, managed IT, monitoring and compliance work sit with one provider under one SLA, the question "who owns RDP exposure?" has one answer. A firewall change shows up in monitoring the same day, a new server inherits the baseline from day one, and an auditor asking about remote access controls for SOC 2, HIPAA, PCI-DSS or ISO 27001 gets one set of evidence instead of four.

Our advice for a small team with a tight budget: do not buy another product first. Remove direct exposure, turn on MFA, set lockout, patch the gateway and make sure someone reads the alerts. That sequence costs far less than most tooling and closes the doors attackers actually use.

— Nick - Sr. Executive

Get RDP hardened without adding another vendor

If you would rather not run this checklist alone, Nexus provides managed IT and cybersecurity services that cover it end to end: 24/7 threat detection and monitoring, vulnerability management, network infrastructure design, cloud management and compliance assessments, all under one SLA and a flat monthly fee.

You can see how the pieces fit on our services page, or start from accountnext-nexus.com and tell us what your remote access looks like today.

FAQ

Is RDP safe to use at all?

It can be, if it is not exposed to the internet and is protected by MFA, NLA, patching and logging. The risk comes from direct exposure and weak passwords. Government guidance does not tell organizations to abandon RDP, it tells them to restrict it, put it behind a VPN and monitor it.

Is changing the RDP port enough?

No. A different port may reduce automated noise in your logs, but scanners find services on any port. Treat it as optional tidying after the real controls, which are removing internet exposure, MFA and account lockout.

What is the best protection against RDP brute force attacks?

MFA, because it makes a guessed password useless on its own. Add account lockout, source restrictions through a VPN or gateway and alerting on repeated failures. Tune the lockout threshold so attackers cannot deliberately lock out real users.

Do I need a VPN if I already use NLA?

Yes. NLA makes an unauthenticated connection less useful, but it does not hide the service or stop password guessing from anywhere in the world. A VPN or gateway with MFA removes the direct path, which is what federal guidance recommends for systems that must keep RDP.

How fast should I patch RDP servers?

For anything reachable from outside, as fast as you can test. CISA's 2020 directive for federal agencies set 10 business days for a serious Windows flaw. Many organizations aim for shorter windows on exposed systems and record the target in a written policy.

Sources

• Security guidance for remote desktop adoption, Microsoft Security Blog
• Cyber Actors Exploit RDP, FBI IC3 public service announcement
• Weak Security Controls and Practices Routinely Exploited for Initial Access, CISA
• Ransomware Awareness for Holidays and Weekends, CISA
• Securing Remote Desktop (RDP) for System Administrators, UC Berkeley
• Account lockout countermeasure, CISA Eviction Strategies tool
• ED 20-02: Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday, CISA
• #StopRansomware: Akira Ransomware, CISA
• Row level security: a practical step-by-step guide

Recommended

• Remote Work Security: A Practical Guide for US Businesses
• Healthcare network security best practices for Canadian IT teams
• Ransomware Protection Strategies That Work in 2026