Securing Remote Desktop: VPN vs Other Access Methods

Remote Desktop is convenient in a way that makes it dangerous. One click gives a person full control of a Windows machine from anywhere, so it is no surprise that attackers spend a great deal of effort trying to get in through it. For years, a computer with its Remote Desktop port open to the internet has been among the most common starting points for ransomware and account takeover, which is why almost every security guide begins with the same advice: do not expose it directly.

This article is about the choice that follows. If Remote Desktop must not face the open internet, what should stand in front of it? A VPN is the traditional answer, but it is not the only one, and for some teams it is not the best one. We compare a VPN with a gateway, a jump host and identity-based access, and finish with a hardening checklist you can apply today. We do not cover how to attack or probe other people's systems.

Why Remote Desktop is a favourite target

Remote Desktop speaks a well-known protocol on a well-known port. That makes it easy to find: automated scanners sweep the whole internet continuously and list every machine that answers. A few things then go wrong again and again.

• Weak or reused passwords. An exposed login is tried thousands of times with lists of common and leaked passwords. If a single account is weak, it is eventually found.
• Known vulnerabilities. Remote access services have had serious flaws that let an attacker act before signing in. An unpatched host that is reachable from the internet is a target.
• Too much privilege. Many accounts used for Remote Desktop are administrators. One stolen credential then means total control of the machine.
• No second factor. The classic setup asks only for a name and a password. Anyone who learns them can sit down at your desk.
• No visibility. Small offices rarely read sign-in logs, so a successful attack can last for weeks before someone notices.

None of this is about the encryption of the session itself. The protocol is encrypted. The problem is that the front door is public, the lock is a password, and the room behind it has the keys to everything else on the network.

The goal of any secure approach is therefore the same: take the front door off the public internet, check who is knocking before they get near the door, give them access only to what they need, and write down what happened.

Option 1: A VPN in front of Remote Desktop

With a VPN, the Remote Desktop port is never published to the internet. Staff first connect to the VPN server run by the office or by the IT provider, which gives them an address on the private network. Only then can they open Remote Desktop to the internal address of their machine.

What it does well

• Removes the open port from public scans.
• Encrypts the path between the remote user and the office, which also helps on hotel and cafe networks.
• Gives one place to apply sign-in rules, for example certificates plus a second factor.
• Works for many applications at once, not only Remote Desktop: file shares, printers, internal web tools.

Where it falls short

• A VPN is a bridge, not a filter. Once connected, a device can often see the whole internal network. A compromised laptop therefore brings the attacker to everything behind the tunnel unless you add rules.
• The VPN server becomes the new front door. It must be patched, monitored and protected with multi-factor sign-in, because it is the one thing now facing the internet.
• Setup and care. Someone must manage accounts, certificates and updates. Small teams sometimes set it up once and forget it.
• Client health. Home computers of staff may be unmanaged and carry malware that rides in with the tunnel.

A VPN is a good fit when you have a single office, a small team, and a person or provider responsible for keeping the VPN server updated. Read business VPN vs personal VPN to see why the kind of VPN you run for this job is a different product from the consumer apps used on a phone.

Option 2: A Remote Desktop Gateway

A gateway is a server that accepts Remote Desktop sessions over HTTPS and relays them inside. The user signs in to the gateway first. The gateway then checks policies such as who may reach which machine and from what kind of device, and forwards the session if the answer is yes.

What it does well

• Only the gateway needs to face the internet, not each desktop.
• Policies are tied to users and to target machines, so someone with access to one server does not automatically reach another.
• Because it uses HTTPS on the usual port, it works on networks that block other traffic types.
• It can be combined with multi-factor sign-in and with logging of every session.

Where it falls short

• It is built for Remote Desktop. If staff also need file shares or an internal web app, you still need another path.
• The gateway needs a valid certificate, regular patching and a careful configuration.
• A misconfigured gateway can end up as a wider hole than the thing it replaced.

A gateway suits a company whose main remote need is reaching a few Windows desktops or servers and which already runs Windows infrastructure.

Option 3: A jump host or bastion

A jump host is a small, hardened machine whose only job is to be the stepping stone. Users sign in to it first, usually with multi-factor authentication, and from there open sessions to the real machines. The real machines accept connections only from the jump host's address.

What it does well

• A very small attack surface, because the jump host runs few services.
• A single place to record sessions and review who connected.
• It is easy to explain and audit: all roads lead through one door.

Where it falls short

• It is yet another machine to update, and if it is compromised the attacker is already past the first wall.
• It adds a step for every user, which tempts people to find shortcuts.
• It protects the way into the machines but does not by itself encrypt the path from the user's home network to the jump host; you normally pair it with a VPN or with an encrypted gateway protocol.

A jump host is often combined with other layers rather than used alone. It is popular in teams that already manage servers day to day.

Option 4: Identity-based or zero trust access

Instead of putting the user on the network, identity-based access asks a different question on every request: who is this person, what device are they using, and is this machine allowed to reach this one application right now? The user gets a connection to one application or one machine, not to the whole network.

What it does well

