RDP Security in 2026: NLA, Certificates, and Account Lockout Settings That Stop Brute Force

Expose a Windows Server’s RDP port to the internet and you will see brute-force attempts within minutes — typically 5,000 to 20,000 failed logins per day on a plain 3389 endpoint. The good news: three settings neutralize the overwhelming majority of those attacks, and all three are built into Windows Server with no third-party software. This article covers Network Level Authentication (NLA), RDP server certificates, and account lockout policies — what each one actually stops, and the exact settings to apply.

1. Network Level Authentication (NLA)

NLA forces the client to authenticate before a full remote desktop session is created. With NLA off, an attacker completes the RDP handshake and reaches the Windows logon screen, which historically enabled the “BlueKeep”-class vulnerabilities and lets attackers hammer the credential prompt with far less noise. With NLA on, the connection is rejected unless the client presents valid credentials up front.

NLA is enabled by default on Windows Server 2022/2025, but templates and imaging pipelines occasionally disable it. Verify it two ways:

• GUI: System Properties → Remote → “Allow connections only from computers running Remote Desktop with Network Level Authentication” must be checked.
• Registry: HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp — UserAuthentication should be 1 and SecurityLayer should be 2 (TLS).

If your RDP client is older than Windows 8 / macOS 10.12, NLA will refuse it — that is a feature, not a bug; those clients are exactly what you want to keep out.

2. RDP server certificates

By default the RDP service uses a self-signed certificate, which means the client cannot verify it is talking to your server and not a machine-in-the-middle. Certificate pinning fixes that: install a certificate trusted by your clients (from an internal AD CS, or a public CA) and force the RDP service to use it.

1. Request a certificate with the server’s DNS name in Subject/SAN — a public CA cert or an internal CA works.
2. Install it into the Local Machine → Personal store.
3. Pin it to RDP via WMI: $cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -like "*your-server-dns*"}; (Get-WmiObject -Class Win32_TSGeneralSetting -Namespace root\cimv2\TerminalServices -Filter "TerminalName='RDP-tcp'").SetSSLCertificate($cert.Thumbprint)
4. Verify with qwinsta (no effect) and on the client: the certificate name should match the server and show as trusted, with no “identity cannot be verified” warning.

For fleets, do this with Group Policy: Computer Configuration → Policies → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Security → “Server authentication certificate template” — set it to a template issued by your CA. Renew before expiry; an expired pinned cert silently breaks RDP for everyone.

3. Account lockout and access restriction

Lockout policies stop password guessing at the source. Apply these via Group Policy → Computer Configuration → Windows Settings → Security Settings → Account Policies → Account Lockout Policy:

Setting	Recommended value	Why
Account lockout threshold	5 failed attempts	Below 5, typos lock people out; above 10, brute force gets too many tries
Account lockout duration	15–30 minutes	Short enough to not disrupt work, long enough to stall distributed attacks
Reset account lockout counter	15 minutes	Prevents “slow drip” guessing over hours
RDP access list	Only the “Remote Desktop Users” group	Administrators are not automatically excluded — remove them or gate via a separate group

Two more cheap wins: (1) change the RDP port from 3389 — cosmetic against port scans but it kills most automated noise; (2) restrict source IPs in the firewall/security group to your office or VPN range, which is the single most effective control of all. Watch for lockout denial-of-service: an attacker who knows your admin account can lock it repeatedly, so keep a second break-glass account outside the policy and monitor Event ID 4740 (account locked out).

Monitoring and verification

• Failed logins: Event ID 4625 (Security log). Successful RDP logins: Event ID 4624 with Logon Type 10.
• Quick audit: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 50 | Select TimeCreated, @{n='User';e={$_.Properties[5].Value}}
• Confirm NLA state: Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" | Select UserAuthentication, SecurityLayer

One more layer worth naming: routing RDP through a VPN or RD Gateway instead of exposing 3389 at all. An RD Gateway terminates TLS on 443, hides the session host, and lets you enforce MFA at the gateway — the settings above still apply, but the attack surface shrinks from “the whole internet” to “your gateway’s TLS endpoint.” For single servers, a WireGuard or SSTP VPN with RDP bound to the VPN interface only is the strongest configuration you can build with built-in tools, and it makes the lockout policy almost redundant in practice.

Putting it together

NLA removes the pre-auth attack surface, certificate pinning defeats interception, and lockout policy makes guessing impractical — together they convert a screaming-open port into a boring one. Apply all three before the server ever gets a public IP, and you can skip most of the “RDP honeypot” anxiety. When you are choosing where to run that server, our Windows VPS comparison table flags providers that include firewall and DDoS protection in the base plan, and the feature list on our Windows VPS page shows which plans let you set security groups per IP — worth having when 3389 has to face the internet.