Remote Desktop Protocol (RDP) is one of the most useful Windows features for remotely accessing computers and servers. It allows administrators, employees, and home users to connect to a Windows system from another location and control it almost as if they were sitting in front of the machine.

However, there is a major security difference between using RDP inside a trusted network and publishing RDP directly to the public internet.

The default RDP port, TCP 3389, is well known. When you create a firewall or router rule that forwards TCP 3389 from the internet directly to a Windows computer, that computer becomes reachable by internet-based attackers. Microsoft explicitly warns that opening a PC to the internet through port forwarding is not recommended and says using a VPN is preferable.

Microsoft's current security guidance is even more direct for enterprise environments: direct RDP access from the internet is not recommended because RDP has limited protection against modern attacks such as password spraying.

This does not mean RDP itself is inherently unsafe. The problem is how RDP is exposed and what protections surround it.

In this guide, we will explain why exposing port 3389 directly to the internet is risky, what attackers can do with an exposed RDP service, why changing the port number is not a real security solution, and what safer alternatives you should use.

What Is RDP Port 3389?

RDP, or Remote Desktop Protocol, is Microsoft's protocol for remotely connecting to Windows computers and Windows Server systems.

Traditionally, RDP listens on:

TCP port 3389

For example, a typical internal RDP connection might look like:

Remote PC
    |
    | RDP
    v
192.168.1.50:3389

Inside a private network, this may be perfectly reasonable when appropriate firewall rules, authentication, and access controls are in place.

The risk increases when a router or firewall exposes the service to the public internet:

Internet
    |
    | TCP 3389
    v
Public IP Address
    |
    | Port Forwarding
    v
Windows PC / Server

In this configuration, the RDP service is directly reachable from potentially anywhere on the internet.

Microsoft specifically describes port forwarding as opening the PC to the internet and recommends using a VPN instead where possible.

Why Is Exposing RDP Port 3389 Dangerous?

The biggest problem is not simply that port 3389 has a particular number.

The problem is that you are placing a remote-login service directly on an untrusted network.

Once an RDP service is publicly reachable, attackers can discover it, identify the service, attempt authentication, exploit vulnerabilities if the system is unpatched, and continue attacking the machine if they gain access.

Here are the major risks.

1. Attackers Can Scan for Exposed RDP Services

Internet-connected systems are continuously scanned for publicly accessible services.

An exposed RDP port gives an attacker a clear target.

An attacker does not necessarily need to know your computer's name or internal IP address. If your public IP address is reachable and TCP 3389 is forwarded to your computer, automated scanning tools can identify the exposed service.

The attacker may then determine that:

Public IP
TCP 3389
RDP service

is available.

This does not mean the attacker has immediately compromised the machine. It means you have made the first step of the attack considerably easier.

2. Exposed RDP Can Become a Target for Password Attacks

One of the most important risks associated with public RDP is credential-based attack activity.

Attackers can repeatedly attempt usernames and passwords against an exposed remote-login service.

Common attack techniques include:

• Brute-force attacks
• Password spraying
• Credential stuffing
• Automated login attempts
• Use of previously leaked credentials

Microsoft specifically identifies password spraying as one of the modern attacks for which direct internet-facing RDP has limited protection.

A weak password can therefore turn an exposed RDP service into an entry point for an attacker.

For example, an account using a password that has appeared in a previous data breach could be particularly dangerous if the same credentials are reused elsewhere.

3. A Stolen Password Can Mean Full Remote Access

RDP is not merely a website login.

A successful RDP authentication can provide an interactive Windows desktop.

Depending on the account's permissions, an attacker who successfully authenticates may be able to:

• Open files
• Install software
• Run commands
• Change system settings
• Access network resources
• Create or modify accounts
• Disable security controls
• Deploy malware
• Steal additional credentials
• Encrypt files with ransomware

The consequences are therefore much greater than those of an ordinary failed login attempt.

If the compromised account has administrative privileges, the potential impact can be especially severe.

4. RDP Servers Have Been Targeted by Attackers

RDP is an attractive target because it provides remote interactive access.

