Most RDP compromises do not start with a zero-day. They start with a listener that should not have been reachable, an authentication handshake that let an attacker probe credentials before proving anything, or a disconnected session that sat open for three days with a mapped drive still attached. RDP hardening is less about one silver-bullet setting and more about closing five or six gaps that, individually, look minor.
Exposure Inventory: Which Hosts Really Listen on 3389 and Who Can Reach Them
Before touching a single Group Policy object, find out where RDP actually listens. Configuration intent and runtime reality drift apart constantly: a firewall rule gets a temporary exception during an incident and is never removed, a cloud security group is cloned from a template that allows 0.0.0.0/0 on port 3389, or a contractor’s jump box gets a public IP during a migration and keeps it.
Run an authenticated internal scan for TCP 3389 across every subnet, not just the ones you expect to have RDP. A quick unauthenticated pass with nmap -p 3389 --open -sV tells you what is listening; cross-reference the results against your asset inventory to flag anything that should not be there, especially devices outside the intended admin VLAN. For cloud estates, pull every security group and NSG rule that mentions port 3389 or 3389-3390 and check the source CIDR, not just the rule name. A rule labeled “admin-access” with a source of 0.0.0.0/0 is a finding regardless of what it is called.
Separate the inventory into three buckets: hosts that should never expose RDP directly to anything but a bastion or RD Gateway, hosts that are legitimately jump hosts, and anything unaccounted for. That third bucket is where ransomware affiliates buying initial access on criminal forums usually land first, because internet-facing RDP with weak or reused credentials remains one of the most searched-for access categories on those markets. Continuous discovery matters here more than a one-time audit, since new instances, cloned VMs and forgotten lab boxes reopen the same exposure a week after you closed it. This is the kind of recurring check that attack surface and network reachability visibility is meant to catch automatically rather than during the next scheduled audit.
Network Level Authentication, TLS Settings and Certificate Handling
Network Level Authentication (NLA) forces the client to authenticate via CredSSP before a full RDP session is established, instead of loading the logon UI first and authenticating afterward. This is not a cosmetic difference: several wormable RDP vulnerabilities, including CVE-2019-0708 (BlueKeep), relied on reaching the pre-authentication session negotiation code path. NLA does not eliminate every remote code execution risk in RDP, but it removes a large class of pre-auth attack surface and should be treated as a non-negotiable baseline, not an optional hardening step.
Enable it via Group Policy: Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security > Require user authentication for remote connections by using Network Level Authentication, set to Enabled. The equivalent registry value is HKLMSYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-TcpUserAuthentication set to 1 (DWORD). Verify it took effect with:
Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices | Select UserAuthenticationRequired
Alongside NLA, set the transport security layer to TLS only rather than the legacy RDP security layer or “Negotiate.” In the same GPO branch, set Require use of specific security layer for remote (RDP) connections to SSL (TLS 1.0), which corresponds to SecurityLayer = 2 under the RDP-Tcp key. Pair it with Set client connection encryption level at High (MinEncryptionLevel = 3).
Certificate handling is the part teams skip. A self-signed or auto-generated certificate on the RDP listener trains users to click through a “cannot verify identity” warning every single session, which trains them to click through it for a genuinely spoofed listener too. Issue a proper certificate from an internal CA with the host’s FQDN in the SAN, bind it via Set-RDCertificate or the RD Session Host configuration console, and confirm the thumbprint matches on both the host and any RD Gateway in front of it. If a warning still appears after that, treat it as an incident-worthy anomaly, not background noise.
Restricted Admin Mode and Remote Credential Guard: Which One Fits Admin Workflows
Both features exist to stop full credentials from landing in LSASS memory on a target machine, but they solve it differently and the choice depends on how much you trust the target host.
Restricted Admin mode (mstsc /admin /restrictedAdmin) connects using a network logon rather than an interactive one. No reusable credential material is delegated to the target, so if that box is later found to be compromised, an attacker who was on it during your session cannot lift your password hash or ticket to pivot onward with your identity. The tradeoff is that the target itself cannot use your credentials to reach a third system, so admin scripts that need double-hop access (for example, RDP into a host and then run a command against a file share as you) will fail silently or prompt for credentials again.
Remote Credential Guard (mstsc /remoteGuard) takes a different approach: Kerberos ticket requests from the session are redirected back to your client rather than processed on the target, so your credentials never touch the target’s memory at all, and double-hop scenarios keep working because the client is still brokering the requests. It requires Kerberos (no NTLM fallback) and both endpoints on Windows 10 / Server 2016 or newer.
The practical rule: use Restricted Admin when connecting to a host you do not fully trust, such as a potentially compromised server during incident response or a shared jump box with mixed workloads. Use Remote Credential Guard for routine administration of trusted, fully patched infrastructure where multi-hop workflows are common. Enforce the choice centrally rather than leaving it to muscle memory, via Computer Configuration > Administrative Templates > System > Credentials Delegation > Restrict delegation of credentials to remote servers, which lets you require Restricted Admin or Remote Credential Guard mode and refuse plain delegation entirely.
Session Policies That Matter: Idle Limits, Disconnected Sessions, Clipboard and Drive Redirection
A disconnected session is still a live logon token sitting on the host. It survives reboots of the client, VPN drops and forgotten laptops, and it is exactly what an attacker who steals a workstation’s session cookie or hijacks a network path is looking for.
| Setting | GPO path (Session Time Limits) | Suggested value |
|---|---|---|
| Idle session limit | Set time limit for active but idle RDS sessions | 15 minutes for standard users, 10 minutes for privileged tiers |
| Disconnected session limit | Set time limit for disconnected sessions | 1 hour for standard workloads, immediate logoff for Tier 0/1 admin sessions |
| Broken/timed-out session action | Set time limit for active RDS sessions | End session rather than disconnect, for admin-tier hosts |
Redirection channels deserve equal attention because they are a data path, not just a convenience feature. Clipboard redirection lets malware on either end move payloads across the session boundary in both directions; drive redirection lets an attacker on a compromised RDP source machine copy tooling onto a target, or stage stolen data the other way, without touching the network at all. Disable both by default on anything that is not an explicitly approved file-transfer path: Do not allow Clipboard redirection and Do not allow drive redirection, both under Remote Desktop Session Host > Device and Resource Redirection. If a workflow genuinely needs drive redirection, scope it to a single approved share via drivestoredirect rather than allowing all local drives.
Account Controls: Deny Log On Through Remote Desktop Services for Tiered Admin Accounts
If your Domain Admins or Tier 0 service accounts can RDP into a Tier 1 application server, your tiering model is decorative. The single most effective control here is explicit denial, not just omission from an allow list: add the Domain Admins, Enterprise Admins and any Tier 0 admin groups to Deny log on through Remote Desktop Services on every host outside Tier 0, via Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
Order of precedence matters: deny rules override allow rules in the same right, so a Tier 0 admin who is also a member of a lower-tier support group is still blocked, which is the intended behavior. Push this out through your tiering GPOs rather than local security policy so imaging and re-provisioning cannot silently drop it. Audit compliance with a targeted query rather than trusting the policy report:
whoami /groups | findstr /i "Domain Admins" Get-ADGroupMember "Domain Admins" | Get-ADUser -Properties LastLogonDate
and cross-check any recent logons against event ID 4624 with logon type 10 (RemoteInteractive) on hosts outside the Tier 0 boundary.
Watching for Drift After Gateway Changes, Imaging and Third-Party Remote Tools
Hardening decays. Three sources account for most of the drift teams see: golden images that predate the current GPO baseline and get deployed without a fresh policy refresh, RD Gateway or VPN concentrator changes that inadvertently open a direct path to a host that was previously reachable only through the gateway, and third-party remote access tools installed outside change control. TeamViewer, AnyDesk and similar tools bypass every RDP-specific control described above entirely, since they tunnel out over HTTPS and do not touch port 3389 at all. An inventory that only checks 3389 will miss them.
Build a recurring check rather than a one-time hardening pass: rescan for new 3389 listeners weekly, diff RD Gateway connection authorization policies against the last known-good baseline after any change ticket, and alert on new remote-access executables appearing outside your approved software list. Platforms that automate this kind of fleet-wide re-check, such as SITEY, re-test the specific finding after a patch or config change instead of assuming a closed ticket stayed closed, which is exactly the gap that lets a hardened RDP listener quietly regress after the next imaging cycle. Pair the technical checks with the event log side: 4778/4779 for session reconnect/disconnect, and a baseline of which accounts normally log on interactively to which host, so a Tier 0 account showing up with logon type 10 on a Tier 2 server triggers review the same day, not during the next quarterly audit.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.