What is Network Level Authentication?

Network Level Authentication (NLA) is a pre-authentication gate for Windows Remote Desktop. Before the familiar login screen ever renders, NLA forces the connecting client to prove who it is at the network layer using CredSSP. No session gets created, no memory gets allocated for a desktop, until that handshake succeeds. It sounds like a small detail. In practice it is one of the cheapest, highest-leverage security controls a Windows shop can flip on, and a surprising number of environments still don't have it enforced everywhere it should be.

This matters more in 2026 than it did when NLA first shipped, because remote access has quietly become the dominant way ransomware crews get their first foothold. According to Coalition's 2025 Cyber Claims Report, remote access services served as the entry point for 87% of ransomware claims the insurer paid out, with compromised remote desktop protocol specifically accounting for 18% of ransomware intrusions where the initial vector could be identified. Coalition's own network scanning also found more than 5 million internet-exposed remote-management endpoints across the public internet, a number that should make anyone running RDP on a default port a little uneasy. Robert Jones, Coalition's Head of Global Claims, summarized the shift in the report's release: 'Over the past year, our claims data clearly demonstrates one thing: Active Insurance works,' pointing to proactive exposure management, closing off things like open RDP, as the difference between a claim and a near miss.

How the NLA handshake actually works

When a client initiates a connection to a server with NLA enabled, the two sides negotiate before anything resembling a desktop session exists. The server presents a certificate, the client verifies it, generates a challenge, and encrypts that challenge with the server's public key. The server decrypts it with its private key, proving it holds the matching key pair, then prompts for credentials. Those credentials travel encrypted under a session key established during the negotiation. Only after the server validates them against its user store does an actual desktop session spin up.

The practical effect: an unauthenticated connection attempt never gets far enough to consume meaningful server resources or to reach a stateful RDP session that a vulnerability could target. This is exactly the mitigation path Microsoft recommends for several 2026 RDP-related CVEs, including one where restricting RDP to trusted networks and enforcing NLA is the primary guidance rather than a footnote.

Turning it on

NLA is not always enabled by default depending on your deployment history, and only members of the local Administrators group can configure it. On a single host:

1. Open Remote Desktop Session Host Configuration (search for it, or find it under Administrative Tools on older builds).
2. Under Connections, right-click the RDP-Tcp connection and choose Properties.
3. On the General tab, check 'Allow connections only from computers running Remote Desktop with Network Level Authentication.'
4. Click OK.

For a fleet, do not touch each box by hand. Push the equivalent Group Policy setting (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') to an OU, so the setting survives re-imaging and applies consistently. You can also verify the current state across many machines at once with a PowerShell one-liner against the registry key HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp, checking the UserAuthentication value: 1 means NLA is on, 0 means it isn't.

To confirm a machine supports NLA

1. Start Remote Desktop Connection.
2. Click the icon in the upper left corner of the dialog box, then click About.
3. Look for the phrase 'Network Level Authentication supported.'

Why this is worth the two minutes it takes

NLA's biggest win is closing off pre-authentication attack surface. A large share of automated exploitation attempts rely on reaching the login screen before any credential check happens. NLA removes that window. It also mitigates man-in-the-middle scenarios during the initial handshake, since the client validates the server's certificate before sending anything sensitive, and it reduces the blast radius of naive Denial of Service attempts, since the server isn't allocating full session resources to every random connection attempt that hits the port.

There's a second-order benefit that's easy to miss: NLA makes credential-guessing campaigns slightly less efficient, because an attacker has to get through the CredSSP negotiation before they can even attempt a login, rather than hammering a login prompt directly. That said, this is not the same as a lockout policy or MFA. NLA does not rate-limit anything on its own. Pair it with an account lockout threshold (a reasonable 2026 baseline is locking after five failed attempts for 15 to 30 minutes) and, ideally, multi-factor authentication in front of the whole thing. The urgency here is real: CrowdStrike's head of counter adversary operations, Adam Meyers, described the current pace of intrusions in the company's 2026 Global Threat Report by saying, 'Breakout time is the clearest signal of how intrusion has changed. Adversaries are moving from initial access to lateral movement in minutes.' An average eCrime breakout time of 29 minutes doesn't leave much room for a security team to catch and stop an attacker who's already past your front door.

Where NLA falls short (be honest about this)

• NLA is a network-layer pre-auth gate, not an identity or authorization control. A compromised but valid credential still gets a full session. Nothing about NLA stops that.
• Very old RDP clients that don't support CredSSP get locked out entirely once you flip this on. If you have a fleet with mixed client versions, test before you roll out broadly, or you'll generate a wave of help desk tickets.
• Certificate management at scale is genuinely annoying. Self-signed certs work but throw trust warnings; a proper internal CA is better but is its own project.
• NLA does nothing to protect RDP traffic that's still reachable from the open internet. It reduces the attack surface of what's exposed, it doesn't remove the exposure.
• It doesn't always play cleanly with certain SSO setups without extra configuration, particularly in mixed on-prem and cloud identity environments.

This last point is the one practitioners trip up on most: teams enable NLA, consider RDP 'secured,' and stop there. As SecureW2 puts it in their NLA breakdown, NLA has to be combined with identity-based and 802.1X-style controls rather than treated as a complete answer on its own. It's a floor, not a ceiling.

What NLA actually requires under the hood

The client device needs to support the CredSSP protocol (any reasonably current Windows build does). The host needs to be running a modern Windows Server release with RDP enabled. Both sides need working network connectivity through the negotiation phase, since latency or drops during that window can produce a confusing connection failure rather than a clean error. The server needs an SSL certificate to present during negotiation, and the client needs to trust it (or you accept the warning prompt, which is not great practice for anything beyond a lab). Firewalls on both ends need to allow the negotiation traffic, not just the final RDP stream.

Also read: What is Multi-Factor Authentication?

The bigger picture: NLA is one layer of a stack, not a silo

If your team still has RDP directly reachable from the internet, enabling NLA is a good start but it is not the fix. The fix, per Coalition's own guidance to policyholders, is getting RDP off the public internet entirely: close port 3389 at the firewall, put remote access behind a VPN or Remote Desktop Gateway, and layer Zero Trust Network Access or a Secure Access Service Edge approach on top if your organization can support it. Coalition's earlier threat research found that RDP-related traffic made up over a third of all traffic they observed from threat actors scanning the internet, which tells you how much automated attention any exposed RDP port draws before a human attacker ever gets involved.

Where this actually shows up in an incident: an admin opens port 3389 temporarily to troubleshoot something from home, forgets to close it, and a scanner finds it within hours. NLA buys you time and reduces noise in that scenario, but it does not replace closing the port. Treat NLA as table stakes, not a finish line, and build the rest of your remote-access controls, MFA, gateway isolation, monitoring, around it.

Roll NLA into your written remote-access policy, alongside the technical configuration itself. Make sure new server builds have it enabled by default, that your onboarding checklist for new admins covers it, and that whoever reviews new firewall rules knows to flag any RDP-adjacent exception for a second look.