Securing Remote Desktop and VPN Access Without Locking People Out

Remote access is where convenience and risk meet. Staff need to work from home, vendors need to reach a server, and the IT provider needs to fix things at night. Every one of those paths is also a path for an attacker with a stolen password.

The goal is not to make remote access painful. It is to make sure every remote session is tied to a known person on a known device, and that nobody can reach a login prompt on the internet by simply scanning for it.

Rule one: no RDP on the internet

Port 3389 open to the world is the most common finding in ransomware post-mortems and the easiest to fix. Scanners find it within hours, and password spraying starts immediately against every account on the domain. A single weak password on a service account is enough.

Check right now. From a machine outside your network, or from an online port scanner, test your public IP for 3389. Then check the firewall NAT table for any forward to that port, including forwards on non-standard external ports; changing 3389 to 33890 hides nothing from a full port scan.

1. Remove the port forward. There is no configuration of RDP directly on the internet that is acceptable.
2. Put RDP behind the VPN, or behind Remote Desktop Gateway, which wraps RDP in HTTPS and can require MFA through the NPS extension for Entra ID.
3. For cloud-first environments, Azure Virtual Desktop or Windows 365 puts the desktop in Azure with Conditional Access in front of it and no inbound ports on your network.
4. Enable Network Level Authentication on every host so the login happens before a session is created.
5. Restrict the Remote Desktop Users group. Administrators are in it by default; Domain Users should never be.

# Check RDP settings on a host
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication  # 1 = NLA required
Get-LocalGroupMember -Group 'Remote Desktop Users'

VPN: identity, MFA and device

A VPN is only as strong as its login. Local user accounts on the firewall with a password and no second factor are what most small business VPNs have, and that is one phished password away from an attacker on the LAN.

Tie the VPN to your identity provider so the same account, the same MFA policy and the same disable-on-departure apply. Every major firewall vendor supports RADIUS or SAML for this.

• SAML to Entra ID is the cleanest option where the firewall supports it: Conditional Access policies apply, including device compliance and location rules.
• RADIUS through Network Policy Server with the Entra MFA extension is the fallback for appliances without SAML.
• Certificate-based authentication for the device plus user MFA means a stolen password on a personal laptop gets nowhere.
• Pick a modern protocol: IKEv2 with certificates, or WireGuard where the appliance supports it. Retire PPTP and L2TP with pre-shared keys.

Vendors and IT providers

Third-party access is the part nobody documents. The copier company has a VPN account from 2019, the ERP vendor has a shared login, and the previous IT provider still has a firewall admin account. Each one is a credential you do not control.

Treat every external party as a separate identity with its own account, its own MFA, a scope limited to what they support, and an expiry date.

1. Inventory every external account on the VPN, the firewall, the servers and Microsoft 365. Disable anything nobody can explain.
2. Give each vendor a named account per technician, not a shared login. If they refuse, that is useful information.
3. Scope access with firewall rules: the ERP vendor reaches the ERP server on its port, nothing else.
4. Set accounts to expire. In Active Directory, Account expires on the Account tab. Renew on request.
5. Log sessions. Remote Desktop Gateway, most VPN appliances and privileged access tools record who connected when and to what.

Watch the logins

Once remote access is tied to identity, the sign-in logs become useful. An account logging in from two countries in an hour, a VPN session at 3 a.m. from a user who works days, or an account that has never used the VPN suddenly connecting: each is worth a phone call.

Entra ID sign-in logs cover anything behind SAML or the NPS extension. Firewall VPN logs cover the rest and should be forwarded to a syslog server or SIEM so they survive the firewall being wiped.

• Alert on VPN or RDP Gateway logins outside business hours for accounts that do not normally work then.
• Alert on impossible travel and on logins from countries you do not operate in; better, block those countries in Conditional Access and on the firewall.
• Review the list of VPN-enabled accounts monthly. Departed staff and finished vendors are the usual finds.

Frequently asked questions

Takeaway

Take RDP off the internet today, put the VPN behind your identity provider with MFA, give every vendor their own expiring account, and forward the logs somewhere you will look at them. Remote access done this way is no harder for staff and far harder for anyone with a stolen password.