Is Remote Desktop Open to the Internet? Close Port 3389 and Replace Direct RDP Safely

Reader ratingRate this article

Loading reader rating…

Privacy-conscious voting uses a signed random browser identifier and a short-lived network hash; the rating tables contain no raw IP-address column.

Jennifer Hudsen closes a small office network cabinet while holding an Ethernet cable beside a secured gateway appliance. — Replace direct public Remote Desktop exposure with a maintained, authenticated gateway path before closing the old route.

If Remote Desktop is reachable directly from the public internet, treat that as a security problem to fix—not as a convenient long-term remote-work setup. CISA’s ransomware guidance says not to expose services such as Remote Desktop Protocol (RDP) on the web and identifies TCP port 3389 as a protocol and port to disable when it is not needed for business purposes.^[1] The safer goal is not necessarily to turn off every internal RDP session; it is to remove direct internet exposure and put necessary remote access behind a controlled path such as a VPN with multifactor authentication (MFA), an RD Gateway with MFA, or a zero-trust remote access gateway.^[2]

Guidance checked: September 28, 2026 at 1:15 p.m. EDT (17:15 UTC). This article explains a defensive configuration workflow; it does not claim that an exposed service has been compromised.

The short answer

Publicly forwarded RDP should be closed. Forwarding a different external port to RDP does not remove the exposure; it only changes the number at which the exposed service is reached. By contrast, RDP that is enabled on a computer but reachable only from a trusted local network is a different condition. Microsoft says enabling Remote Desktop opens a port on the PC for devices on the local network and recommends enabling it only on trusted networks.^[6]

Do not disable it blindly. First identify who or what depends on the connection, confirm an alternate administrative path, and arrange a maintenance window. CISA’s RDP countermeasure specifically calls for estimating the effect on business and system-administration operations because restricting RDP can disrupt legitimate work.^[2]

What “open to the internet” actually means

RDP is internet-exposed when an unauthenticated device on the public internet can reach the RDP service or a device that forwards traffic directly to it. Common paths include a router port-forward, a public firewall rule, a cloud security rule, or a public IP assigned to a Windows host. The public-facing port might be 3389 or a different number; if that port is forwarded to RDP, the underlying service is still directly reachable.

CISA’s joint advisory says open ports and misconfigured services exposed to the internet are a common weakness, that scanning tools are used to find them, and that RDP is among the high-risk services it identifies.^[3] The same advisory recommends verifying that machines do not have open RDP ports and placing required RDP behind a firewall and VPN.^[3]

Bad: direct exposure

A router sends a public port straight to a Windows PC’s RDP service.
A cloud firewall allows RDP from the whole internet.
The external port was changed, but it still forwards to RDP.
NLA or a strong password is treated as permission to leave direct exposure in place.

Better: brokered, limited access

Users authenticate to a maintained VPN with MFA before reaching internal RDP.
An RD Gateway provides the external entry point, with MFA and policies controlling which users reach which resources.
A managed zero-trust gateway provides authenticated, least-privilege access.
RDP remains LAN-only where internal administration still requires it.

Are you affected?

Situation	Affected?	What it means	Next move
Public port 3389 forwards to a Windows PC or server	Yes	RDP is directly internet-reachable.	Plan to remove the forwarding rule after confirming dependencies and alternate access.
A different public port forwards to internal port 3389	Yes	The port number changed; the RDP service is still exposed.	Replace direct forwarding with a protected remote-access path.
A cloud rule permits RDP from any internet address	Yes	The host is broadly reachable even if no office router is involved.	Remove broad reachability and use an approved gateway or VPN.
RDP works only after connecting to the company VPN	Not directly exposed	The VPN is the internet-facing control point.	Confirm MFA, patching, access scope, and logging on the VPN and RDP path.
RDP works only between devices on a trusted LAN	Not directly exposed	Local RDP is distinct from internet-facing RDP.	Keep it restricted to necessary users and systems; retain NLA and strong credentials.
Remote Desktop is disabled and no other product exposes it	No, for RDP	The Windows host is not accepting new RDP connections.	Still audit other remote-support or remote-management tools.

A safe diagnostic and remediation sequence

This sequence deliberately avoids context-free firewall commands. The correct change depends on whether the exposure is created by an office router, cloud firewall, Windows firewall, managed security appliance, or provider-managed network. A generic command applied to the wrong layer can fail to close the real path—or can lock out the person trying to fix it.