• Limits what a stolen account or a compromised laptop can reach.
• Makes the device matter: access can require an up-to-date, managed device.
• Fits mixed environments with cloud services, offices and home workers.
• Produces useful logs about who reached what.

Where it falls short

• It needs an identity system and some planning, so it takes more effort than switching on a VPN.
• It costs more to set up in a very small business with one office and two machines.
• It does not remove the need to patch the target machine.

The principles are described in NIST's zero trust architecture publication, and our comparison of zero trust and VPN goes through the differences in plain language.

Comparing the four options

Question	VPN	Gateway	Jump host	Identity-based access
Takes RDP off the open internet	Yes	Yes	Yes	Yes
Covers apps other than RDP	Yes	Mostly no	Partly	Yes, per application
What a stolen login can reach	Often the whole network	Only allowed machines	Only allowed machines	Only allowed applications
Good for a team of 2 to 5	Yes	Sometimes	Rarely	Sometimes, if hosted
Good for a growing company	Needs extra rules	Good	Good as a layer	Strong fit
Effort to maintain	Medium	Medium	Medium	Medium to high at start
Typical weak spot	Flat network behind it	The gateway's patch level	The jump host's patch level	Mistakes in policy

No option is magic. The right choice depends on how many people connect, how many machines, and who is available to maintain it. A two-person design studio and a 60-person accounting firm should not end up with the same answer.

A hardening checklist that applies to every option

Whatever sits in front of Remote Desktop, the machine behind it needs the same basics.

1. Do not publish the RDP port to the internet. Confirm it from the outside, for example by testing from a mobile connection that is not on your network. See VPN port forwarding explained for how published ports work and why they are risky.
2. Turn on network level authentication. It forces the user to authenticate before a full session is created, which reduces what an unauthenticated visitor can touch.
3. Require multi-factor sign-in at the front door, whether that is the VPN, the gateway or the identity provider. CISA's guidance on multi-factor authentication and our article on two-factor authentication explain the options.
4. Use unique, long passwords and remove shared accounts. Each person should have their own named login.
5. Limit who may use Remote Desktop. Only members of one specific group should be allowed, and administrators should sign in with a separate admin account only when needed.
6. Apply updates quickly, especially to the operating system, the gateway and the VPN server.
7. Set account lockout rules so repeated wrong passwords slow an attacker down.
8. Read the logs. Turn on logging of sign-ins and failures and look at it on a schedule. A sudden burst of failed attempts is useful information.
9. Disable clipboard and drive redirection where you do not need them, so a session cannot carry files in or out casually.
10. Back up offline. If something does go wrong, a backup that the attacker could not reach turns a disaster into an inconvenience.

The NIST telework security guidance lays out the reasoning behind these measures, and NIST's guide to IPsec VPNs covers the VPN side for readers who want detail.

Three situations and sensible answers

A two-person design studio with one office PC. Laila and Tom want to reach a powerful desktop in the studio from home. The cheapest sensible answer is a VPN on the studio router, with sign-in protected by a second factor, and Remote Desktop reachable only on the internal address. They update the router and the PC monthly. They do not forward the RDP port, even though a tutorial told them it was quick.

A twenty-person accounting firm with three Windows servers. Staff need the accounting software and file shares, and the owner worries about client data. A gateway with multi-factor sign-in gives staff access to the specific servers they use, while a VPN is kept for printers and shared drives. A named partner receives a monthly summary of unusual sign-ins.

A growing company with remote staff on mixed laptops. Developers, finance and support work from different countries, and some use personal devices. Here identity-based access, with device checks, avoids putting everyone on a flat network. Remote Desktop stays for the few cases that need it, behind the same sign-in.

In each case the pattern is the same: shrink what is exposed, check identity strongly, and give each person the least access that lets them work.

Mistakes people make

• Forwarding port 3389 "just for a week". Temporary rules are famous for becoming permanent. Treat any exposed RDP as an incident waiting to happen.
• Assuming a VPN makes the PC safe. It only moves the front door. Weak passwords and unpatched hosts remain.
• Using a consumer VPN app and expecting office access. A VPN app sold to individuals sends your internet traffic through the provider. It does not connect you to a network that your own organisation runs. If you want to reach your own office, you need a VPN or gateway that your office controls.
• Sharing one administrator login. You lose accountability and cannot tell who did what.
• Ignoring the endpoint. A remote user with an infected laptop can carry the problem into the tunnel. Keep the client device updated and protected.
• Skipping the backups. Remote access is a common path for ransomware. A tested offline backup is the real safety net.

Summary

Remote Desktop should not be reachable directly from the internet. A VPN removes the open port and encrypts the path, which makes it a sensible and familiar answer for small offices, but it can give a stolen login a wide view of the internal network. A gateway, a jump host and identity-based access each narrow what a user can reach and what an attacker can use, at the price of more design effort. Whatever you pick, add multi-factor sign-in, named accounts, updates, lockout rules, logging and offline backups.

If you are looking at a personal VPN for use on public networks while you work remotely, you can compare options on the pricing page, keeping in mind that it protects your own traffic and does not replace the access setup your organisation runs.