Microsoft announced it will disable NTLM authentication by default in future Windows releases, ending a 33-year run for the protocol that first appeared in Windows NT 3.1 in 1993. The transition follows Microsoft formally deprecating NTLM in June 2024.
Announcement overview
| Attribute | Details |
|---|---|
| Protocol | NT LAN Manager (NTLM) |
| First introduced | Windows NT 3.1 (1993) |
| Formal deprecation | June 2024 |
| Replacement protocol | Kerberos |
| Status | Receives no updates since deprecation |
| Default disable target | Future major Windows release (unspecified) |
Why NTLM is being retired
NTLM has fundamental security weaknesses that cannot be fixed without breaking compatibility:
| Vulnerability | Impact | Severity |
|---|---|---|
| Relay attacks | Attackers forward NTLM authentication to other systems | Critical |
| Replay attacks | Captured credentials can be reused | High |
| Man-in-the-middle | Weak cryptography enables interception | High |
| Pass-the-hash | Hash alone sufficient for authentication | Critical |
| No mutual authentication | Server identity not verified | Medium |
| Weak encryption | DES-based cryptography | High |
“Today, NTLM is susceptible to various attacks, including replay and man-in-the-middle attacks, due to its use of weak cryptography.”
Despite being superseded by Kerberos for most scenarios, NTLM remains widely used as a fallback and in legacy environments. Attackers frequently abuse NTLM for lateral movement and credential theft—techniques like NTLM relay remain staples of penetration testing and real-world attacks.
Common NTLM attack techniques
| Attack | Description | Mitigation difficulty |
|---|---|---|
| NTLM relay | Forward authentication to another server | High without SMB signing |
| Pass-the-hash | Use captured hash directly | Requires Kerberos migration |
| Responder | Capture NTLM hashes on network | Requires network controls |
| LLMNR/NBT-NS poisoning | Trick systems into NTLM auth | Disable legacy protocols |
Three-phase transition
Phase 1: Enhanced Auditing (Available Now)
Available in: Windows Server 2025, Windows 11 24H2
Enhanced NTLM auditing tools help organizations identify where NTLM is still in use:
| Audit capability | Purpose |
|---|---|
| Application identification | Which apps trigger NTLM authentication |
| System dependency mapping | Which systems rely on NTLM fallback |
| Service inventory | Which services haven’t migrated to Kerberos |
| User identification | Which accounts use NTLM |
This audit data is the foundation for any NTLM migration effort. Organizations should deploy these tools immediately to understand their NTLM dependencies.
Phase 2: Addressing Migration Roadblocks (H2 2026)
Target: Second half of 2026
New features will address common scenarios that trigger NTLM fallback:
| Feature | Purpose | Impact |
|---|---|---|
| IAKerb | Extends Kerberos to scenarios previously requiring NTLM | Enables Kerberos without direct DC connectivity |
| Local KDC | Enables Kerberos for local accounts and workgroups | Removes major NTLM dependency |
| Component upgrades | Core Windows components negotiate Kerberos first | Reduces automatic NTLM fallback |
IAKerb enables Kerberos authentication when direct network connectivity to a domain controller is unavailable—a common scenario that previously forced NTLM fallback.
Local KDC allows local account authentication without forcing NTLM fallback on modern systems, addressing workgroup and non-domain-joined scenarios.
These improvements reduce legitimate NTLM dependencies, making the transition to “disabled by default” less disruptive.
Phase 3: NTLM Disabled by Default (Future Major Releases)
Target: Unspecified future Windows Server release and associated Windows client releases
Network NTLM will be disabled by default. Key clarification from Microsoft:
“Disabling NTLM by default does not mean completely removing NTLM from Windows yet. Instead, it means that Windows will be delivered in a secure-by-default state where network NTLM authentication is blocked and no longer used automatically.”
| What changes | What remains |
|---|---|
| NTLM blocked by default | NTLM code remains in Windows |
| No automatic NTLM fallback | Can be re-enabled via policy |
| Secure-by-default state | Legacy compatibility maintained |
NTLM will remain in the operating system and can be re-enabled through Group Policy or registry settings for environments that require it. IT administrators running software that absolutely requires NTLM will have an escape hatch.
NTLMv1 timeline
NTLMv1 (the oldest, weakest version) has an accelerated deprecation schedule:
| Date | Action |
|---|---|
| Already done | NTLMv1 removed from Windows 11 24H2 and Server 2025 |
| September 2025 | NTLMv1 attempts trigger audit events |
| October 2026 | NTLMv1 blocking enforced by default |
Organizations still using NTLMv1 face a hard deadline in October 2026.
NTLMv1 vs NTLMv2 comparison
| Aspect | NTLMv1 | NTLMv2 |
|---|---|---|
| Encryption | DES (56-bit) | HMAC-MD5 |
| Security | Critically weak | Weak but better |
| Status | Hard deadline Oct 2026 | Soft deprecation ongoing |
| Crackability | Minutes to crack | Hours to days |
What administrators should do now
1. Deploy enhanced auditing
Use the tools in Windows Server 2025 and Windows 11 24H2 to identify NTLM usage:
Group Policy path:
Computer Configuration → Windows Settings → Security Settings →
Local Policies → Security Options → Network security: Restrict NTLMKey audit settings:
| Setting | Purpose |
|---|---|
| Audit Incoming NTLM Traffic | Log NTLM authentications to this system |
| Audit NTLM authentication in this domain | Domain-wide NTLM tracking |
| Restrict NTLM: Audit NTLM in this domain | Detailed domain audit |
2. Map dependencies
Document which applications, services, and systems rely on NTLM:
| Category | Examples |
|---|---|
| Line-of-business applications | Legacy ERP, custom apps |
| Third-party software | Older vendor products |
| Legacy systems | Windows Server 2012 and earlier |
| Cross-forest trusts | Complex AD environments |
| Non-Windows clients | Linux, macOS, network devices |
| IP-based access | Apps using IP instead of hostname |
3. Plan migrations
Work with application vendors to update critical applications. Many NTLM dependencies exist because applications were never updated to support Kerberos, not because Kerberos can’t meet the requirement.
| Migration path | Scenario |
|---|---|
| Application update | Vendor provides Kerberos support |
| Custom development | Internal apps modernized |
| Replacement | Legacy system retired |
| Exception | Documented business justification for continued NTLM |
4. Test Kerberos-only scenarios
Use Group Policy to restrict NTLM in test environments and validate that critical workloads succeed with Kerberos authentication.
| Test phase | Actions |
|---|---|
| Lab testing | Restrict NTLM in isolated environment |
| Pilot group | Small production subset with monitoring |
| Staged rollout | Gradual expansion with rollback capability |
| Full deployment | Organization-wide NTLM restrictions |
Impact assessment
Low impact (already using Kerberos)
| Scenario | Status |
|---|---|
| Domain-joined Windows clients | Typically Kerberos already |
| Modern applications | Usually Kerberos-capable |
| Azure AD/Entra ID environments | Cloud identity, no NTLM |
| Web applications | HTTP-based auth, no NTLM |
Higher impact (may require remediation)
| Scenario | Challenge |
|---|---|
| Legacy applications | May require updates or replacement |
| Non-domain-joined machines | IAKerb/Local KDC addresses in Phase 2 |
| Cross-platform environments | Linux/macOS NTLM clients |
| Workgroup configurations | Local KDC addresses in Phase 2 |
| IP address authentication | Kerberos requires hostnames |
| Network attached storage | Many NAS devices use NTLM |
Recommendations
For IT administrators
| Priority | Action |
|---|---|
| Critical | Deploy Phase 1 auditing tools immediately |
| Critical | Inventory NTLMv1 usage before October 2026 deadline |
| High | Map NTLM dependencies across applications |
| High | Engage vendors for Kerberos support timelines |
| Medium | Plan test environment for Kerberos-only validation |
| Ongoing | Monitor Microsoft announcements for Phase 3 timeline |
For security teams
| Priority | Action |
|---|---|
| High | Use NTLM restrictions to reduce attack surface now |
| High | Implement SMB signing to mitigate relay attacks |
| Medium | Deploy detection for NTLM-based attack techniques |
| Ongoing | Track NTLM usage trends across environment |
For application owners
| Priority | Action |
|---|---|
| High | Test applications with NTLM restricted |
| High | Work with vendors on Kerberos roadmaps |
| Medium | Document business justification for NTLM exceptions |
| Ongoing | Plan application modernization or replacement |
Context
NTLM’s deprecation has been anticipated for years. Microsoft has published Kerberos alternatives for most scenarios, and security best practices have long recommended disabling NTLM where possible.
The three-phase approach gives organizations time to identify dependencies and migrate, but the direction is clear: NTLM’s days as a default authentication protocol are numbered.
| Phase | Timeline | Action required |
|---|---|---|
| Phase 1 | Now | Deploy auditing |
| Phase 2 | H2 2026 | Test new Kerberos features |
| Phase 3 | TBD | Prepare for default disable |
Organizations should treat the Phase 1 auditing tools as urgent deployment priorities, not optional enhancements. The NTLMv1 October 2026 deadline provides a forcing function for the most critical migrations.