RDP Security

The real RDP risk model

Attackers almost never break RDP's encryption. They just authenticate, because it is easier. The dominant attack paths are credential attacks against reachable listeners (spraying, stuffing, brute force), phished or reused passwords, and lateral movement once a foothold exists. A secondary path is exploiting an unpatched protocol vulnerability outright; BlueKeep (CVE-2019-0708) showed exactly how bad that can get. The risk equation comes down to exposure × credential strength × authorization scope, which is exactly why hiding the port and calling it a day changes nothing.

Is RDP encrypted?

Yes, modern RDP is encrypted. The details matter more than the yes-or-no, though:

Transport. RDP runs over TCP and UDP 3389 (or HTTPS/443 through RD Gateway). On current Windows, the connection negotiates TLS (security layer "Negotiate" or "SSL/TLS") rather than the deprecated legacy "RDP Security Layer," whose native encryption is considered obsolete and should never be selected deliberately.

Authentication before encryption pays off. With Network Level Authentication enabled, the user authenticates via CredSSP before any session or logon screen exists. CredSSP protects the credential exchange inside the TLS channel; keeping it patched matters (the 2018 "encryption oracle remediation" errors traced to CVE-2018-0886 mismatches).

Encryption levels. Windows still exposes legacy per-session encryption levels: Low, Client Compatible, High, FIPS Compliant. These apply to the deprecated security layer, not the modern one. Once TLS is negotiated, which is the default today, TLS's own cipher suites govern the channel and that legacy level setting is mostly vestigial. FIPS-mode requirements are a separate compliance topic governed by FIPS 140-2, worth a dedicated look if that applies to your environment.

Certificate validation. By default, hosts present self-signed certificates, so users see a warning and click through it out of habit. That habit is the problem: it trains people to accept exactly the conditions a man-in-the-middle attack needs. Deploying trusted certificates, whether from an internal CA or a public one, actually restores the point of certificate validation, especially at gateway endpoints.

Why encryption alone is not security. Encryption protects data in transit. It does not stop a valid stolen password (identity risk), does not hide a listener from scanners (exposure risk), and does not limit what an authenticated account can reach (authorization risk). A fully encrypted, fully exposed, password-only RDP host is a fully attackable one.

RDP security in four layers

Defense stacks in four layers here. Identity: MFA in front of every session, a strong password policy, lockout on repeated failures. Exposure: nothing internet-facing on 3389, a gateway at minimum, outbound-only brokering if you can manage it. Authorization: least privilege, meaning per-user desktop entitlements and no shared admin credentials. Visibility: session logging, failed-logon monitoring, a patching cadence you actually stick to.

Best practices, the short version

The full implementation checklist (NLA settings, firewall rules, account policies, monitoring) lives in the how-to guide: How to better secure RDP on your network →. If you only do five things: require MFA, eliminate direct exposure, patch your hosts, scope access per user, and log everything.