RDP Security Without a VPN: 5 Situations It's the Only Option

If you've read any modern guide on remote access, the advice is the same: don't expose RDP directly — put it behind a VPN, Tailscale, Cloudflare Tunnel, or RD Gateway. That advice is correct. Microsoft's own guidance and CISA's StopRansomware checklist both recommend it.

But correct advice and feasible advice aren't always the same thing. Plenty of admins reading this can't dictate what their tenants run, can't roll out a VPN client to 80 ad-hoc contractors, or are looking at a Windows Server 2012 R2 box where the modern VPN client refuses to install. For them, the question isn't "should I use a VPN?" — it's "how do I keep port 3389 alive without becoming the next Verizon DBIR statistic where stolen credentials drove 88% of basic web application attacks (per the 2025 Verizon DBIR)?"

Five situations follow where VPN enforcement isn't on the table, and what effective RDP security without VPN looks like in each. It's meant for sysadmins, MSPs, and hosting teams who already know the ideal answer — and need a working answer for the messy reality.

Why is "just use a VPN" not always possible?

A VPN works when one organization controls both ends of the connection. The moment that assumption breaks, the model breaks with it.

Hosting providers and datacenters can't force a VPN client onto a customer's laptop. MSPs juggling 50 or more client environments often inherit RDP exposure they didn't design. Contractors come and go on weekly cycles, and provisioning a VPN account for each one creates more attack surface than it removes. Older Windows Server boxes — and there are still a lot of them — have flaky VPN client compatibility. And when the VPN itself goes down at 2 a.m., somebody still has to reach the server.

The realistic frame: a VPN is the best default, and direct RDP is what you protect when the default isn't available. The numbers are sobering. Sophos's Active Adversary Report found that compromised credentials and exposed RDP were the top initial access vectors in incident response engagements, and that external remote services were used in 65% of incident response cases tracked across 2023, with RDP abused in 90% of those attacks. So the protection has to be real, not theatrical.

Situation 1: Hosting providers and datacenters

A hosting provider sells Windows VPS instances. The customer signs up, gets RDP credentials, and connects directly. There is no shared corporate network, no LDAP, no central VPN. The provider can't enforce client-side software on machines they don't own.

What works here:

• Per-VM RDP brute-force protection at the OS level — something that watches Windows Security Event Log for Event ID 4625 failed logons and blocks the source IP at the Windows Firewall after a small number of attempts. This is a layer the hosting provider can ship as part of the base VM image without breaking the customer's workflow.
• Geo-blocking at the host firewall when the customer's user base is regional. Cutting off 90% of source countries cuts off roughly the same percentage of automated brute-force noise.
• Network Level Authentication (NLA) enforced on every image. NLA forces credential validation before the RDP session is fully established, blunting most pre-auth exploit attempts.
• Account lockout policy on the VM itself — typically 5 failed attempts, 30-minute lockout. Combined with Event ID 4625 monitoring, this stops slow-burn password spraying before it succeeds.

If you operate a hosting platform and want to know how exposed your customer fleet currently is, the RDP exposure article covers what attackers see when they scan port 3389.

Situation 2: MSPs managing dozens of mixed client environments

The typical MSP nightmare: 50 clients, 200 servers, and a VPN strategy that varies by client. Client A has Tailscale. Client B has a 10-year-old SonicWall. Client C refuses to pay for a VPN line item. Client D is a 4-person dental office where the dentist will absolutely call the help desk to reset their VPN client every Monday at 7 a.m.

Forcing a uniform VPN deployment isn't always the MSP's call, and even when it is, the rollout can take 6 to 12 months across a book of business. In the meantime, RDP is exposed for some subset of clients, and the MSP carries the breach risk.

What works here:

• Standardized RDP hardening as a baseline — NLA on, RDP user group locked down, account lockout configured, brute-force protection installed during onboarding. The Windows Server security checklist has the practical version of this list.
• Centralized log forwarding so Event ID 4625 spikes show up in the MSP's SIEM or RMM dashboard within 5 minutes, not when the client calls.
• Conditional access where Microsoft 365 is in play — Entra ID Conditional Access policies can require MFA for RDP access via RD Gateway with Azure MFA integration without touching the client's existing VPN setup.
• A kill-switch playbook for clients who refuse hardening: documented in writing, signed by the client, with a 24-hour disable-RDP procedure ready for the day a 4625 spike turns into something worse.

This isn't security through perfection. It's security through repeatable defaults applied to non-uniform environments.

Situation 3: How do you protect RDP for external contractors and short-term users?

Contractors are the third hard case. A typical mid-sized IT team might have 15 full-time staff and 30 contractors rotating across 6-month projects. Provisioning each contractor with a VPN account, a corporate laptop, and an offboarding procedure costs roughly $1,200 per person per year in license and admin time, by most estimates — and the offboarding step is where most organizations fail. Verizon's 2024 DBIR flagged that valid-account abuse, including stale credentials, was involved in roughly 1 in 3 breaches.

