Join our Newsletter — 33% off our NHI Course

Notifications
Clear all

NTLM deprecation and relay risk: are your controls ready?


(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 18936
Topic starter  

TL;DR: Microsoft’s February 2026 Patch Tuesday covers 59 CVEs, including six actively exploited zero-days, while Expel’s analysis argues that NTLM’s 2026 deprecation is overdue because its weak cryptography, pass-the-hash exposure, and lack of mutual authentication still enable lateral movement. Legacy authentication remains a live identity security problem, not a history lesson.

NHIMG editorial — based on content published by Expel: February Patch Tuesday and the NTLM long goodbye

By the numbers:

Questions worth separating out

Q: What breaks when NTLM is still enabled in Active Directory?

A: NTLM preserves a replayable trust path that attackers can abuse once they obtain cached hash material from a compromised endpoint.

Q: Why do legacy authentication protocols increase lateral movement risk?

A: They allow attackers to reuse captured authentication material instead of forcing a fresh, mutually verified login.

Q: How can security teams know whether NTLM is still actually needed?

A: They should inventory applications, devices, and service accounts that still generate NTLM traffic, then test whether Kerberos, local KDC, or IAKerb can replace that dependency.

Practitioner guidance

  • Inventory every remaining NTLM dependency Enable NTLM auditing through group policy and review domain controller logs for legacy applications, service accounts, printers, scanners, and local accounts that still rely on NTLMv1 or NTLMv2.
  • Prioritise relay-resistant hardening while migration is underway Enforce SMB signing and extended protection for authentication on systems that cannot be migrated immediately, so relay attempts are less likely to succeed during the deprecation window.
  • Migrate fallback accounts to Kerberos-capable paths Use local KDC and IAKerb where required so local and non-domain joined scenarios can authenticate without preserving NTLM as the default fallback.

What's in the full article

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

  • A phased NTLM deprecation plan with the specific event IDs and policy settings used to find residual usage.
  • Practical guidance for handling legacy applications, printers, scanners, and local accounts that still depend on NTLM.
  • The Microsoft-authored replacement paths for local KDC and IAKerb, including when each fits.
  • Hardening guidance for SMB signing and extended protection for authentication during the transition period.

👉 Read Expel’s analysis of NTLM deprecation and February Patch Tuesday risk →

NTLM deprecation and relay risk: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 3 months ago
Posts: 18527
 

NTLM persistence is a governance failure, not just a protocol legacy. Organisations that still allow NTLM are maintaining a fallback authentication path that attackers can abuse long after the original business need has faded. The real problem is not that NTLM exists in the codebase, but that identity teams have not fully mapped which accounts, devices, and applications still depend on it. Practitioners should treat residual NTLM use as unmanaged identity exposure, not as harmless technical debt.

A few things that frame the scale:

A question worth separating out:

Q: What is the difference between hardening NTLM and removing it?

A: Hardening reduces exposure by adding controls such as SMB signing and extended protection for authentication, while removal eliminates the fallback protocol entirely. Hardening is a transition step, but it does not solve the core problem if NTLM remains broadly available in production.

👉 Read our full editorial: Microsoft’s NTLM deprecation shows why legacy auth must go



   
ReplyQuote
Share: