Notifications
Clear all
Topic starter
08/06/2026 4:51 pm
TL;DR: Network Level Authentication (NLA) reduces RDP exposure by requiring pre-session authentication, but it remains a single-protocol control with limited reach across SSH, Kubernetes, databases, and cloud access, according to StrongDM. The bigger lesson is that pre-authentication is only one slice of identity governance when access is multi-protocol and policy-driven.
NHIMG editorial — based on content published by StrongDM: What Is Network Level Authentication (NLA)? (How It Works)
Questions worth separating out
Q: How should security teams govern remote access when NLA only covers RDP?
A: Treat NLA as one control in a broader access model.
Q: Why do single-protocol controls fail in modern access environments?
A: They fail because identity activity no longer stays inside one protocol.
Q: What breaks when organisations rely on NLA as their main access control?
A: The main failure is coverage, not authentication quality.
Practitioner guidance
- Inventory every administrative access path Map where RDP is used alongside SSH, database tools, Kubernetes, and cloud consoles so protocol coverage gaps are visible before policy decisions are made.
- Separate transport controls from identity governance Keep NLA as an RDP safeguard, but govern standing privilege, credential scope, and approval workflows through your broader IAM and PAM processes.
- Standardise policy across remote access channels Apply one access model for Windows and non-Windows paths where possible, because inconsistent server-by-server settings create drift and exceptions.
What's in the full article
StrongDM's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step RDP configuration guidance for enabling and verifying NLA across Windows hosts.
- The article's comparison of RDP, SSH, Kubernetes, and database access paths in mixed environments.
- StrongDM's explanation of where its own access model claims to replace protocol-specific controls.
- Examples of real-world friction points for administrators managing remote access at scale.
👉 Read StrongDM's analysis of Network Level Authentication and remote access control →
Network level authentication and zero trust: where does it fall short?
Explore further
08/06/2026 6:43 pm
Protocol-bound authentication is a narrow trust boundary, not an access governance model. NLA enforces pre-session checks for RDP, but that control only governs one connection path. In a modern enterprise, users and systems move across RDP, SSH, databases, and cloud consoles, so the security boundary must follow the identity, not the protocol. Practitioners should read NLA as a transport safeguard, not as a substitute for unified access governance.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable for access drift when protocol-specific controls create exceptions?
A: The accountability sits with the teams that own identity policy, privileged access, and system configuration together. If NLA settings differ by server or environment, the organisation needs clear ownership for exception handling, review cadence, and enforcement consistency across the full access stack.
👉 Read our full editorial: Network level authentication is too narrow for modern access