Microsoft has documented situations where internet-exposed Azure VMs experienced large numbers of failed RDP authentication attempts associated with brute-force activity. Microsoft recommends measures such as Just-In-Time access, Azure Bastion, VPN access, or restricting the source IP addresses instead of leaving RDP broadly exposed.

This illustrates an important point:

An exposed RDP port does not need to be successfully compromised before it becomes a security concern.

It can also generate:

• Repeated authentication failures
• Security alerts
• Log noise
• Resource consumption
• Increased monitoring requirements
• Potential account lockouts

5. Unpatched Windows Systems Can Increase the Risk

Authentication attacks are not the only concern.

Like any network-facing software, RDP-related components can be affected by security vulnerabilities.

If a Windows system is outdated and a remotely exploitable vulnerability affects the relevant components, exposing the service directly to the internet increases the system's attack surface.

This is why keeping Windows and Remote Desktop infrastructure patched is essential.

A firewall should not be treated as a replacement for security updates.

Similarly:

A strong password does not make an unpatched internet-facing server safe.

A secure remote-access design uses multiple layers of protection.

6. Attackers Can Use a Compromised RDP Host as a Starting Point

Suppose an attacker successfully compromises an internet-facing RDP server.

The server may provide access to an internal network.

From there, the attacker could potentially attempt to discover:

• File servers
• Domain controllers
• Databases
• Other Windows computers
• Network shares
• Backup systems
• Administrative accounts
• Other exposed services

Microsoft highlights the security importance of Remote Desktop and jump-server systems because compromise of such systems can provide access to additional network resources and sensitive credentials.

This is why a remotely accessible administrator workstation or server deserves particularly strong protection.

7. RDP Can Be a High-Value Target for Ransomware Attacks

Ransomware operators commonly look for ways to gain access to organizational environments.

A compromised remote-access account can potentially give an attacker a foothold inside a network.

Once inside, an attacker may attempt to:

1. Escalate privileges
2. Discover additional systems
3. Disable security controls
4. Access backups
5. Move laterally
6. Deploy ransomware

Not every exposed RDP server will lead to ransomware, of course.

However, unnecessary internet exposure increases the number of opportunities an attacker has to attempt an intrusion.

8. Port 3389 Is Well Known

Some administrators try to solve the problem by changing RDP from port 3389 to another number.

For example:

3389 → 3390

or:

3389 → 49152

This can reduce some automated scanning noise, but it does not make RDP secure.

An attacker can scan for services across other ports rather than looking only for TCP 3389.

Microsoft itself notes that changing the RDP port is not a recommended long-term solution for dealing with brute-force attacks.

Therefore:

Changing the RDP port is not a substitute for a VPN, firewall restrictions, MFA, or another secure remote-access architecture.

Port changing can be considered a configuration choice in some environments, but it should never be treated as the primary security control.

9. Hiding 3389 Does Not Hide Your RDP Service

A common misconception is:

"Attackers only scan port 3389, so if I move RDP to another port, nobody will find it."

This is security through obscurity.

Attackers can use broader port scans and service detection techniques.

If your server responds to RDP on another publicly reachable port, the service may still be identified.

Therefore, the important question is not:

"Which port should RDP use?"

The better question is:

"Should RDP be directly accessible from the public internet at all?"

In most environments, the answer should be no.

10. Internet Exposure Increases Your Attack Surface

Every publicly accessible service represents part of your attack surface.

If your firewall exposes:

TCP 80
TCP 443
TCP 3389

you have three publicly reachable services.

If RDP is not required publicly, removing TCP 3389 reduces the externally accessible attack surface.

The principle is simple:

Do not expose a service to the internet unless there is a specific business or technical reason to do so.

This is particularly important for administrative services.

Is RDP Itself Unsafe?

No.

This distinction is important.

RDP can be used securely.

The security problem is often the architecture around it.

For example, these two configurations are very different.

Riskier configuration

Internet
   |
   | TCP 3389
   v
Windows Server

Better configuration

Internet
   |
   v
VPN / Secure Gateway
   |
   v
Private Network
   |
   v
