RDP vs VPN: which one your servers actually need

The comparison people think they are making

"RDP or VPN" sounds like a choice between two remote-access technologies. It is not: a VPN does not replace RDP, it decides who is allowed to reach it. You still use Remote Desktop at the end. The real question is whether the RDP service listens to the whole internet or to a private network you control the door to.

Framed that way, the security comparison is not close. A VPN removes the exposure; direct RDP manages it. Every serious hardening guide says use the VPN, and every serious hardening guide is right.

And yet an enormous number of production servers are directly exposed, run by people who have read those guides. That is worth taking seriously rather than dismissing, because the reasons are usually real.

What a VPN actually changes

Put a VPN in front and the RDP service is no longer internet-reachable. That single fact removes a whole category of problem:

• The scanners stop finding you. Failed-login volume goes to essentially zero, and your Security log becomes readable again.
• Pre-authentication vulnerabilities in RDP itself stop being urgent. If nobody unauthenticated can reach the service, the next RDP CVE is a patch you schedule rather than an incident you manage.
• Credential attacks have to get through the VPN's authentication first, which is one more place to enforce multi-factor and one more log to review.
• You get a single, auditable entry point instead of a service exposed on every server independently.

What it costs to run

The reason VPNs get recommended and not adopted is that the cost is operational rather than financial, and it lands on people rather than budgets.

Every person who needs access needs a client, a credential and a working configuration — including the contractor who joins for two weeks, the colleague on a phone, and whoever is on call at three in the morning from a hotel network that blocks the VPN's port.

The VPN itself becomes critical infrastructure. When it is down, nobody can reach anything, including the people who need to fix it. It needs monitoring, patching and its own emergency access path, and VPN appliances have themselves been the entry point in several large breaches.

And there is a failure mode specific to organisations that half-adopt it: the VPN goes in, one server is left directly exposed "temporarily" so that a client can connect, and that exception outlives everyone who remembers agreeing to it. A documented, defended direct exposure is safer than an undocumented one behind a VPN nobody audits.

When direct RDP is the defensible choice

Not a concession — there are situations where it is genuinely the better engineering decision.

When the people who need access are outside your control. Client-owned servers, external contractors, agencies handing machines back and forth: you cannot issue VPN credentials to an organisation you do not administer.

When you run one or a handful of servers. Standing up and maintaining VPN infrastructure to protect two machines is a poor trade, and the VPN becomes the more likely thing to break.

When access has to work from anywhere, immediately. Hotel and corporate networks block VPN protocols often enough that "I cannot connect" during an incident is a real operational risk.

In those cases the honest position is: the service is exposed, and it needs compensating controls that are actually in place — MFA on every account, NLA, current patches, and automatic banning of sources that fail repeatedly. That combination is meaningfully stronger than a VPN that half the team routes around.

The options in between

The choice is not binary, and the middle ground is where most well-run fleets end up.

• Remote Desktop Gateway — tunnels RDP over HTTPS on 443, so it works from networks that block everything else, and gives you one authenticated, logged entry point. Closer to a VPN in benefit, closer to RDP in operational cost.
• A bastion or jump host — one hardened, heavily monitored machine is exposed; everything else is reachable only from it. Concentrates the risk somewhere you can afford to watch closely.
• Cloud provider session managers — browser or agent-based access with no inbound port at all. Excellent where your servers live in a provider that offers it, unavailable where they do not.
• Zero-trust network access — per-application, identity-aware access without a network-level tunnel. The direction the industry is moving, with a subscription and an onboarding cost to match.
• Source-restricted RDP — no tunnel, just a firewall that permits a small list of known addresses. The cheapest real control there is, and it works right up until somebody travels.

Choosing

Two questions settle it in most cases. Can every person who needs access reliably reach a VPN, from every network they work from? And do you have someone who will keep that VPN patched and monitored?

Two yes answers: use the VPN, and stop here. It is the stronger design and the cost is one you can carry.

Any no: be honest that the service is exposed, and build the compensating controls properly rather than adopting a VPN that will be worked around. That means MFA everywhere, NLA on, patches current, the built-in Administrator account disabled, and automatic firewall banning of sources that fail repeatedly.

RDP Protector covers that last piece for servers that stay reachable — subnet bans, permanent and reboot-proof, your own address whitelisted before anything is blocked, and ports detected from the registry rather than assumed. It is also worth running behind a VPN, because the failed logins that remain are then coming from inside your perimeter, which is exactly the traffic you most want to know about.