Subscribe to the Non-Human & AI Identity Journal

What breaks when organisations rely on NLA as their main access control?

The main failure is coverage, not authentication quality. NLA can still protect RDP sessions, but it does nothing for SSH, databases, cloud tools, or service-driven access. That creates a false sense of control when the real access surface is spread across many systems.

Why This Matters for Security Teams

NLA is often treated as a control boundary when it is really only a gate on one protocol. The operational risk is not that NLA is weak at authentication, but that teams mistake RDP coverage for access governance across the rest of the environment. Once SSH, databases, cloud consoles, CI/CD systems, and service accounts sit outside that boundary, attackers and over-privileged operators can move through paths NLA never sees. The result is fragmented control, inconsistent review, and hidden standing access.

This is exactly why NHI governance focuses on the full identity surface, not one login path. The Ultimate Guide to NHIs frames the problem as identity sprawl across machines, services, and automation, while the OWASP Non-Human Identity Top 10 treats exposed or mis-scoped machine access as a primary risk class. In practice, many security teams discover the gap only after a credential reuse incident or lateral movement has already bypassed the one control they assumed was enough.

How It Works in Practice

NLA validates a user before the remote desktop session starts, which is useful for reducing unauthenticated RDP exposure. The problem is that modern environments rarely stop at interactive desktop access. Administrative work commonly happens through SSH bastions, database clients, cloud control planes, automation runners, and service-to-service APIs, each with different identity mechanics and different logging depth. NLA does not unify those controls.

For that reason, strong access control needs to move from protocol-specific authentication to identity-centric governance. Practitioners typically combine:

  • centralised inventory of human and non-human identities, including service principals and API keys;
  • least privilege enforced across all admin paths, not only RDP;
  • short-lived credentials and just-in-time elevation for privileged tasks;
  • session recording and command auditing where supported;
  • continuous review of standing access, especially for shared admin accounts.

That broader model aligns with the NHI research view that access should be tied to the workload or operator identity, not a single entry point. The 52 NHI Breaches Analysis shows how frequently identity misuse becomes the entry path once secrets or service access are exposed, and the Ultimate Guide to NHIs — Key Challenges and Risks highlights the operational drag created by identity sprawl. These controls tend to break down when organisations use NLA as a proxy for PAM, because non-RDP access paths then remain permanently outside review.

Common Variations and Edge Cases

Tighter protocol gating often increases operational friction, requiring organisations to balance easier administration against broader access coverage. That tradeoff becomes visible in mixed environments where some assets support NLA, some support other federated login methods, and some are still accessed with local accounts or embedded secrets. Best practice is evolving, but current guidance suggests treating NLA as one layer in a larger access model rather than the main control.

There is no universal standard for every environment yet, but the direction is clear: govern identities, not just sessions. That means treating service credentials, cloud tokens, and privileged automation as first-class access paths, even when RDP is locked down. For environments with many admin tools, PCI-oriented audit expectations can also reinforce the need to prove who accessed what and how, not just that an RDP login was challenged at the edge. The practical failure case is when a team can demonstrate NLA enforcement for desktops but cannot explain who still has direct SSH, database, or API access.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 NLA-only control leaves non-RDP identities and secrets outside governance.
NIST CSF 2.0 PR.AC-4 Access control must span every admin path, not just remote desktop sessions.
NIST AI RMF Autonomous and service-driven access needs governance beyond one protocol boundary.

Apply least privilege across SSH, cloud, database, and service access, then review entitlements regularly.