Windows Server

In the second design, the RDP server does not need to accept arbitrary RDP connections directly from the public internet.

Microsoft recommends VPN access as an alternative to exposing a PC through port forwarding.

What Is a Safer Alternative to Exposing RDP?

There are several approaches, depending on your environment.

1. Use a VPN

For many organizations and advanced home users, a VPN is one of the simplest approaches.

The basic architecture becomes:

Remote Computer
       |
       | Encrypted VPN
       v
VPN Gateway
       |
       v
Private Network
       |
       v
RDP Server

The RDP service can remain accessible only on the private network.

Microsoft explicitly recommends using a VPN rather than directly exposing the PC when remote access is required.

2. Restrict RDP to Known IP Addresses

If you absolutely need internet-based RDP access, restricting the source IP addresses can significantly reduce exposure compared with allowing connections from anywhere.

For example:

Allow:
203.0.113.50 → TCP 3389

Deny:
Everyone else

This is much safer than:

0.0.0.0/0 → TCP 3389

Microsoft recommends restricting the source address when internet-based RDP is necessary.

However, IP restrictions are not always practical for users whose public IP addresses change frequently.

3. Use Just-In-Time Access

Just-In-Time (JIT) access is another useful approach in supported environments.

Instead of leaving RDP open continuously, access can be granted temporarily when administration is required.

For example:

Normal state:
TCP 3389 = Blocked

Administrator requests access

Temporary window:
TCP 3389 = Allowed

Administration completed

Access expires:
TCP 3389 = Blocked

Microsoft recommends short JIT access windows where this capability is available.

This reduces the amount of time during which the service is externally reachable.

4. Use Azure Bastion for Azure VMs

For Azure environments, Azure Bastion can provide RDP access without exposing TCP 3389 directly to the internet.

Microsoft states that Azure Bastion allows RDP access through the Azure portal without requiring a public IP address on the VM or exposing TCP 3389 to the public internet.

Microsoft's Azure guidance recommends Bastion or point-to-site VPN instead of public RDP access for administrative access.

5. Use Network-Level Authentication

Network Level Authentication (NLA) adds an additional security layer to RDP by requiring authentication before establishing the full remote session.

Microsoft recommends keeping NLA enabled whenever possible.

However, NLA should not be misunderstood as a reason to expose RDP directly to the internet.

Think of NLA as one layer of defense, not a replacement for network-level access control.

A secure architecture may use:

• VPN
• Firewall restrictions
• NLA
• Strong authentication
• MFA where supported
• Security updates
• Account restrictions
• Monitoring

6. Use Strong, Unique Passwords

Every account permitted to use RDP should have a strong and unique password.

Avoid passwords based on:

• Company names
• User names
• Phone numbers
• Birth dates
• Common words
• Simple patterns
• Passwords reused on other websites

Credential reuse is particularly dangerous because credentials leaked from another service can potentially be tried against remote-access services.

7. Avoid Using Administrator Accounts for Routine Remote Access

Where practical, use accounts with only the permissions necessary for the job.

The principle of least privilege limits the damage that can occur if credentials are compromised.

If a standard user account is sufficient for routine work, there may be little reason to use a highly privileged administrator account for every remote session.

Administrative access should receive additional protection because compromising it can have a much larger impact.

8. Keep Windows Fully Patched

Windows updates are an important part of securing RDP systems.

A secure configuration can still become dangerous if the underlying operating system and remote-access components are not maintained.

Keep current with:

• Windows security updates
• Windows Server updates
• Remote Desktop-related security updates
• Antivirus/endpoint protection updates
• Firewall updates
• VPN or gateway updates

Patch management should be part of your normal security process.

9. Monitor RDP Login Activity

If RDP is used in an organization, monitor authentication events and investigate unusual activity.

Pay attention to:

• Large numbers of failed logins
• Repeated attempts against multiple usernames
• Logins from unexpected countries or networks
• Successful logins outside normal working hours
• New administrator accounts
• Unexpected privilege changes
• Multiple failed attempts followed by a successful login

