Disable NTLM in Windows Safely: 2026 Step-by-Step Hardening Guide

NTLM has been on borrowed time for two decades, and Microsoft made it official: as of late 2023 Microsoft formally announced that NTLM is deprecated, with Kerberos and the new Negotiate-based authentication taking over. Windows 11 24H2 and Windows Server 2025 ship with NTLMv1 fully removed, and Microsoft strongly recommends auditing and disabling NTLMv2 wherever Kerberos can take over. This guide walks through how to disable NTLM in Windows safely — auditing first, staging the rollout, and rolling back cleanly if something breaks.

This is not a “flip the switch” guide. Disabling NTLM domain-wide on day one will break things — schedulers running \\IP\share paths, legacy NAS appliances, applications that hard-code IP addresses, and any workgroup machine that doesn’t speak Kerberos. The right approach is to audit, identify, migrate, and only then enforce. We’ll do all four.

TL;DR — the safe NTLM disable workflow

If you only have ten seconds, this is the order of operations:

1. Audit NTLM usage on Domain Controllers and member servers for at least 2 weeks (Event ID 8004 / 8001 / 8003)
2. Inventory every client and app showing up in those logs
3. Migrate the easy fixes: hostnames instead of IPs, SPN registration, SMB signing
4. Enforce NTLMv2-only by setting LmCompatibilityLevel = 5 everywhere
5. Block NTLM per-server on critical assets (file servers, DCs)
6. Block NTLM domain-wide with explicit exceptions
7. Verify Kerberos is doing the work (klist, Event 4624)
8. Plan rollback before you start — and document the GPO link order so you can reverse it in one minute

Below, each step is unpacked with the real Group Policy paths, registry keys, PowerShell commands, and the failure modes you’ll hit.

Why disable NTLM in 2026?

Three forces are pushing NTLM into the grave:

1. NTLM is fundamentally vulnerable to relay attacks. Tools like ntlmrelayx.py (Impacket), Responder, and Inveigh exploit the fact that NTLM authentication can be passed verbatim from one endpoint to another. Attackers chain a credential coercion (PetitPotam, PrinterBug, DFSCoerce, ShadowCoerce, MS-EFSR, MS-EVEN) with relay to LDAP, SMB, or AD CS, escalating from “I can ping the network” to “I control the domain” in minutes. None of these attacks work against Kerberos.

2. Microsoft formally deprecated NTLM in 2023. The announcement on the Windows IT Pro blog declared NTLM “deprecated” and committed to defaults of Kerberos and the new Negotiate flow. Deprecation isn’t removal yet, but it signals that future Windows releases will progressively restrict NTLM, default-deny it, and eventually drop support entirely. Windows 11 24H2 already removed NTLMv1 entirely.

3. Recent CVEs keep underlining the urgency.

Every one of these is a “user opens a file, attacker gets their NTLMv2 hash” pattern. Kerberos environments are immune.

The compounding risk: every NTLMv2 hash that leaves your network can be cracked offline (modern GPUs hit 70+ billion NTLM hashes/sec for weak passwords) or relayed in real-time to access services you didn’t realise were exposed. The only durable mitigation is to stop emitting NTLM in the first place.

NTLM, NTLMv2, and Kerberos: a quick clarification

Three closely-related terms that mean different things — and matter for what you actually disable:

Crucially, “disabling NTLM” almost always means disabling NTLMv2. NTLMv1 should already be off; if it isn’t, that’s your highest-priority fix.

Pre-flight checklist

Before you change a single setting:

1. Make sure you have console access to at least one Domain Controller. If you remote in over RDP and the change locks you out, you need physical/iLO/iDRAC/console access to recover.
2. Snapshot or back up the Default Domain Policy and the Default Domain Controllers Policy. Use Backup-GPO -All -Path C:\GPOBackups in PowerShell.
3. Confirm Kerberos is healthy. Run klist tickets on a workstation, verify you have TGS tickets for the services you use. If Kerberos is already broken, fix that first — disabling NTLM will just expose the breakage.
4. Identify your “critical exception” apps in advance. Legacy line-of-business apps, NAS appliances, and old printers are the usual suspects.
5. Schedule a maintenance window for the eventual cut-over, even though most of these changes are reversible in seconds.

Step-by-step: how to disable NTLM in Windows

The full safe-rollout sequence:

Step 1: Enable NTLM auditing

The single most important setting in the entire rollout. Without audit data, you’re guessing at which apps depend on NTLM.

Group Policy path (Default Domain Controllers Policy):

Computer Configuration
  └ Policies
    └ Windows Settings
      └ Security Settings
        └ Local Policies
          └ Security Options
            ├ Network security: Restrict NTLM: Audit Incoming NTLM Traffic
            │    = Enable auditing for all accounts
            └ Network security: Restrict NTLM: Audit NTLM authentication in this domain
                 = Enable for all accounts

Registry equivalents (apply via New-ItemProperty if you’re scripting):

$lsa = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-ItemProperty -Path $lsa -Name 'AuditReceivingNTLMTraffic' -PropertyType DWord -Value 2 -Force
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters' `
  -Name 'AuditNTLMInDomain' -PropertyType DWord -Value 7 -Force

gpupdate /force

Once the policy applies, NTLM auth events appear in Event Viewer → Applications and Services Logs → Microsoft → Windows → NTLM → Operational.

The events you care about:

Pipe Event 8004 to CSV for analysis:

Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath "*[System[EventID=8004]]" |
  Select-Object TimeCreated,
    @{N='User';      E={$_.Properties[1].Value}},
    @{N='ClientPC';  E={$_.Properties[2].Value}},
    @{N='ServerName';E={$_.Properties[3].Value}} |
  Export-Csv -Path C:\NTLMAudit.csv -NoTypeInformation

Run this on every DC for 14 days minimum. Aggregate the CSVs.

Step 2: Build the migration inventory

Open the aggregated CSV in Excel/PowerBI/your tool of choice and group by (ClientPC, ServerName, User). Classify each row:

• “Easy fix” — client uses IP address; replace with hostname. Or service account missing SPN; register the SPN.
• “Workgroup host” — non-domain machine; join the domain or carve out an exception.
• “Legacy appliance” — NAS, printer, IPMI controller; check firmware for Kerberos support or plan replacement.
• “Local account auth” — someone is authenticating with a local account on a remote server (often admins). Migrate to a domain account.
• “Genuine NTLM-only app” — old line-of-business application that genuinely can’t speak Kerberos. Note it for the exception list.

The first three categories are your prep work. The fourth is a process fix. The fifth is the permanent allowlist.

Step 3: Migrate the easy fixes

Replace IP-based connections with hostnames. Kerberos service tickets are issued for SPNs that match a specific hostname. If a scheduled task connects to \\10.1.1.5\backup, the client can’t request a Kerberos ticket — the SPN lookup happens on hostname, not IP. Update the path to \\fileserver01.corp.local\backup.

Register missing SPNs. When a service runs under a custom account (e.g., a SQL Server instance using a domain service account), the SPN must exist for Kerberos to work. Check with setspn -L corp\svc-sqlsvc. Add missing ones:

setspn -S MSSQLSvc/sql01.corp.local:1433 corp\svc-sqlsvc
setspn -S MSSQLSvc/sql01.corp.local       corp\svc-sqlsvc

Re-join workgroup hosts where possible. Anything outside the domain falls back to NTLM. Domain-join eliminates that.

SMB hardening pairs naturally with NTLM removal. Set SMB signing required on both servers and clients via GPO: Microsoft network server: Digitally sign communications (always) and Microsoft network client: Digitally sign communications (always). SMB signing makes the most common NTLM relay attack (SMB → SMB) infeasible even where NTLM still flows.

Step 4: Enforce NTLMv2-only with LmCompatibilityLevel = 5

The single most important hardening change before you block NTLM. LmCompatibilityLevel = 5 means “send and accept NTLMv2 only; refuse LM and NTLMv1.” Setting this on every host kills NTLMv1 forever.

Group Policy path:

Computer Configuration
  └ Policies
    └ Windows Settings
      └ Security Settings
        └ Local Policies
          └ Security Options
            └ Network security: LAN Manager authentication level
                 = Send NTLMv2 response only. Refuse LM & NTLM.

Registry equivalent:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' `
  -Name 'LmCompatibilityLevel' -Value 5 -Type DWord

# Verify
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel

The full value table for reference:

Apply on DCs first, then member servers, then workstations. Most environments are already at 3 or 4; the jump to 5 rarely breaks anything that audit didn’t already flag.

Step 5: Block NTLM on critical servers (per-server hardening)

Per-server blocking is the low-risk first restriction. You’re saying “this specific file server does not accept NTLM” without touching the rest of the domain. If something breaks, the blast radius is one host.

Group Policy path (applied to the server itself or via a per-server OU):

Network security: Restrict NTLM: Incoming NTLM traffic
   = Deny all accounts

The three available values:

• Allow all — default, no restriction
• Deny all domain accounts — domain accounts can’t NTLM-auth to this server; local accounts still can (useful as a stepping stone)
• Deny all accounts — full block

