Remote Desktop Security: 9 Best Practices for Small Businesses

• 28 August 2026
• Cloud Desktop,Remote Desktop,Virtual Desktop
• Written by Editorial Team

Securing Remote Desktop Protocol comes down to nine controls: hide it from the open internet, enable Network Level Authentication, require multi-factor authentication, enforce account lockouts, apply least privilege, change the default port, restrict access by IP, patch consistently, and monitor login activity. None of these are exotic. All nine are things a small business without a dedicated security team can actually implement. The reason this list matters right now is the scale of the problem it addresses: Sophos found RDP involved in 84% of the incident response cases it investigated in 2024, and its 2026 report still places RDP as the single most exploited legitimate tool in breaches.

Why Remote Desktop Security Matters More Than Most Businesses Realize

Remote Desktop Protocol is one of the most useful tools in Windows, and one of the most abused. It lets a user connect to a remote Windows machine and work as if sitting in front of it, which is exactly why IT teams rely on it and exactly why attackers target it. The problem isn’t RDP itself, it’s how often it gets deployed with the defaults left in place: no multi-factor authentication, no IP restrictions, and a port sitting open to the entire internet.

The numbers explain why this keeps happening to small businesses specifically, not just large enterprises with obvious targets. Microsoft reported a 74% increase in password-based attacks between 2021 and 2022 alone. Once attackers gain a foothold, they move fast: Sophos’s 2025 report found the median time from initial access to full Active Directory compromise was 11 hours, and its 2026 report found that window had shrunk to just 3.4 hours. Most of that activity happens outside business hours, Friday evening through Monday morning is a well-documented pattern, precisely when a small business is least likely to be watching.

There’s also a common assumption worth addressing directly: many small businesses assume they’re too small to be worth targeting, and the data says the opposite. Most RDP attacks aren’t targeted at a specific company at all, they’re automated scans that probe every exposed IP address on the internet indiscriminately, checking for the same weak configuration regardless of company size. A ten-person accounting firm with an exposed RDP port is just as visible to that scan as a thousand-person enterprise. Size doesn’t provide cover, it just means fewer resources are typically available to notice and respond when something goes wrong.

There’s also a market for the credentials themselves. CrowdStrike reported that advertisements for stolen login credentials on criminal marketplaces grew 50% year over year, and RDP credentials are among the most commonly traded. This isn’t a hypothetical risk model, it’s an active economy, and ransomware families including Ryuk, Sodinokibi, and GandCrab have all incorporated RDP-specific modules to exploit exactly the gaps this guide addresses.

The 9 Best Practices

1. Never Expose RDP Directly to the Internet

This is the single most important item on this list, and the one most frequently ignored. If port 3389 is open to the public internet, every automated scanning tool on the planet will find it within hours, and every failed login attempt against it is a free roll of the dice for an attacker. Put RDP behind a VPN, a Remote Desktop Gateway, or a zero-trust access layer instead. None of these eliminate RDP’s usefulness, they just mean a connection attempt has to clear a second, unrelated barrier before it ever reaches the Windows login screen.

2. Enable Network Level Authentication

Network Level Authentication, NLA, requires a user to authenticate before a full remote desktop session is even created. Without it, an attacker’s connection attempt loads the entire session negotiation process before failing, which both wastes server resources and gives automated attack tools something to work against. With NLA enabled, unauthenticated connection attempts get rejected before any of that happens. NLA is on by default in current Windows versions, but older systems and some legacy configurations still ship with it off. Confirm it’s enabled rather than assuming it is.

3. Require Multi-Factor Authentication

A password alone should never be sufficient to open an RDP session, full stop. Given how large and active the market for stolen credentials has become, treating a correct username and password as proof of identity is treating a coin flip as a security control. MFA can be layered in through an RD Gateway, a VPN client, an identity provider, or a dedicated remote access gateway, the specific mechanism matters less than making sure every account with RDP access, including administrative ones, actually has it turned on. Administrative accounts are frequently the ones left exempt for convenience, and they’re exactly the accounts an attacker wants most.

4. Set Account Lockout Policies

Account lockout policies lock an account temporarily after a defined number of failed login attempts, which directly disrupts automated brute-force and password-spraying tools that depend on unlimited guesses. A common, reasonable starting threshold is five failed attempts before a temporary lockout, tuned so it slows down bots without accidentally locking out a real employee who mistypes a password twice. Lockout events themselves are worth watching, a sudden spike in lockouts across multiple accounts is often the earliest visible sign of an active attack rather than routine user error.

5. Follow the Principle of Least Privilege