For Azure VMs, Microsoft documents checking Windows Security event logs for failed sign-in activity when investigating RDP brute-force attacks.

Monitoring does not prevent every attack, but it can significantly improve detection.

Should You Block TCP 3389 Completely?

If you do not need direct internet-based RDP access, yes, blocking inbound TCP 3389 from the public internet is generally the better approach.

For example, a typical firewall policy could be:

Internet → TCP 3389 → DENY
VPN → TCP 3389 → ALLOW
Internal Network → TCP 3389 → ALLOW

This allows RDP to continue working while preventing arbitrary internet hosts from connecting directly.

For cloud environments, Microsoft specifically warns against allowing RDP from 0.0.0.0/0 and recommends Bastion, VPN, or other restricted access methods.

What If You Absolutely Must Expose RDP?

There may be situations where direct internet access is temporarily required.

If you cannot avoid it, reduce the risk as much as possible.

Consider:

1. Restrict the source IP

Allow only trusted public IP addresses or ranges.

2. Enable NLA

Keep Network Level Authentication enabled whenever supported.

3. Use strong, unique credentials

Do not reuse passwords.

4. Use MFA where your architecture supports it

Additional authentication controls can reduce the consequences of stolen passwords.

5. Keep Windows patched

Do not expose an outdated Windows installation.

6. Enable firewall controls

Restrict inbound traffic to only what is required.

7. Monitor authentication events

Look for repeated failures and unusual successful logins.

8. Use temporary access

JIT access can be preferable to leaving RDP permanently exposed.

9. Consider a VPN or gateway

Even if direct RDP works, redesigning access through a secure intermediary is usually preferable.

10. Remove the exposure when it is no longer needed

Temporary administration should not become permanent internet exposure.

Does Changing RDP From Port 3389 Make It Safe?

No.

Changing the RDP listening port can sometimes reduce basic automated scanning noise, but it does not eliminate the fundamental problem.

For example:

3389 → 45000

does not transform:

Internet → RDP

into:

Private → RDP

The service is still internet-facing.

Microsoft specifically describes changing the default RDP port as something that may temporarily help in some attack scenarios, while recommending stronger measures such as JIT access, Azure Bastion, VPN, or restrictive firewall rules.

So, changing the port should never be presented as the primary RDP security solution.

Is RDP Over a VPN Completely Safe?

No security solution is completely risk-free.

A VPN reduces the exposure of the RDP service by putting remote users onto a controlled network path rather than publishing the RDP service directly to the entire internet.

However, the VPN itself must be properly secured.

You still need to consider:

• Strong authentication
• MFA
• VPN software updates
• Device security
• Access controls
• Network segmentation
• Account privileges
• Logging and monitoring

A poorly secured VPN can itself become an attractive target.

RDP Security Checklist

Use this checklist before exposing any Windows system to remote access:

• Avoid direct public exposure of TCP 3389 where possible

• Prefer a VPN or secure remote-access gateway

• Keep Network Level Authentication enabled

• Use strong, unique passwords

• Enable MFA where supported

• Avoid unnecessary administrator privileges

• Keep Windows fully patched

• Restrict firewall source IPs when direct access is unavoidable

• Consider Just-In-Time access

• Monitor failed and successful RDP logins

• Disable RDP when it is not required

• Do not rely on changing port 3389 as your primary security control

• Remove unnecessary public IP exposure

• Use Azure Bastion for appropriate Azure VM scenarios

• Regularly review firewall and RDP access rules

Common RDP Security Myths

Myth 1: "Port 3389 is dangerous by itself."

Not exactly.

TCP 3389 is simply the default port commonly used for RDP.

The larger issue is exposing a remote administration service directly to an untrusted network.

Myth 2: "Changing 3389 to another port makes RDP secure."

False.

Changing the port can reduce some simple automated scanning, but it does not provide meaningful protection against determined attackers.

Myth 3: "A strong password makes public RDP safe."

False.

A strong password is important, but it is only one security control.

You still need patching, access restrictions, authentication protections, monitoring, and preferably a VPN or secure gateway.

Myth 4: "Nobody knows my public IP address."

