Michael Narehood
Plenty of SMBs still live on Remote Desktop: line-of-business apps, a session host, someone logging in from home on a laptop that is not joined to the domain. That is fine until RDP is exposed straight to the internet on port 3389, protected by a password that showed up in a breach list. A gateway (RD Gateway on Windows Server or an equivalent TLS front door) is the minimum civilized setup, but the gateway alone is not a security program.
These habits assume you already need RDP for a reason you cannot eliminate this quarter. The steps keep it usable for staff and vendors without turning it into a permanent hole.
1. Never publish RDP directly to the internet
Block inbound 3389 at the firewall. Full stop.
Staff and vendors should hit an RD Gateway (or VPN / Zero Trust app) that terminates TLS, enforces who can connect, and forwards sessions to internal hosts. If you are still port-forwarding to a desktop, schedule a fix before you schedule anything else.
2. Require modern auth in front of the session
Pair the gateway with identities you can manage:
- Individual accounts, not
remote/shopshared logins - MFA on the account or upstream VPN / access product
- Account lockout and logging enabled; someone should notice repeated failures
If MFA is too much friction for every user today, start with accounts that can reach domain controllers, ERP, or accounting systems.
3. Limit who can reach which host
RD Gateway authorization policies should map users to specific internal servers, not “anyone authenticated can RDP anywhere on the LAN.”
Document allowed paths:
- Which users → which server names
- Whether clipboard and drive redirection are allowed (often no for vendors)
- Session idle timeout that actually disconnects
Vendor access gets narrower rules and shorter timeouts than employees.
4. Patch the gateway and the targets
Gateway servers and session hosts need the same patch discipline as domain controllers. Missing cumulative updates on RD Gateway has been a real entry path in plenty of incidents.
Include:
- Windows updates on gateway and RDS hosts
- TLS settings that deprecate old protocols
- Removal of local admin rights for everyday RDP users where the app allows it
5. Log and review monthly
Turn on connection logging you can read:
- Who connected, from which source IP, to which resource, when
- Failed auth attempts ( spikes matter )
- Concurrent sessions that do not match known work patterns
You are not building a SOC. You are making sure a forgotten vendor account is obvious.
6. Have an exit plan for legacy RDP
RDP is a bridge, not a forever architecture. Note in your documentation:
- Which apps still require it
- Target dates to move each app to SaaS, AVD, or a managed remote app model
- Who approves new RDP dependencies (default answer: nobody without a written exception)
Saying “we will always RDP to the server” is how that server becomes the company.
Bottom line
Keep RDP off the public internet, front it with a gateway, enforce MFA and per-user authorization, patch the RDS stack, and review logs often enough to catch stale access. Small shops can run Remote Desktop safely when it is scoped, logged, and treated as temporary infrastructure, not a permanent front door.