The pragmatic pattern when you can't issue VPN access to every short-term user:

• Time-boxed RDP firewall allowlists. A scheduled task or PowerShell script opens port 3389 for the contractor's IP for the duration of the engagement, then closes it automatically. This is essentially manual just-in-time access and works for a small number of contractors.
• Per-user RDP accounts, never shared. Shared accounts make Event ID 4625 forensics nearly useless because you can't tell which person's stolen password is being tried.
• MFA via Duo, Entra ID, or a third-party RD Gateway plugin. MFA on RDP isn't free to set up — budget 4-8 hours per server — but it removes credential stuffing as a viable attack path. Microsoft reports MFA blocks 99.9% of automated account takeover attempts.
• Session timeout of 15 minutes idle, 8 hours absolute. Forces re-authentication and limits the damage if a contractor's machine gets compromised mid-session.

The Event ID 4625 deep-dive explains exactly which fields to watch when contractor credentials start showing up in failed-login logs from unexpected source IPs.

Situation 4: How do you secure RDP on legacy Windows Server without VPN support?

Windows Server 2012 R2 reached extended support end-of-life on October 10, 2023. Server 2016 hit mainstream end-of-life in January 2022. Plenty of these boxes are still running production workloads — line-of-business apps that nobody wants to touch, ERP systems on legacy SQL Server, manufacturing-floor controllers tied to specific hardware.

Modern VPN clients often won't install cleanly on these systems. Tailscale supports Windows Server 2016 and newer. WireGuard on Server 2012 R2 is unofficial at best. Even traditional IPSec VPNs hit driver-signing and TLS-version mismatches.

For these environments:

• Patch what you can. Apply ESU (Extended Security Updates) where available. Server 2012 R2 ESU runs through October 2026 — available free on Azure, or via Azure Arc or volume licensing for on-premises machines.
• Treat the box as fragile. No experimental security agents, no untested kernel-level filters. RDP brute-force protection that runs purely in user mode and reads the Event Log is safer here than anything that hooks the network stack.
• Network-segment aggressively. If the legacy server doesn't need to reach the internet outbound, block outbound traffic at the upstream firewall. Most ransomware operators rely on outbound C2 to function.
• Plan the replacement. Legacy hardening is a holding pattern, not a destination. Document a 12 to 18-month migration plan even if execution is delayed.

Situation 5: Break-glass and emergency access

Every VPN-first design needs a break-glass answer for the case when the VPN itself is the thing that broke. If the firewall config is corrupted, the VPN appliance's certificate expired overnight, or the cloud VPN provider has an outage, you still need to reach the server.

The common pattern used by mature ops teams:

• A single jump host with RDP exposed to a tightly allowlisted set of admin IPs (home IP, office IP, on-call analyst's static IP — typically 3-5 entries). Not the production server. The jump host.
• Hardware MFA on the jump host RDP login. YubiKey or equivalent. If credentials leak, the attacker still can't log in.
• Brute-force protection on that jump host as a safety net. Even with allowlists and MFA, Event ID 4625 monitoring catches the case where an admin's home IP gets compromised.
• Quarterly drills. Actually use the break-glass path on a scheduled date. If you've never tested it, it doesn't exist.

This is the one case where direct RDP exposure is unambiguously correct. The trade-off is acknowledged, the surface is tiny, and it's the only thing standing between you and a 4 a.m. site-down with no way in.

Where does BruteFence fit in this picture?

BruteFence is the layer that handles point 1 across most of these situations: a small Windows agent that watches Event ID 4625, identifies brute-force patterns, and blocks source IPs at the Windows Firewall before credentials get guessed. It runs locally, with no cloud dependency, which matters for legacy boxes and for hosting customers who don't want third-party telemetry leaving their VM.

What it doesn't do, and what we say plainly: it doesn't replace a VPN, it doesn't add MFA, and it doesn't hide the fact that port 3389 is open. If you can put RDP behind Tailscale or RD Gateway with MFA, do that — it's a stronger control. BruteFence is the layer that keeps the brute-force noise from turning into a successful guess in the situations above where the stronger control isn't available.

The bigger picture is in how RDP brute force protection actually works in 2026. For a fully VPN-less deployment, you want defense-in-depth: NLA on, lockout policy configured, geo-block where it makes sense, brute-force monitoring active, and a real plan to migrate to VPN-fronted access when the situation allows.

The situations in this article aren't excuses to skip the ideal. They're acknowledgments that a working partial defense, applied today, beats a perfect plan that ships in nine months.

If you want to see what's happening on your server right now, try BruteFence free for 7 days.