How to Secure Remote Desktop Without Exposing RDP to the Internet

Overview

If you need remote access to a Windows workstation or server, the obvious route often looks simple: enable RDP, forward TCP 3389 on the firewall, and connect from anywhere. It is also one of the least defensible designs. Open RDP services are continuously scanned, login pages are hammered by automated tools, and any weak credential, stale patch level or misconfiguration turns a convenience feature into an exposed attack surface.

The better goal is not merely to “secure RDP” in isolation. It is to design secure remote desktop access so that the desktop service is only reachable through a trusted control layer. In practice, that usually means one of four models:

• RDP over VPN, where users first authenticate to a VPN and then connect to the private host address.
• Remote Desktop Gateway, where RDP is proxied through an access gateway with policy controls.
• Zero Trust Network Access (ZTNA) or application access brokers, where users receive identity-based access to a specific service rather than broad network reachability.
• Jump host or bastion design, where remote users connect to a hardened intermediary system rather than to every endpoint directly.

Each approach can work. The right choice depends on how many users you support, whether they are staff or contractors, how much network access they actually need, and how mature your identity, logging and endpoint management already are.

As a general rule, if your current setup relies on router port forwarding to expose RDP from an office, home network or branch site, your first improvement is straightforward: remove direct internet exposure and place access behind a stronger trust boundary. That alone cuts a large amount of ambient risk.

This article focuses on comparison rather than product rankings. It is designed to stay useful even as tools change, because the access patterns and tradeoffs stay broadly consistent.

How to compare options

The fastest way to choose the wrong remote access design is to compare on convenience alone. A secure setup should be judged on five practical criteria: exposure, identity control, device trust, user experience and operational overhead.

1. Exposure: is the desktop service directly reachable?

This is the first question to ask in any RDP security best practices review. If the RDP service itself is directly reachable from the public internet, you are relying on the host and its authentication settings to absorb constant unsolicited traffic. If access is mediated through a VPN, gateway or ZTNA broker, the desktop service remains private and the public-facing component can be hardened independently.

From a defensive point of view, lower exposure is usually better. “Remote desktop without port forwarding” is not just a convenience phrase; it is the right default design principle.

2. Identity control: can you enforce strong authentication centrally?

Look for central identity integration, especially if you already use SSO, conditional access or MFA. A good remote access layer should let you:

• Require MFA before any desktop session begins
• Restrict access by user group or role
• Disable accounts quickly in one place
• Apply session policy consistently
• Log who accessed what and when

If your access model depends on local machine accounts, shared admin credentials or manually maintained exceptions, it will become brittle as the environment grows.

3. Device trust: are you checking the endpoint, not just the user?

For internal administrators, managed devices matter. For contractors, they matter even more. Ask whether the remote access method can distinguish between:

• Managed and unmanaged devices
• Compliant and non-compliant devices
• Known and unknown locations
• Corporate and personal endpoints

A traditional VPN can provide strong encryption and private network access, but many deployments grant more network reach than users actually need. ZTNA-style access can be narrower, though it may add architectural complexity. If you are weighing ZTNA vs VPN, the real decision is often whether users need broad private network access or access to one or two clearly defined services.

4. User experience: does secure access stay usable?

Security controls that make remote access too fragile usually lead to workarounds. Compare:

• How many steps users need to connect
• Whether reconnection is reliable on unstable links
• How well the solution performs on home broadband and public Wi-Fi
• Whether access works consistently across Windows, macOS and mobile clients where relevant

If performance is a concern, review your transport choices and test rather than guess. Our guides on VPN Speed Test Guide: How to Measure Real Performance and Fastest VPNs Compared: UK Servers, International Speeds and Latency are useful references for the methodology side, especially if you are planning RDP over VPN for distributed teams.

5. Operational overhead: who will manage it next year?

An elegant remote access design on paper can become a burden if it needs constant manual maintenance. Compare options based on:

• Patch and certificate management
• User onboarding and offboarding effort
• Support for always-on or policy-based connection
• Logging and troubleshooting quality
• Compatibility with existing firewalls, identity providers and endpoint tools