Start with Deny all domain accounts for a week. Watch Event 8002 (blocked NTLM). Resolve the failures. Then move to Deny all accounts.

Test from a domain client:

# Before: should succeed via Kerberos (check with klist after)
Test-NetConnection fileserver01.corp.local -Port 445
net use Z: \\fileserver01.corp.local\share /persistent:no
klist | findstr cifs

# After enforcement: same commands should still work — Kerberos takes over.
# If they fail, something is forcing NTLM (IP address? local account?).

Step 6: Block NTLM domain-wide

Once 80%+ of your servers are running per-server blocks cleanly, escalate to domain-wide enforcement.

Group Policy path (Default Domain Controllers Policy):

Network security: Restrict NTLM: NTLM authentication in this domain
   = Deny all

The five available values:

• Disable — no restriction (default)
• Deny for domain accounts to domain servers — domain users can’t NTLM-auth to domain-joined servers
• Deny for domain accounts — domain users can’t NTLM-auth anywhere
• Deny for domain servers — no NTLM auth to any domain-joined server
• Deny all — full block, all accounts, all servers

Start at Deny for domain accounts to domain servers. Monitor for 1 week. Move to Deny all if clean.

Exception list for the genuinely stuck apps:

Network security: Restrict NTLM: Add server exceptions in this domain
   = legacynas.corp.local
     oldsoftware.corp.local
     vendor-appliance.corp.local

Use FQDN format, one per line. Exceptions should be a documented, time-bounded list — not a permanent dumping ground. Every exception is a footnote in your next pentest report.

Step 7: Verify Kerberos is doing the work

After enforcement, you need positive confirmation that Kerberos is filling the gap.

Check ticket cache on a workstation:

klist purge
# Log off and back on, then:
klist tickets

# You should see TGS tickets like:
#   Server: cifs/fileserver01.corp.local @ CORP.LOCAL
#   KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
#   ...

Audit logon events on a target server:

In Event Viewer → Security log → filter Event ID 4624 (successful logon). For each entry, check the Authentication Package field:

• Kerberos ✓ — what you want
• NTLM — still happening; you have an unfound NTLM dependency
• Negotiate — typically wraps Kerberos; verify by checking the LogonProcessName

A useful PowerShell one-liner to count auth methods over the last 24 hours:

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4624 and TimeCreated[timediff(@SystemTime) <= 86400000]]]" |
  ForEach-Object { ($_.Message -split "`n" | Where-Object { $_ -match 'Authentication Package' }) -replace '.*:\s*','' } |
  Group-Object | Sort-Object Count -Descending

You’re looking for Kerberos > 95% and NTLM converging to zero (excluding documented exceptions).

What typically breaks (and how to fix it)

Twelve years of helpdesk pattern recognition, condensed:

Rollback procedure

If something goes wrong and you need to back out:

1. On any DC: gpmc.msc → edit the Default Domain Controllers Policy → reverse the changed settings to Not Defined.
2. PowerShell: gpupdate /force on the DC.
3. Force replication: repadmin /syncall /AdeP /e.
4. On affected client/server: gpupdate /force then klist purge and re-logon.
5. If the issue was the LmCompatibilityLevel, restore the registry value: Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name 'LmCompatibilityLevel' -Value 3 (or whatever your baseline was).

Total time to revert: usually < 5 minutes once you know the exact GPO names. Which is why documenting the rollout in a runbook is non-optional.

Frequently asked questions

What to do next

If you’ve made it this far, the immediate next actions:

1. Enable NTLM auditing today on your Domain Controllers (Step 1) — zero risk, immediate visibility
2. Schedule a 2-week audit window before any enforcement
3. Build the inventory in week 3
4. Start per-server blocking in week 5 on a single low-traffic file server as a pilot
5. Domain-wide enforcement only after the per-server pattern is proven across a representative sample

For related Windows hardening guides on this site, see our Windows Hardening series. If you ran into a specific NTLM rollout issue not covered above, get in touch — we maintain a running list of “weird NTLM dependencies” from reader reports.

References

• Microsoft: The evolution of Windows authentication — the official NTLM deprecation announcement
• Microsoft Learn: Network security: Restrict NTLM (GPO reference)
• Microsoft Learn: Network security: LAN Manager authentication level
• MITRE ATT&CK T1187 — Forced Authentication
• MITRE ATT&CK T1557.001 — LLMNR/NBT-NS Poisoning and SMB Relay
• PetitPotam (CVE-2022-26925) advisory
• Impacket ntlmrelayx.py documentation — the reference relay tool