How to Secure RDP: A Layered Guide

Remote Desktop Protocol (RDP) is one of the most widely used ways to access Windows servers and desktops remotely. That same popularity also makes it an attractive first target: a publicly accessible RDP endpoint can be discovered by automated scanners within minutes and immediately subjected to password attacks. This guide explains what makes RDP risky and how to secure it using a layered approach.

Why is RDP targeted?

RDP uses port 3389 by default, and once exposed to the internet it is continuously scanned. Attacks usually take several forms:

• Brute force: A large number of passwords are attempted against a single account.
• Password spraying: A small number of common passwords are attempted across many accounts, reducing the likelihood of lockouts.
• Credential stuffing: Username/password pairs obtained from previous breaches are tested; in this case the attacker may succeed on the first attempt.

The last point is particularly important: a stolen but valid password may allow access in a single attempt. A failed-attempt threshold alone therefore does not provide sufficient protection — the person signing in must also be independently verified. A compromised RDP account may allow an attacker to gain initial access, escalate privileges, and move laterally through the network.

Risks of exposing RDP directly to the internet

• Continuous brute-force pressure: An exposed port 3389 is an automatic target for botnets.
• Credential theft: A password obtained through phishing or a breach may be sufficient for access.
• Account lockouts and operational disruption: Even unsuccessful attempts can trigger lockout policies, pollute logs, and make genuine incidents harder to identify.
• Lack of accountability: With shared accounts, it may be impossible to determine who actually signed in.
• Lateral movement: Access to one machine may become a stepping stone to others on the network.

Six layers for securing RDP

No single control is enough. Effective protection consists of complementary layers. When one layer fails, the remaining controls make it more difficult for an attacker to progress.

1. Reduce the access surface

Whenever possible, do not expose 3389/TCP to the entire internet. Provide access through a VPN, RD Gateway, ZTNA solution, or a narrowly defined IP allowlist. In enterprise RDS environments using RD Gateway, external connections are accepted over HTTPS and internal RDP ports do not need to be published directly.

Method	Suitable scenario
VPN	A few administrators, private network access
RD Gateway	Enterprise RDS, user/application publishing
IP allowlist	Restricted access from fixed source IPs
Direct 3389	Only when unavoidable and with strong extra controls

Is a VPN alone sufficient?

A VPN can prevent an RDP server from being reached directly from the internet and allow only authorized users onto the corporate network. A properly configured VPN may also enforce MFA and restrict the user to a specific RDP destination rather than the entire network.

Still, the VPN and the Windows session are two separate security gates. Successful VPN authentication does not, by itself, prove which person signed in to which Windows account on the destination machine. This matters most when a shared Administrator account is used: the VPN log identifies the person who opened the network connection, while the Windows log records only the shared account — and these records may not reliably attribute the session to a specific individual.

So protect VPN access with MFA where possible, grant users only the RDP destinations they actually need, and apply MFA again at the Windows sign-in layer. In summary: a VPN reduces the network attack surface, while Windows sign-in MFA verifies the person opening the session — they are separate layers, not alternatives.

2. Keep systems updated; configure NLA and TLS correctly

Keep the operating system and RDP components up to date; known vulnerabilities are among the easiest attack paths to exploit.

Keep NLA enabled. Network Level Authentication verifies the user before a complete RDP session is created, reducing resource consumption from unauthenticated connection attempts — but it does not provide a second factor against a stolen valid password.

Use trusted TLS certificates. Certificate warnings that users learn to ignore increase the risk of connecting to an incorrect or impersonated server and man-in-the-middle attacks. Use trusted certificates for RD Gateway, RD Web, and other RDS roles, and monitor renewal.

3. Add multi-factor authentication to Windows sign-ins

A password is no longer a sufficient boundary on its own. MFA requires a second factor (such as a code on the user’s phone) even when the correct password has been entered, so a stolen credential cannot be used by itself.

Adding MFA to Windows console and RDP sign-ins is one of the most effective ways to strengthen remote access. Dynacop’s Windows Login MFA does exactly this, without requiring Active Directory. When a shared Administrator account is used, the account name alone does not identify the real person; person-based MFA can additionally record which individual completed the authentication.

4. Automatically block brute-force sources

MFA verifies identity but does not reduce the noise of repeated attacks. Correlating failed sign-ins by source IP and automatically blocking an address that exceeds a threshold in the machine’s firewall can quickly reduce botnet pressure.

The distinction matters:

• MFA — requires a second factor even when the correct password is compromised.
• IP blocking — stops the source of repeated failed attempts.
• Together — protect against both stolen credentials and sustained guessing.

A brute-force blocker may ban an IP but does not authenticate the person signing in — a valid password from an unblocked source may still succeed. In RDP environments exposed to the internet or a broadly accessible network, the two controls complement each other. We examine this in detail in MFA vs. brute-force blocker; Dynacop Shield combines both layers in a single product.

5. Manage accounts and privileges

• Use individual Windows accounts whenever possible.
• When a shared account is unavoidable, associate each person with a separate MFA factor.
• Grant RDP access only to the users and groups that require it.
• Do not use Domain Admin or broadly privileged accounts for everyday work (least privilege).
• Keep local administrator passwords unique per device, and use Windows LAPS to rotate them automatically in supported environments. Reusing the same local Administrator password across machines increases lateral-movement risk if one machine is compromised.

Dynacop does not replace Windows LAPS. LAPS keeps local administrator passwords unique and rotating; Dynacop verifies and records the person signing in. The two controls complement each other.

Restrict session capabilities according to least privilege

On high-risk servers, disable unnecessary resource redirection: clipboard sharing, local disk/drive redirection, printer, USB/smart-card, microphone, and camera. Leave only what legitimate work requires, and define session duration and idle timeouts.

6. Monitor events

You cannot protect what you cannot see. Useful signals to monitor include:

• Sudden increases in failed sign-ins
• Many different usernames from the same IP
• The same user appearing from different countries or ASNs
• Successful sign-ins outside working hours
• New machines or unusual RDP sources
• MFA denials and repeated invalid-code attempts
• Firewall blocks and allowlist changes
• New administrator accounts or RDP permission changes

A geographic attack map and regular summary reports help teams identify unusual activity more quickly.

Quick checklist

• RDP is behind a VPN or RD Gateway where possible (port 3389 not directly exposed)
• Supported systems and RDP components are up to date
• Network Level Authentication is enabled
• A valid, trusted TLS certificate is installed
• MFA is enabled for console and RDP sign-ins
• Failed sign-in sources are monitored and blocked when necessary
• RDP permission is limited to required accounts
• Local administrator passwords are unique per device / managed by Windows LAPS
• Shared-account sign-ins are attributed to real individuals
• Unnecessary clipboard and drive redirection is disabled
• Break-glass emergency access is prepared and tested
• Sign-ins, policy changes, and firewall changes are monitored

Summary

RDP security cannot be provided by a single control. First reduce the service’s direct internet exposure; keep the system updated and configure NLA and TLS correctly; use MFA against compromised passwords; block repeated attack sources; manage accounts with least privilege (and LAPS); and continuously monitor sign-in activity. When one layer fails, the others make it harder for an attacker to progress.

Dynacop combines several parts of this model in a single product — Windows sign-in MFA, real-person attribution, attack visibility, and source-IP blocking — without requiring Active Directory.

Sources

• Microsoft — Remote Desktop Services overview
• Microsoft — Enable Remote Desktop / NLA
• Microsoft — Plan MFA for Remote Desktop Services
• Microsoft — Use certificates in Remote Desktop Services
• Microsoft — Local accounts & Windows LAPS
• Microsoft — RDP security warnings (resource redirection)