Publishing TCP port 3389 directly to the internet makes Remote Desktop Protocol a constant target for password attacks, vulnerability scanning, and stolen-credential abuse. Changing the port does not solve the exposure. A safer design places RDP behind an authenticated VPN, a Remote Desktop Gateway, or a zero-trust access service and allows connections only from that controlled path.
Choose the Access Architecture
For a home or small office, a WireGuard VPN is usually straightforward: the remote device authenticates to the tunnel, then connects to the private Windows address. An organization already using Microsoft infrastructure may prefer Remote Desktop Gateway over HTTPS with Network Policy Server and MFA. A managed zero-trust connector can provide application-specific access without a broad network route.
The design should avoid any public forwarding rule to the Windows host. It should also provide an emergency administrative path, centralized revocation, and logs that connect a person to a session.
Remove Direct Internet Exposure
- Identify router, firewall, cloud security-group, and provider-level rules that forward or allow RDP.
- Verify the VPN or gateway from an external network before removing the old rule.
- Delete the public 3389 rule and confirm with an external port test that the address is closed or filtered.
- Check for alternate port mappings that still forward to 3389 internally.
- Document the change and rollback path.
Do not rely only on Windows Firewall if an upstream device still exposes the service. Defense in depth matters, but the outer boundary should reject unsolicited RDP.
Restrict Windows Firewall to the Trusted Path
Enable the built-in Remote Desktop rules only on the appropriate network profile and limit their remote address scope to the VPN subnet or gateway. If the tunnel uses 10.77.40.0/24, the inbound rule should not accept every address.
Keep Network Level Authentication enabled. NLA requires authentication before a full desktop session is created, reducing resource use and exposure. Disable legacy clients that cannot support your required authentication level rather than weakening the entire host.
Strengthen Accounts and Authentication
- Use named user accounts; do not share one administrator password.
- Grant Remote Desktop access only to people who need it.
- Use standard accounts for routine work and separate elevation credentials.
- Deploy MFA at the VPN, gateway, or identity-aware access layer.
- Set lockout and password policies appropriate to the environment.
- Disable stale accounts promptly and review group membership.
MFA on the access layer is essential but does not excuse weak local credentials. A compromised endpoint already inside the tunnel can still attempt Windows authentication.
Limit Network Reach
A remote-access VPN should not automatically open the entire LAN. Allow each user or device to reach only required hosts and ports. Separate administrative access from general remote work where possible. For a WireGuard deployment, unique device peers and narrow firewall rules make revocation and investigation easier.
Our Windows WireGuard setup guide covers keys, routes, DNS, and validation. The MikroTik WireGuard server guide shows how to restrict forwarding at the router.
Harden the Windows Host
Keep Windows and Remote Desktop components updated. Enable BitLocker on portable and sensitive systems, protect recovery keys, and configure endpoint protection. Disable clipboard, drive, printer, or device redirection when the workflow does not need it. These features are useful but expand data-transfer paths.
Set an idle session timeout and disconnect abandoned sessions. Back up critical data independently of the host. RDP access is not a recovery strategy, and ransomware that reaches the system may also reach attached or redirected storage.
Monitor Successful and Failed Access
Windows Security logs record relevant authentication events, while Terminal Services logs add session detail. Monitor repeated failures, unexpected source addresses, logins outside normal times, new group membership, and successful access after a failure burst. Centralize logs if the host is important enough that local tampering would hinder an investigation.
Use our Event Viewer failed-login guide to interpret event IDs and logon types. Tune alerts to the expected VPN subnet so random local noise does not hide meaningful events.
Validate the Complete Control Chain
- From the public internet, confirm that direct RDP is unavailable.
- Connect through the approved VPN or gateway with MFA.
- Confirm that an authorized account can reach only its intended system.
- Verify that an unauthorized account and an unauthorized network source are denied.
- Check that both the access layer and Windows record the test.
- Test revocation by disabling a temporary peer or account.
Frequently Asked Questions
Is changing the RDP port enough?
No. It reduces basic noise but scanners find services on alternate ports. It does not add authentication, isolation, MFA, or protection against service vulnerabilities.
Is a VPN alone sufficient?
No. Use unique VPN identities, narrow routes, strong Windows accounts, updates, host firewall restrictions, monitoring, and ideally MFA. The VPN is one security boundary.
Should I disable RDP completely?
If it is not required, disable it. If it supports a real workflow, keep it behind a controlled access layer and test the controls regularly.
Final Recommendation
A secure RDP design has no public listener, authenticates the user before the Windows host is reachable, limits the route and firewall scope, uses named accounts and MFA, records activity, and supports rapid revocation. Test both permitted and denied paths after every network or identity change.
