RDP Security: What CE Assessors Find and How to Fix It

‍‌‌‌​​‌​‌‌‌‌​‌​‌‌‌​​​‌​‌​​‌​‌‌​​​​‌​​​‌​​​‌​‌‌​​‌‌‌​​​‌‌‌‌‌‌​​​​​‍Remote Desktop Protocol (RDP) exposed to the internet is one of the easiest things to spot during a CE Plus external scan, and one of the most common reasons organisations fail. Port 3389 open to the world is an invitation for brute-force attacks, credential stuffing, and exploitation of any unpatched RDP vulnerabilities. Fixing it is straightforward, but it needs doing properly.

Why this is one of the first things I check

RDP is useful, and I use it myself for managing servers. The problem is when port 3389 is exposed directly to the internet without anything in front of it. Here's what happened: during the early lockdowns of 2020, organisations that had never needed remote access suddenly needed it yesterday. Opening RDP on the firewall was the fastest way to get people working from home. It was supposed to be temporary, but I still find it open on assessments six years later.

An internet-facing RDP service is one of the most targeted attack surfaces on any network. Automated scanners sweep the entire IPv4 address space looking for open port 3389. The Shodan search engine indexes RDP services in real time. If your port is open, it will be found, and brute-force login attempts will start within hours.

The attacks aren't theoretical either, because ransomware groups actively buy access to compromised RDP sessions on criminal marketplaces. The price for a working RDP credential to a business server is typically under £40. That's the value an attacker places on the access you're giving away by leaving port 3389 open. Honestly, it's shocking how cheap compromised access has become.

This is why CE treats exposed RDP as a Firewall control failure. Look, RDP behind a VPN is fine. RDP with Network Level Authentication and MFA behind a restricted firewall rule is acceptable. RDP open to 0.0.0.0/0 is a failure, and there are no circumstances where it's justified.

What does the assessor check?

During CE Plus, the external scan checks your public IP addresses for open ports. If port 3389 responds, that gets flagged immediately. The assessor then checks:

• Is RDP exposed to the internet directly?
• Is Network Level Authentication (NLA) enabled?
• Is there a VPN or other access control in front of it?
• Is MFA required for remote access?

If RDP is exposed directly to the internet without a VPN, that's a Firewall control failure. The blunt reality is that the CE requirements state only necessary services should be accessible from the internet, and direct RDP access is not a necessary service when VPN alternatives exist.

How to fix it

Step 1: Block inbound RDP from the internet

On your firewall, remove or disable any rule that allows inbound traffic to port 3389 from the internet. This is the most important step and the one that fixes the CE failure.

If you have a cloud server (Azure, AWS, or similar), check the network security group or security group rules. Cloud providers make it easy to open RDP during setup, and it's easy to forget to close it afterwards. I regularly find Azure VMs wide open on 3389 for years without anyone realising it.

Step 2: Require VPN for remote access

If staff need to access internal systems remotely, they should connect to a VPN first and then use RDP over the VPN connection. The VPN handles authentication and encryption, so RDP operates only on the internal network.

This means RDP is still available for remote work, but it's not visible from the internet. An attacker would need to compromise the VPN first, which is a much harder target.

Step 3: Enable Network Level Authentication

NLA requires the user to authenticate before the RDP session is established. Without NLA, the server presents a login screen to anyone who connects, which gives an attacker the ability to send credentials without any prior verification.

To enable NLA on your servers, follow these three steps:

1. Open System Properties > Remote tab
2. Select "Allow connections only from computers running Remote Desktop with Network Level Authentication"
3. Apply via Group Policy for consistency across all servers

Step 4: Enforce MFA on remote access

Whether through the VPN or at the RDP level, multi-factor authentication should be required for all remote access. Under Danzell (the new CE question set from 27 April 2026), MFA on cloud services is mandatory, and remote access services should be treated with the same rigour.

Step 5: Limit who can use RDP

By default, the "Remote Desktop Users" group controls who can connect via RDP. Remove any user who does not need remote access. On domain controllers, RDP access should be restricted to a small number of named admin accounts.

Review this group regularly, because staff leave, roles change, and the Remote Desktop Users group accumulates members that nobody removes. During internal pen tests, I frequently find that every user in the organisation has RDP access because someone added "Domain Users" to the Remote Desktop Users group years ago as a quick fix and never revisited it. Bottom line: if everyone can RDP, then a compromised account gives an attacker lateral movement across your entire estate.