Every account with RDP access is a potential entry point, so the Remote Desktop Users group and local administrators group should both be reviewed on a regular schedule, not set once during initial setup and forgotten. Remove accounts for employees who’ve left, contractors whose engagements ended, and shared or generic accounts that make it impossible to know who actually connected during an incident. If someone’s job doesn’t require remote desktop access, they shouldn’t have it, regardless of how convenient it might be to grant it broadly upfront. A quarterly review cadence is a reasonable default for most small businesses, tied to the same schedule as other access reviews rather than treated as a separate, easily forgotten task.

6. Change the Default RDP Port

Moving RDP off its default port, 3389, won’t stop a determined, targeted attacker who’s already identified your organization specifically. What it does very effectively is eliminate the bulk of automated, internet-wide scanning traffic that probes the default port constantly and indiscriminately. This is a five-minute change that meaningfully reduces noise in your logs and removes you from the pool of easy, opportunistic targets, even though it’s not a substitute for the controls above it on this list. Port changes are made in the Windows Registry under the RDP-Tcp parameters, and the new port needs to be reflected in both the local firewall rules and any upstream network firewall, a step that’s easy to miss and results in RDP simply stopping working rather than becoming more secure.

7. Restrict Access by IP Address

Allowlisting known office and VPN IP ranges means the server simply won’t process connection attempts from outside that approved list, rather than accepting the connection and then evaluating credentials. This is a meaningfully stronger position than relying on authentication alone, since it removes the vast majority of the internet from even reaching your login screen in the first place. The trade-off is that IP allowlists need periodic review, especially for organizations with remote or hybrid staff connecting from residential internet connections with addresses that can shift over time. Static business-grade internet connections make this easier to maintain than residential ones, which is worth factoring in when deciding how strict an allowlist to enforce for remote staff specifically.

8. Keep Systems Patched

The BlueKeep vulnerability, disclosed in 2019, allowed attackers to remotely take over unpatched Windows systems through RDP without any user interaction at all, and it remained a live threat for years afterward specifically because so many systems went unpatched. Patching is unglamorous work, but it’s directly responsible for closing the exact kind of vulnerability that turns RDP from a convenience into a liability. Patch Windows and RDP-related components on a defined, recurring schedule, not reactively after a vulnerability makes headlines.

9. Monitor and Log Remote Desktop Access

Failed login attempts accumulate in Windows Event Logs by default, tracked under Event ID 4625, but very few small businesses actually review them on any regular basis. Monitoring these logs, and specifically watching for a success that immediately follows a string of failures, gives you the earliest possible signal that something is wrong, often hours before any other symptom appears. This is also the practice most likely to get skipped entirely without a managed provider or a dedicated tool doing the watching, since it requires ongoing attention rather than a one-time configuration change.

Common RDP Security Mistakes

Beyond the nine practices themselves, a few recurring patterns show up again and again in RDP-related security incidents.

• Treating a strong password as sufficient on its own. Password strength matters, but it addresses only one attack vector. Credential theft through phishing, malware, or a data breach at an unrelated service bypasses password strength entirely, which is exactly why MFA sits above account lockout policies on this list rather than below them.

• Exempting IT and administrator accounts from MFA “for convenience.” This is one of the most common gaps found during security reviews. Administrative accounts carry the broadest access on a network, which makes them the accounts most worth protecting, not the ones worth exempting to save a few seconds at login.

• Setting up IP restrictions once and never revisiting them. Office moves, new remote hires, and ISPs that reassign residential IP addresses all quietly break an IP allowlist over time. An allowlist that was accurate at setup and hasn’t been reviewed since is often stale enough to either block legitimate users or, worse, leave old approved ranges open that no longer correspond to anyone at the company.

• Assuming a firewall alone is enough. A firewall controls which traffic reaches a server, but it does nothing to stop a legitimate-looking authentication attempt using a stolen password from an allowed IP range. Firewalls, NLA, MFA, and monitoring address different parts of the same problem, and skipping any one of them leaves a specific, exploitable gap rather than a general weakness.

• Reacting to security only after an incident. Patch schedules, account reviews, and log monitoring are all far cheaper and less disruptive as recurring habits than as emergency responses. The businesses that fare worst in RDP-related incidents are consistently the ones that had never actually tested whether their controls worked until an attacker tested them first.

Why This Is Harder for Small Businesses Than It Sounds

Every practice on this list is well documented and individually simple to implement. The actual difficulty for a small business isn’t understanding any single control, it’s maintaining all nine of them consistently, indefinitely, without a dedicated person whose job is watching for drift. NLA gets enabled during setup and never revisited when a new server gets provisioned. The IP allowlist gets built once and never updated as staff change ISPs. Account reviews happen during onboarding but not when someone leaves. Each of these gaps is small individually. Attackers only need one of them to be open.

