Topic starter
20/08/2026 5:21 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Expel: “Patch Tuesday: February 2026 (Expel’s version)”.
By the numbers:
- This February’s Patch Tuesday includes 59 CVEs.
Key questions
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 relay risk?
A: Legacy authentication increases relay risk when the client proves itself without the server proving it is genuine.
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
- Build an NTLM inventory Enable NTLM auditing through Group Policy and review domain controller logs to identify legacy applications, service accounts, and devices that still depend on NTLMv1 or NTLMv2.
- Prioritise relay-hardening controls Enforce SMB signing and extended protection for authentication on systems that must remain compatible while you reduce NTLM exposure.
- Create an NTLM removal roadmap Move identified dependencies to Kerberos or a modern identity provider, then disable NTLM by default once exceptions are documented and owned.
Bottom line: NTLM remains a live security issue because its trust model still enables replay and relay in Windows environments that have not fully moved on.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:12 pm
NTLM deprecation is really a governance correction for a broken trust model. NTLM was designed for an era when the client-server relationship was simpler and the threat model less hostile. The protocol’s one-way trust, hash validation, and relay exposure make it unsuitable for modern identity governance, especially where access boundaries must be explicit and verifiable. The practitioner takeaway is that legacy authentication should be managed as a lifecycle risk, not tolerated as an exception forever.
A few things that frame the scale:
- 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do with local accounts that still depend on NTLM?
A: Organisations should move local-account use cases to Kerberos alternatives such as local KDC or IAKerb where possible, then treat any remaining NTLM requirement as a temporary exception with a named owner. The key decision is whether the access path can be preserved without leaving hash replay and relay exposure in place.
👉 Read our full editorial: Microsoft’s NTLM deprecation shows why legacy auth must go