Your public IP address should not be considered secret.

Internet-facing systems can be discovered through scanning and other techniques.

Myth 5: "If the server has antivirus, public RDP is safe."

False.

Endpoint protection is valuable, but it does not eliminate network exposure or authentication attacks.

Security should be layered.

Direct RDP vs VPN: Which Is Better?

Feature	Direct Internet RDP	RDP Through VPN
Public RDP exposure	Yes	Usually no
Internet-wide scanning	Possible	RDP can remain private
Password attacks against RDP	Greater exposure	Reduced exposure
Network access control	Firewall-dependent	VPN + firewall
Attack surface	Higher	Lower
Recommended for general use	No	Yes
Suitable for administration	Higher risk	Preferred approach
Can use MFA	Depends on architecture	Often possible
Can keep RDP private	No	Yes

The goal is not to make RDP disappear.

The goal is to avoid unnecessarily publishing the RDP service to the entire internet.

What Should Home Users Do?

For a home Windows computer, the safest approach is usually to avoid forwarding TCP 3389 directly from the router.

Instead, consider using a VPN that allows you to connect to your home network first and then establish the RDP session.

The resulting connection looks like:

Laptop
   |
   | VPN
   v
Home Network
   |
   | RDP
   v
Windows PC

rather than:

Laptop
   |
   | Internet
   v
Public IP:3389
   |
   v
Windows PC

Microsoft's own guidance for remote access from outside a local network presents VPN as the preferred alternative to exposing the PC through port forwarding.

What Should Businesses Do?

Businesses should treat internet-facing RDP as a significant security decision rather than simply creating a firewall rule.

A stronger architecture can include:

Remote User
     |
     v
MFA / Identity Provider
     |
     v
VPN / Secure Gateway / Bastion
     |
     v
Internal Network
     |
     v
RDP Host

Organizations should additionally consider:

• Network segmentation
• Privileged access management
• MFA
• Conditional access
• Endpoint security
• Centralized logging
• SIEM monitoring
• Least privilege
• JIT administration
• Secure administrative workstations

Microsoft recommends avoiding direct RDP access to internet-facing session hosts and suggests mechanisms such as secure gateways or JIT access depending on the environment.

How to Check Whether RDP Is Exposed to the Internet

If you manage a server or router, review your firewall and NAT/port-forwarding rules.

Look for rules similar to:

WAN TCP 3389
        ↓
192.168.1.100:3389

or:

0.0.0.0/0 → TCP 3389

These indicate that the RDP service may be accessible from the public internet.

In cloud environments, check security groups, network security groups, firewall rules, and public IP assignments.

Microsoft's Azure documentation specifically warns against creating inbound RDP rules from 0.0.0.0/0.

What If RDP Is Already Exposed?

If you discover that TCP 3389 has been publicly accessible, do not assume that changing the port is enough.

Take a broader approach.

Step 1: Restrict or remove public access

If direct internet RDP is unnecessary, block it.

Step 2: Review authentication logs

Look for unusual failed and successful login attempts.

Step 3: Check for unknown accounts

Review local and domain accounts for unexpected changes.

Step 4: Verify administrator memberships

Look for accounts that have unexpectedly gained elevated privileges.

Step 5: Check for suspicious software

Investigate unexpected applications, services, scheduled tasks, or security-tool changes.

Step 6: Change potentially exposed credentials

If there is evidence of compromise or credential exposure, reset affected credentials according to your organization's incident-response procedures.

Step 7: Patch the system

Install current security updates.

Step 8: Replace direct RDP exposure

Move remote access behind a VPN, gateway, Bastion, or another appropriate security control.

If you have evidence of compromise, treat the situation as a potential security incident rather than simply a networking configuration problem.

The Bottom Line

You should generally not expose RDP port 3389 directly to the public internet.

The problem is not that TCP 3389 is inherently malicious or that RDP cannot be used securely.

The problem is that a publicly accessible RDP service gives attackers a direct path to a remote authentication interface.

That can expose the system to:

