Network Level Authentication and RDP Security

Updated: October 2026

Remote Desktop is still how a lot of Windows servers get fixed, and every open RDP listener is a login screen someone else can knock on. The difference between a hardened host and an easy target often comes down to a few Group Policy settings and whether anyone checked they stuck. This guide covers what network level authentication does, how to enforce it across a fleet, the errors it throws, and the RDP hardening that has to sit around it.

What Network Level Authentication Does

Network Level Authentication (NLA) makes a user prove who they are before the server builds a Remote Desktop session. Without it, the host accepts the connection, spins up a session and draws a Windows logon screen for anyone who asks. With it, the client hands over credentials first, and only a verified user gets a session.

The handshake runs over CredSSP, the Credential Security Support Provider. The client authenticates with Kerberos or NTLM inside a TLS channel, and the server checks the result before it commits memory, CPU and a desktop to the caller. Microsoft's own guidance puts it plainly: with NLA enabled, "users must authenticate themselves before a remote session is established" (Microsoft Learn, updated February 2026).

That ordering matters for two reasons. An unauthenticated caller never reaches the code that renders sessions, so bugs in that code are harder to reach. And a flood of anonymous connections can't make the server build hundreds of logon screens.

Microsoft recommends keeping NLA on and turning it off only temporarily for older clients that can't use it. In practice the setting gets switched off to get one old client or one odd gateway working, and it tends to stay off.

Why NLA Matters: BlueKeep and the Pre-Auth Problem

The clearest case for NLA is BlueKeep, CVE-2019-0708. Microsoft patched it in May 2019. It was a remote code execution flaw in Remote Desktop Services that an unauthenticated attacker could trigger by sending crafted requests over RDP. It hit Windows 2000 through Windows 7 and Server 2008 R2, and Microsoft shipped patches even for Windows XP and Server 2003, long out of support.

CISA's June 2019 alert called BlueKeep "wormable", able to spread from one vulnerable system to the next the way WannaCry did in 2017. Its advice included enabling NLA, because doing so "forces a session request to be authenticated" and the exploit needed an unauthenticated session (CISA AA19-168A).

Read the fine print on that mitigation. NLA moves a pre-auth bug behind a login, so anyone holding valid credentials is past the gate. Treat it as a speed bump for mass scanning. The fix for BlueKeep was the update, and NLA bought time for hosts that couldn't take it yet.

The same logic applies to RDP threats today, where credentials are the other way in. CISA's advisory on BlackSuit (formerly Royal) ransomware lists RDP compromise as the second most common initial access vector, at around 13.3% of incidents, behind phishing (AA23-061A, updated August 2024). NLA doesn't stop a correct password. That's what the layers further down this guide are for.

How to Enable and Enforce NLA With Group Policy

On one machine, the switch lives in Settings > System > Remote Desktop, under "Require devices to use Network Level Authentication to connect." Across a domain, set it once in Group Policy so nobody can quietly untick it:

1. Open the GPO linked to your server and workstation OUs.
2. Go to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.
3. Enable "Require user authentication for remote connections by using Network Level Authentication."
4. In the same folder, set "Require use of specific security layer for remote (RDP) connections" to SSL, so the session runs over TLS.
5. Run gpupdate /force on a test host, then verify the value on the host itself (the check is in the exposure section below).

Step 5 is the one that gets skipped. A GPO only works where it applies, and hosts outside the domain, in the wrong OU, or blocked from inheritance keep whatever setting they had. If you manage a lot of servers from one console, such as RDCMan, the connection list is a ready-made inventory of hosts to verify.

Expect one or two exceptions. RDP proxies, older thin clients and some third-party gateways don't speak CredSSP. The thread below is a typical case. The safer answer scopes the exception to that one host and puts a gateway in front of it, while NLA stays on everywhere else.

Common NLA Errors and What They Mean