For smaller teams, simpler is often safer. A modest, well-managed VPN plus strict RDP hardening can be a better outcome than a half-deployed zero trust programme with unclear ownership.

Feature-by-feature breakdown

This section compares the main approaches to how to secure RDP without treating any single pattern as universally correct.

Option 1: RDP over VPN

This is the most familiar route for many IT teams. Users authenticate to a remote access VPN first, receive access to a private network path, and then open an RDP session to the internal hostname or IP.

Where it fits well

• Small to mid-sized environments
• IT admins who already operate VPN infrastructure
• Users who need access to more than one internal service
• Teams that want predictable deployment with common client support

Strengths

• Removes the need to expose port 3389 publicly
• Can be combined with MFA, device certificates and always-on policies
• Works with existing private addressing and internal DNS
• Often simpler to understand than newer access abstractions

Limitations

• May provide broader network reach than necessary
• User experience depends heavily on client stability and tunnel design
• Split tunnel decisions can affect both performance and risk
• Poorly segmented VPNs can make lateral movement easier after compromise

If you are exploring this route, related reading includes Always-On VPN for Windows, macOS, iPhone and Android: Setup Considerations, SSL VPN vs IPsec VPN: Performance, Security and Setup Tradeoffs, and Site-to-Site VPN vs Remote Access VPN: Key Differences for IT Teams.

Option 2: Remote Desktop Gateway

A Remote Desktop Gateway or similar gateway architecture publishes a controlled entry point rather than the desktop service itself. Users connect through HTTPS-based access, and gateway policies determine what internal resources they can reach.

Where it fits well

• Environments centered on Windows administration
• Organisations that want to confine remote access to desktop workloads
• Teams that prefer gateway-mediated sessions over broad VPN access

Strengths

• Keeps internal hosts private
• Can narrow access to approved targets
• Often more precise for RDP-specific use cases than general VPN access
• Can simplify user workflows when well configured

Limitations

• Still requires careful hardening of the gateway tier
• May not cover non-RDP use cases cleanly
• Certificate, policy and gateway maintenance need attention

This can be a sensible middle path when users need desktop access but not a full private network presence.

Option 3: ZTNA or application-specific secure access

ZTNA-style access shifts the model from “connect the device to the network” to “connect the verified user and verified device to a specific application or service.” For remote desktop, that means the user may be granted access only to a designated internal host or brokered session, rather than to a wide subnet.

Where it fits well

• Hybrid environments with identity-centric access policy
• Contractor or third-party access scenarios
• Teams reducing broad network-level VPN access
• Organisations that already use SSO, MFA and device posture checks

Strengths

• Fine-grained access control
• Better alignment with least privilege
• Can reduce lateral movement opportunities
• Typically strong logging and policy visibility

Limitations

• Architecture and vendor choices vary widely
• May be excessive for very small environments
• Integration effort can be higher than a straightforward VPN

If you are evaluating modern secure remote access patterns rather than just replacing port forwarding, this is the category worth watching most closely over time.

Option 4: Jump host or bastion

In this model, users first access a hardened intermediary system, then continue to internal desktops or servers from there. The jump host can sit behind VPN, gateway or other access controls.

Where it fits well

• Administrative access to sensitive environments
• Segregated networks and privileged workflows
• Cases where session recording or tighter monitoring is required

Strengths

• Creates a clear choke point for monitoring and control
• Supports stronger privileged access separation
• Can reduce direct admin access to production systems

Limitations

• Adds an extra step for users
• Needs careful hardening and operational ownership
• Can become a bottleneck if undersized

Core hardening steps that apply whichever model you choose

No access architecture removes the need for host-level discipline. These are the baseline RDP security best practices that remain useful across designs:

• Do not expose RDP directly to the internet. Remove port forwarding rules and public listener exposure wherever possible.
• Require MFA at the access layer. VPN, gateway or identity broker should enforce it before the session begins.
• Use strong, unique credentials and disable stale accounts. Remote access tends to reveal old hygiene problems quickly.
• Restrict who can sign in via Remote Desktop Services. Limit membership and review it regularly.
• Patch the operating system and remote access stack promptly. Delays create avoidable risk, especially on exposed gateways.
• Enable Network Level Authentication where appropriate. This adds a useful pre-session control, though it is not a substitute for broader hardening.
• Segment the network. A user who connects for one desktop should not automatically gain access to unrelated systems.
• Log authentication events and session activity. Make sure logs are retained somewhere central and reviewed when alerts fire.
• Use managed endpoints for administrative access. Avoid high-privilege administration from personal devices.
• Test for accidental leaks and access drift. Re-check firewall rules, exposed services and identity group assignments after changes.

For a broader operational baseline, see Remote Access Security Checklist for Small Businesses.

Best fit by scenario

The right design depends less on vendor branding and more on the shape of the problem. These scenarios help narrow the choice.

Small business with a few office PCs

If a small team needs occasional access to office desktops, the practical default is usually RDP over VPN with MFA and minimal user permissions. It is familiar, cost-conscious and easier to support than a more complex brokered model. The important part is to avoid direct exposure and keep the VPN tightly scoped.

For planning and procurement questions, How to Choose a Business VPN: UK SMB Checklist is a useful companion.

Hybrid team with laptops and regular remote work

If remote access is routine rather than occasional, usability matters more. Always-on VPN, device posture checks and clear conditional access rules usually become more important than pure protocol choice. In this scenario, broad but segmented VPN access may still be acceptable if endpoint management is strong and users genuinely need access to multiple internal services.

For wider planning, see Best VPNs for Remote Workers and Hybrid Teams.

Contractors or third-party support access

This is where broad VPN access often becomes uncomfortable. If an external user only needs access to one internal host or one admin workflow, a gateway or ZTNA-style approach is usually easier to justify. Least privilege matters more here, and so does central logging.

Privileged admin access to servers or regulated systems

For domain admins, infrastructure teams or sensitive workloads, a jump host combined with MFA, session controls and managed endpoints is often the most defensible option. The user experience is less direct, but the security boundary is clearer.

Home lab or single advanced user setup

Even for a single admin, “just open 3389” is still the wrong habit. A lightweight VPN on a firewall, router or dedicated appliance is usually the cleanest path to remote desktop without port forwarding. If you are extending secure access into a home or small office network, Best VPN Routers and Router VPN Setups for Home Networks may help with the network side.

When to revisit

Remote access designs should not be treated as a one-time project. Revisit your setup when the underlying conditions change, especially if your original design was chosen for speed rather than long-term fit.

Review your approach when:

• You add contractors, MSPs or other third-party users
• You move from occasional remote access to daily hybrid work
• You adopt SSO, MFA or conditional access and can enforce better policy centrally
• You discover users have wider network access than they actually need
• You replace firewalls, VPN appliances or endpoint management tools
• You see repeated login noise, account lockouts or suspicious authentication patterns
• You need better auditability for internal policy or compliance reasons
• You are considering ZTNA as a replacement for broad remote access VPNs

A practical review cycle can be simple:

1. List every system currently reachable through remote desktop.
2. Confirm none are directly exposed to the public internet.
3. Map who can access each system and why.
4. Check whether MFA is enforced before desktop access starts.
5. Review whether users need full network access or only specific hosts.
6. Verify logging, alerting and account offboarding procedures.
7. Test the connection flow from an external network to confirm the design matches your documentation.

If you want one durable rule to keep, use this: make the RDP service private, make access identity-aware, and keep permissions narrower than the network makes convenient. That principle holds whether you use a business VPN, a gateway, a jump host or a zero trust access layer.

For most teams, the immediate next step is not a wholesale redesign. It is to remove direct exposure, enforce MFA, and choose the access model that matches real user needs with the least unnecessary reach. Once that foundation is in place, future upgrades become much easier to evaluate as products, features and policies change.