• Automated scanning
• Password spraying
• Brute-force attempts
• Credential attacks
• Exploitation of unpatched vulnerabilities
• Account compromise
• Lateral movement
• Ransomware-related activity

Microsoft's current guidance favors approaches such as VPNs, secure gateways, Azure Bastion, restricted source IPs, and Just-In-Time access instead of broadly exposing RDP to the internet.

The most important principle to remember is:

Don't ask how to hide port 3389. Ask how to keep RDP off the public internet.

For most environments, the preferred architecture is:

Internet
   |
   v
VPN / Secure Gateway / Bastion
   |
   v
Private Network
   |
   v
RDP Server

rather than:

Internet
   |
   v
TCP 3389
   |
   v
RDP Server

A secure RDP deployment is therefore less about changing a port number and more about controlling who can reach the service, how they authenticate, when access is available, and what happens if an account or device is compromised.

Frequently Asked Questions

Is port 3389 safe to leave open?

Leaving TCP 3389 open to the entire public internet is generally not recommended. If RDP is required, prefer a VPN, secure gateway, Bastion, JIT access, or tightly restricted source IP addresses.

Should I change the RDP port from 3389?

Changing the port may reduce some basic automated scanning noise, but it is not a security solution. It should not replace a VPN, firewall restrictions, strong authentication, patching, or other security controls.

Can hackers find an RDP server on a non-standard port?

Yes. Moving RDP to another port does not make the service invisible to determined attackers.

Is RDP secure over a VPN?

RDP through a properly configured VPN is generally a much better architecture than exposing RDP directly to the internet. The VPN itself must also be properly secured.

Should I disable RDP if I don't use it?

Yes. If remote desktop access is unnecessary, disabling it or blocking inbound access reduces the attack surface.

Is Network Level Authentication enough to secure RDP?

No. NLA is an important security control, but it should be part of a layered security strategy rather than a replacement for network access restrictions.

Can I use RDP without exposing port 3389?

Yes. You can use RDP through a VPN, secure gateway, Bastion service, private network connection, or another remote-access architecture that keeps the RDP service away from direct public exposure.

Is RDP over the internet always dangerous?

Not necessarily, but direct public exposure increases risk and attack surface. The safer design is to avoid making the RDP service directly reachable by arbitrary internet hosts.

What is the safest alternative to public RDP?

For many environments, a properly secured VPN is a practical option. In Azure, Microsoft recommends solutions such as Azure Bastion or point-to-site VPN rather than directly exposing RDP on a VM.

What should I do if my RDP port is already exposed?

First restrict or remove public access if possible. Then review authentication and security logs, check for suspicious accounts or activity, verify patching, and investigate any signs of compromise. Finally, replace direct public RDP with a more secure access method.

Suggested Internal Link Opportunities

If your knowledge base contains relevant articles, consider linking this article to pages covering:

• How to Secure Remote Desktop on Windows
• How to Enable Network Level Authentication for RDP
• How to Set Up a VPN for Remote Desktop
• How to Disable Remote Desktop in Windows
• How to Check Open Ports in Windows
• How to Configure Windows Firewall
• How to Detect Brute-Force Login Attempts
• How to Secure a Windows Server
• How to Remove an Old Device from a Microsoft Account
• How to Protect a Windows PC From Remote Attacks

Only add these as internal links when corresponding articles actually exist in your site's approved internal-link list.

Quick Takeaway

Do not expose TCP 3389 directly to the entire internet unless there is a compelling reason and you have deliberately accepted and mitigated the risk.

For most users and organizations:

VPN / Bastion / secure gateway + restricted firewall rules + NLA + strong authentication + patching + monitoring

is a substantially better security strategy than simply forwarding:

Internet → TCP 3389 → Windows PC.

 

#RDP #RemoteDesktop #RDP3389 #WindowsSecurity #Cybersecurity #NetworkSecurity #RemoteAccess #VPN #WindowsServer #Firewall #RDPProtection #RDPHacking #RDPBruteForce #PasswordSpraying #ITSecurity #SystemSecurity #MicrosoftWindows #ServerSecurity #InternetSecurity #RemoteDesktopSecurity