"The remote computer that you are trying to connect to requires Network Level Authentication (NLA), but your Windows domain controller cannot be contacted to perform NLA" is the classic. The client can't finish the credential check, so it never gets a session. Common causes are a host that can't reach a domain controller, a broken machine trust relationship, clock skew that breaks Kerberos, or a password that has expired or must be changed at next logon. NLA can't show the password-change prompt, because that prompt lives inside the session it hasn't built yet.

The second one ends with "This could be due to CredSSP encryption oracle remediation." It traces back to CVE-2018-0886, a CredSSP flaw that could let an attacker relay user credentials to run code on the target. Microsoft patched it on March 13, 2018, added the error message on April 17, and on May 8, 2018 changed the default "Encryption Oracle Remediation" policy from Vulnerable to Mitigated (Microsoft Support). A patched client talking to an unpatched server gets refused.

The fix is to patch the side that's behind. Setting the policy to Vulnerable makes the error go away and reopens the hole the patch closed, so treat it as a minutes-long workaround at most.

The quickest fix for either error is unticking the NLA box, which is why the box keeps ending up unticked.

RDP Hardening Beyond NLA

NLA is one layer. These are the others, roughly in the order they cut risk:

• Keep RDP off the internet. No port forward from the firewall to 3389, on any port number. If you're unsure what a forward exposes, our port forwarding guide walks through it.
• Put a gateway in front. RD Gateway wraps RDP in HTTPS and gives you one place to log and restrict access. A VPN or a zero-trust access tool does the same job from a different angle.
• Add MFA at the gateway. NLA checks a password. MFA checks that the password belongs to the person typing it.
• Lock out repeated failures. Microsoft's Windows security baselines recommend an account lockout threshold of 10 failed attempts.
• Don't hand your credentials to the host. Restricted Admin mode and Remote Credential Guard keep reusable credentials off the server you connect to.

The gateway choice often overlaps with the wider question of how techs reach client machines at all. Our roundup of remote access software covers the options that avoid exposing RDP in the first place.

Lockout thresholds only help if the passwords behind them aren't on a spray list. The brute-force and password-spray section of our common passwords guide covers how those attacks pick targets.

Restricted Admin and Remote Credential Guard need a word of care. Remote Credential Guard redirects Kerberos requests back to your device, so credentials never reach the host, and you still get single sign-on onward. It's Kerberos only, needs an Active Directory joined target, and doesn't work through RD Gateway or a Connection Broker. Restricted Admin sends no credentials at all, and the session reaches onward as the host's own identity. Microsoft recommends Restricted Admin for helpdesk connections, paired with LAPS (Microsoft Learn, updated March 2026). Start a session with mstsc.exe /remoteGuard or mstsc.exe /RestrictedAdmin, or force one with the client policy "Restrict delegation of credentials to remote servers."

How to Check Your RDP Exposure

Start with the setting itself. On each host, this PowerShell returns 1 when NLA is required and 0 when it isn't:

powershell
(Get-CimInstance -Namespace root\cimv2\TerminalServices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").UserAuthenticationRequired

Run it across every client's servers and workstations, not only the ones in the GPO's scope, and collect the zeros. OpenFrame can run a script like this across a client's devices and collect the output in one place, which turns a GPO you hope applied into a list you can read.

Then check from the outside. Scan each client's public IPs for 3389 and any custom RDP port, and read the firewall's NAT rules for forwards nobody remembers adding. Anything you find there matters more than any setting on the host.

Finally, read the logs. Failed RDP logons land in the Security log as event 4625, and the 13Cubed walkthrough below shows how an NLA logon shows up there and why a failure can look different from what you'd expect:

Network Level Authentication, in Short

NLA makes Remote Desktop check credentials before it builds a session. That closed the door on BlueKeep-style pre-auth bugs and still cuts the noise from anonymous scanning. It doesn't stop a stolen password, so pair it with no internet exposure, a gateway with MFA, lockout, and Restricted Admin or Remote Credential Guard. Enforce it by GPO, verify it on every host, and patch instead of downgrading CredSSP when the errors show up.

Next, see how techs can reach client machines without opening RDP at all, in our guide to remote access software.