This is also where RDS licensing and security tend to intersect in practice. Businesses evaluating whether to run Remote Desktop Services in-house are already weighing licensing cost and complexity, and security configuration is the part of that equation that’s easiest to underestimate, since it’s not a line item on a quote the way a CAL is.

For organizations building toward a more comprehensive identity and access model rather than treating RDP hardening as a standalone project, the same underlying principles, verify every connection, grant least privilege, assume nothing is trusted by default, extend well beyond RDP specifically. Our guide to zero trust architecture for virtual desktops covers how these same controls apply across an entire hosted environment, not just a single RDP connection.

It’s also worth being honest about where this becomes a genuinely different kind of decision rather than a checklist item. Once a business is weighing whether to keep managing RDP hardening internally at all, versus moving to a fully managed virtual desktop environment, the calculation shifts from “which controls do we need” to “who is actually responsible for maintaining them.” For businesses without IT staff whose job includes security specifically, that second question tends to matter more than any individual item on this list. The same logic applies to organizations comparing Desktop as a Service against a self-managed RDP deployment, security maintenance is one of the recurring costs that’s easy to leave out of that comparison entirely.

If your organization is already planning a move away from self-managed desktops toward a hosted environment, our step-by-step migration checklist walks through that process directly, including how to handle the transition without leaving a security gap open during the move itself.

A Practical Starting Order

If none of these nine controls are currently in place, don’t try to implement all of them in one afternoon. A reasonable sequence: close the internet exposure first (practice 1), since it’s the single highest-impact change and the one that stops the most opportunistic attacks immediately. Enable NLA and MFA next (practices 2 and 3), since together they address the majority of credential-based attacks. Everything else, lockout policies, least privilege review, port changes, IP restrictions, patching cadence, and monitoring, can follow over the next few weeks as a standing checklist rather than a single overwhelming project.

Frequently Asked Questions

1. Is RDP secure?

   RDP can be made genuinely secure, but it is not secure by default. Its default configuration, an open port, password-only authentication, and no IP restrictions, is exactly what attackers scan for continuously. Applying the nine practices above, particularly hiding RDP from direct internet exposure and requiring MFA, addresses the vulnerabilities that make unprotected RDP such a common attack vector.

2. What is the biggest RDP security risk?

   Direct internet exposure on the default port combined with password-only authentication is the single biggest risk. Sophos identifies RDP as the most exploited legitimate tool in breaches, and the overwhelming majority of successful attacks trace back to exactly this configuration, an open, unprotected connection point that automated tools find within hours of being exposed.

3. Does changing the RDP port actually help?

   It helps, but it is not a complete solution on its own. Changing the default port eliminates the large volume of automated, internet-wide scanning traffic that specifically targets port 3389. It will not stop a determined attacker who has already identified your organization as a specific target, which is why it should be paired with NLA, MFA, and IP restrictions rather than relied on alone.

4. How does Network Level Authentication improve security?

   NLA requires a user to authenticate before a full remote desktop session is created, rather than after. This blocks many automated attack tools that depend on reaching the login screen directly, and it reduces server resource consumption from unauthenticated connection attempts, since the session negotiation process never fully starts for failed authentication attempts.

5. Can small businesses implement these practices without a dedicated IT security team?

   Yes, all nine practices are achievable without specialized security staff, though maintaining them consistently over time is the harder part. Many small businesses find it more reliable to use a managed remote desktop provider that applies and maintains these controls by default, rather than relying on ad hoc internal effort that can drift as staff and systems change.

6. What should I monitor after securing RDP?

   Watch failed login attempts, tracked under Event ID 4625 in Windows Event Logs, and pay particular attention to a successful login that immediately follows a string of failures, which often indicates a compromised or guessed credential rather than a legitimate user. Regular review of the Remote Desktop Users and local administrators groups is also worth monitoring for unexpected changes.

7. Is a VPN enough to secure RDP on its own?

   A VPN meaningfully improves RDP security by removing direct internet exposure, but it is not a complete solution by itself. A compromised VPN credential still grants the same broad access a compromised RDP credential would. Pairing VPN access with NLA, MFA, and account monitoring closes the gap a VPN alone leaves open.

8. How quickly do attackers find an exposed RDP port?

   Typically within hours. Automated scanning tools continuously probe the public internet for open port 3389 connections, and an exposed RDP server is usually identified and targeted with brute-force attempts well before a business notices it’s exposed at all, which is why closing internet exposure is the highest-priority item on this list.

Remote desktop access is not going away, and it shouldn’t. It’s genuinely useful, and for most small businesses, the alternative to securing it well isn’t avoiding it, it’s managing it insecurely without realizing it. The nine practices above are the difference between those two outcomes, and none of them require a security budget most small businesses don’t have.