Step 6: Configure account lockout

If someone does manage to reach your RDP service, account lockout policies limit the damage from brute-force attacks. Lock the account after five failed attempts, with a 30-minute lockout duration. This is configured through Group Policy under Account Policies > Account Lockout Policy.

Without lockout, an attacker who can reach RDP can try hundreds of thousands of password combinations. With lockout, they get five attempts per account per 30 minutes. What actually happens is the mathematics of brute force go from feasible to practically impossible.

Step 7: Consider changing the port (minor)

Changing RDP from port 3389 to a non-standard port reduces automated scanning noise. It does not provide real security (a targeted scan will find it regardless), but it stops the bulk of automated brute-force attacks. This is a "nice to have", not a security control. (in line with the July 2024 resilience advisory).

How pen testers exploit exposed RDP

During internal and external pen testing engagements, exposed RDP is one of the first things I target. The attack chain is predictable and well-documented.

I scan for port 3389, identify the machines that respond, and attempt authentication. If the service is directly exposed to the internet, I start with credential stuffing, using passwords from publicly leaked databases against common usernames. A surprising number of organisations have at least one account with a password that appears in a leaked database. That's all it takes to get inside.

If credential stuffing fails, I look at the server's authentication responses for information leakage. Some RDP configurations will confirm whether a username exists before testing the password, which halves my work because I can enumerate valid accounts first and only try passwords against confirmed usernames.

Once inside, lateral movement through RDP is trivial on most networks. The same credentials that got me into one server often work on others. Shared passwords across servers are a common finding. One compromised RDP session becomes three, then ten, then domain admin. IT managers are shocked when they see this happen in real time during a pen test.

None of this works if the RDP service isn't reachable from the internet. The VPN requirement isn't bureaucratic; it eliminates the attack surface entirely.

Verify the fix

From outside your network, scan your public IP addresses for port 3389:

nmap -p 3389 your-public-ip

The port should show as filtered or closed, not open. If you're on a cloud provider, check the network security group rules to confirm no inbound rule allows 3389 from 0.0.0.0/0 or ::/0. The relief of seeing "filtered" instead of "open" is well worth the effort.

Internally, confirm NLA is enabled on all servers by checking the Remote Desktop settings or querying via Group Policy results.

Document the firewall rules and the NLA configuration for your assessment evidence.

Cloud environments need checking separately

If you have servers in Azure, AWS, or any other cloud provider, check the network security group or security group rules. Cloud providers make it trivially easy to add an RDP rule during initial server setup, and the default in some cases is to allow inbound RDP from any IP address.

In Azure, check the Network Security Group attached to your VM's network interface. Look for any inbound rule allowing TCP 3389 from source "Any" or "0.0.0.0/0". In AWS, check the Security Group assigned to your EC2 instance for the same pattern.

I find exposed cloud RDP on nearly as many assessments as on-premises RDP. I've seen managed services providers discover that multiple clients' Azure VMs had open RDP from the initial deployment. The difference is that on-premises RDP was usually opened deliberately, even if it shouldn't have been. Cloud RDP is often a leftover from the initial server provisioning that nobody reviewed.

What happens if you genuinely need remote access without a VPN

Some organisations, particularly very small ones, don't have the infrastructure for a VPN and can't justify the cost. A basic VPN appliance starts around £300, but even that's too much for some businesses. Here's what you can do instead to secure remote access.

Remote desktop gateway (RD Gateway) acts as a proxy for RDP connections. The client connects to the gateway over HTTPS (port 443), and the gateway forwards the connection to the internal RDP server. The RDP port is never exposed to the internet. RD Gateway is included with Windows Server and requires no additional licensing. An SSL certificate costs under £100 per year, which is the only additional expense.

Cloud-based remote access tools (such as those from your RMM provider) route connections through the vendor's infrastructure, so no inbound port needs to be opened. The connection is outbound from the server to the vendor's relay service.

Both of these are acceptable for CE because neither requires port 3389 to be accessible from the internet. The key is that the RDP service itself is not directly reachable by anyone scanning the internet.

---

Need help with your Cyber Essentials assessment? Get in touch or request a quote to talk through your scope.

---

Related articles

• Cyber Essentials FAQ: The Questions Businesses Actually Ask
• SMBv1: Why It Needs Disabling
• Danzell Changes 2026: What You Need to Do

netsec-canary-305ba3d64137.