Stop conditions before making changes

Stop if you are connected through the same RDP path you intend to remove and do not have tested out-of-band access.
Stop if the host runs a business-critical application and its owner, maintenance window, backup state, or rollback plan is unknown.
Stop if you find unfamiliar administrator accounts, unexpected successful remote logins, disabled security tools, ransom notes, encrypted files, or other signs of compromise. Preserve evidence and follow the incident-response path instead of treating this as a routine firewall cleanup.
Stop if changing a shared router, cloud rule, or gateway could affect other sites or customers and its ownership is unclear.

Identify the business dependency

Record which computer or server is reached, who uses it, when they use it, and whether vendors, payroll, line-of-business software, backups, or after-hours support depend on the path. CISA advises estimating operational impact before restricting RDP because legitimate business and administrator activity may be disrupted.^[2]

Confirm an independent way back in

Before touching the public rule, test an alternate path: onsite console access, a provider console, a documented remote-management channel, or a newly prepared VPN or gateway. “It should work” is not enough. Have an authorized person prove that the fallback reaches the correct system and that the credentials and MFA method are available.

Map every layer that could publish RDP

Review the internet router or edge firewall, any upstream modem/router, cloud network rules, public IP assignments, and the Windows host. Check for a rule on 3389 and for rules on other external ports that translate or forward to RDP. If the location has two routers or carrier-grade NAT, document that topology rather than assuming the visible router is the only boundary.

If the network layout is confusing, see Remote Access Broke? How to Diagnose Double NAT and CGNAT.

Choose the replacement before closing the old path

For ordinary business remote access, prefer a maintained VPN with MFA, RD Gateway with MFA and scoped authorization policies, or a managed zero-trust remote access gateway. CISA’s current RDP countermeasure recommends a secure VPN after MFA or a zero-trust remote access gateway when RDP is needed.^[2] Microsoft describes RD Gateway as a way for users outside the firewall to connect securely to internal resources through an encrypted tunnel, with policies that can define which users reach which resources.^[4]

When RDS is integrated with MFA, Microsoft’s documented architecture uses RD Gateway as the entry point, Network Policy Server to process and enforce authentication policy, and an identity service to provide MFA.^[5] Plan enrollment, backup authentication methods, network requirements, and support ownership before cutover.^[5]

Restrict who may use RDP

Remove stale access, limit membership to people whose work requires it, and separate everyday accounts from privileged administration. CISA recommends role-based access, limiting RDP to a common security group, auditing connection logs, and rotating remote-service passwords if accounts with RDP access may have been compromised.^[2] Microsoft’s policy documentation confirms that disabling the remote-access policy prevents new incoming connections while maintaining current sessions, which is another reason to plan rather than improvise.^[7]

Remove direct public reachability

During the approved maintenance window, remove the rule or assignment that makes RDP directly reachable from the internet. Change the actual publishing control—not merely the external port number. If local RDP remains a documented need, keep it available only on the intended internal network or through the protected gateway path.

Verify from both sides

From an authorized connection outside the business network, verify that the former direct RDP endpoint is no longer reachable. Then verify that the approved VPN or gateway path works, MFA is enforced, the correct user reaches only the intended resource, and logging records the attempt. Also test from the LAN if local-only RDP is supposed to remain available. CISA recommends auditing RDP use, closing unused RDP ports, applying MFA, and logging login attempts.^[1]

Document and monitor

Record the removed exposure, the replacement path, responsible owner, allowed users, exception approvals, and the verification result. Review authentication and RDP logs for suspicious attempts and keep the internet-facing VPN or gateway patched. CISA recommends centralized logging and alerts for suspicious login attempts, and it warns that attackers may exploit weak or compromised passwords in attacks targeting RDP.^[3]

NLA helps, but it does not make public RDP the right design

Network Level Authentication requires a user to authenticate before a remote session is established. Microsoft recommends keeping NLA enabled in most environments because it adds a layer of security and reduces unauthorized access risk.^[6] Keep it enabled where compatible—but treat it as defense-in-depth, not as a substitute for removing direct internet exposure. CISA’s guidance is still to avoid exposing RDP on the web and to use compensating controls when an internet-facing service truly cannot be avoided.^[1]

A layered target state

No router, cloud, or firewall rule sends arbitrary internet traffic directly to RDP.
Remote users enter through a maintained VPN, RD Gateway, or zero-trust gateway.
MFA is enforced at that entry point, including for administrators.
Only approved users can reach only the systems they need.
NLA remains enabled on compatible RDP hosts.
Remote access attempts are logged and reviewed.
Offline, tested backups and an incident-response plan are maintained; CISA recommends both as ransomware preparation measures.^[1]

Two wrong turns: one harmless, one costly

Harmless wrong turn: checking only 3389

A small office tests public port 3389, finds it closed, and assumes RDP is private. The router actually forwards external port 44389 to internal RDP. No outage occurs, but the audit misses the real exposure. The fix is to review translation and forwarding rules by destination service, not just by familiar public port number, and then verify from outside.

Costly wrong turn: closing the only support path

An administrator removes a public RDP rule while connected through it, without a tested VPN, provider console, or onsite contact. The business application may remain healthy, but support loses access and an emergency site visit becomes necessary. If a rushed recovery adds a broad temporary rule and nobody removes it, the organization can end up exposed again. The prevention is simple: identify dependency, test out-of-band access, schedule the cutover, and verify the final state.

If the evidence points to an intrusion

Do not keep changing access controls as though this were only a configuration cleanup. CISA’s ransomware checklist starts by determining which systems are affected and isolating them, while preserving evidence and coordinating the response.^[1] Use the Ransomware First 15 Minutes Response Checklist and contact your IT/security provider, cyber insurer, and incident-response resources specified in your plan.

Also remember that RDP may not be the only remote path. Review installed and portable remote-support tools, vendor agents, and stale accounts with the Forgotten Remote Support Software 30-Minute Audit. CISA recommends auditing remote access and remote monitoring software and requiring approved tools to operate through approved remote-access solutions.^[1]

Frequently asked questions

Is port 3389 always dangerous?

No. The important distinction is reachability and control. RDP available only to authorized devices on a trusted LAN is not the same as RDP forwarded from the public internet. Microsoft says enabling Remote Desktop makes the PC accessible to devices on the local network and recommends using it only on trusted networks.^[6] Even internally, limit access, keep NLA enabled, patch systems, use strong unique credentials, and monitor use.

Does changing the external RDP port solve the problem?

No. If the new public port still forwards directly to RDP, the service remains internet-reachable. A changed port can reduce obvious noise in some logs, but it is not equivalent to removing exposure and should not be treated as the security boundary.

Should I turn off Remote Desktop in Windows?

If nobody needs it, disabling it reduces unnecessary exposure; Microsoft says there is no need to enable Remote Desktop when the PC is used only locally.^[6] If the business needs LAN-only or gateway-mediated RDP, you may retain that controlled use. Do not disable it until you confirm dependencies and an alternate administrative path.

Is a VPN enough?

A VPN is a safer boundary than direct public RDP only when it is properly maintained and controlled. CISA recommends MFA on VPN connections and notes that threat actors can also exploit VPNs or use compromised credentials.^[1] Patch the VPN, enforce MFA, restrict access, and log authentication.

What is the difference between RD Gateway and direct RDP?

Direct RDP exposes the RDP service itself to the connecting network. RD Gateway acts as the remote entry point and establishes an encrypted tunnel before passing authorized traffic to an internal resource. Microsoft documents RD Gateway policies that can specify which users may access which internal resources.^[4]

Does NLA replace MFA?

No. NLA makes users authenticate before a session is established, while MFA requires more than one authentication method. Microsoft treats NLA as an added security layer for RDP and separately documents MFA integration for Remote Desktop Services.^[6]^[5] Use both where the design supports them, but still remove direct internet exposure.

What if a vendor says it requires public RDP?

Ask for the documented business and technical requirement, named users, support window, logging, MFA capability, and a migration plan to a VPN, RD Gateway, or zero-trust gateway. Escalate any exception for a risk decision rather than leaving an undocumented permanent rule. CISA says internet-facing services should be continually assessed for business need and protected with compensating controls.^[3]

Bottom line

Close direct internet exposure, not legitimate business access. Find the dependency, establish and test a protected replacement, remove every public path to RDP, and verify the result from outside and inside. Keep NLA as a supporting control, enforce MFA at the gateway or VPN, restrict users, patch the entry point, and monitor the logs. That approach follows the central CISA message: do not expose RDP on the web when you can remove the exposure.^[1]