Will NTLM Deprecation Stop Your Business Apps? — How to Collect Audit Logs, and the Order in Which to Kill Dependencies

“I hear NTLM is being retired. Are we going to be all right?” To answer that, the first thing to do is not to block it across the company but to audit the authentication that is running right now. All versions of NTLM were announced as deprecated in June 2024, but that announcement alone does not stop any business.¹

The retirement of NTLM is not the kind of change where a patch lands one day and the whole company stops; it is the kind where the restrictions tighten step by step with each new OS. While NTLM still works, list the machines, applications, and destinations that depend on it, try the change in a small scope, and only then restrict it. Blocking everything first and then hunting for what broke is the wrong order.

This article is a practical procedure for the IT department that runs a Windows environment and for the developers who maintain business applications. It proceeds in this order: audit, classify the causes, fix names, settings, and code, test one connection at a time, then restrict in stages.

The mechanics of the protocol itself (why NTLM is risky, why authentication falls back to NTLM instead of Kerberos) are split out into the companion article “NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM”.

The retirement roadmap and feature availability are stated as of July 2026, the same baseline as the Japanese original. Keep that separate from the date the structure of this article was last updated. Check the availability of IAKerb, the local KDC, and the rest in the release notes for your target version when you actually make the migration decision.²

Start From the Problem You Have

If you are reading straight through, start at chapter 1; when you begin the actual work, come back to the audit in chapter 4.

1. Conclusions First

Distinguish Where the Change Actually Stands

NTLM was deprecated in June 2024. That covers every version, including LANMAN, NTLMv1, and NTLMv2, and it is a statement that active feature development has stopped. The same announcement also says that using NTLM will continue to work in the next release of Windows Server and the next annual release of Windows.¹

Parts of it have already been removed. NTLMv1 was removed in Windows 11 version 24H2 and Windows Server 2025.¹

The retirement proceeds in three phases. Phase 1 is making usage visible and auditing it, phase 2 (second half of 2026) is the features that remove the situations where NTLM cannot be avoided (IAKerb and the local KDC), and phase 3 is disabling network NTLM authentication by default in the next major release.²

Identify the Dependencies Before You Block Anything

There is exactly one thing to do now. Run audit mode and build a list of “which machine, which application, against which server” is using NTLM (chapter 4).

For domain accounts, the investigation starts at the domain controller. Following event 8004, then 8003 on the member server, then 8001 on the client, gets you all the way to the application name (section 4.2). Note, however, that authentication with local accounts does not go through a domain controller, so no 8004 appears. That route has to be picked up from 8003 on the server and 8001 on the client.³

Most causes are names. Hard-coded IP addresses and unregistered SPNs are the two big ones, and neither requires rebuilding the application (chapter 5).³²

Test Small, and Fix the Application Side Too

There is a safe way to test on a single machine. On Windows 11 24H2 or Windows Server 2025, NET USE \\server\share /BLOCKNTLM lets you check “does this connect without NTLM?” without changing a single policy (chapter 7).⁴

In your own applications, change the places that name NTLM to Negotiate. Microsoft itself writes “do not access the NTLM security package directly” (chapter 8).⁵

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (29 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What “Deprecated” Actually Means

Start by settling the terminology. Explain this to the company while it is still vague and you will get “apparently we cannot use it any more” and “apparently we are fine for years” circulating at the same time, and the discussion falls apart.

Separate the Deprecation Announcement From the Removal That Already Happened

Summarized, the NTLM entry in Microsoft’s list of deprecated features says three things.¹

1. Every version of NTLM, including LANMAN, NTLMv1, and NTLMv2, is outside active feature development and is deprecated.
2. Using NTLM will continue to work in the next release of Windows Server and the next annual release of Windows.
3. Calls to NTLM should be replaced by calls to Negotiate. Negotiate attempts to authenticate with Kerberos and falls back to NTLM only when it has to.

An update then adds that NTLMv1 has been removed from Windows 11 version 24H2 and Windows Server 2025.¹

So where we stand is “deprecated”, not “removed”. NTLMv1 alone has gone past deprecation and is already in the removal phase. If an old multifunction printer or NAS can only authenticate with NTLMv1, the update to Windows 11 24H2 is itself the outage. That is not a future problem; it is happening now.

For Uses With No Alternative, Check the Conditions on the Other Side Too

The other thing worth holding on to is that NTLM still has uses for which no alternative exists. Microsoft states explicitly that NTLM is still used, and must be used, for Windows authentication on systems configured as members of a workgroup and for local logon authentication on non-domain controllers.⁶ The local KDC planned for phase 2 is precisely the feature meant to fill that “local accounts require NTLM” gap.²

2.1. Where the Three Phases Stand

The retirement roadmap has three phases. This information is time-dependent, so it is presented with its baseline date (the table below reflects the situation as of July 2026).

What this table should make clear is that phase 1 is the only one you can move with your own hands today. The decision table in chapter 6 says of some items that a phase 2 feature “could be the answer”, but every one of those is conditional on checking availability. Delivery dates can change, so always re-check the content of this table at the point when your organization makes its decision.

3. Why It Is Going Away — Three Minutes

Only the minimum needed as input for the migration decision. The detailed illustrated treatment is left to the companion article.

In its policy settings documentation, Microsoft states plainly that NTLM and NTLMv2 authentication is vulnerable to a variety of malicious attacks, including SMB relay, man-in-the-middle, and brute force attacks.⁷ At the root of it are the following properties, which are usually described by comparison with Kerberos.⁸

There Is No Mutual Authentication

With NTLM, a client cannot verify a server’s identity, and one server cannot verify another server’s identity. NTLM was designed for network environments where you can assume “the server is genuine”. Kerberos does not make that assumption. This difference is what makes relay attacks possible, where a victim is made to send credentials to a fake server.

With Domain Authentication, the Server Queries the DC

With NTLM, an application server has to connect to a domain controller every time it authenticates a client with a domain account (for an account local to the server, the server consults its own account database and decides there).⁶ With Kerberos, renewable session tickets replace that pass-through authentication, and the server does not have to go to a domain controller except when it needs to validate the PAC (privilege attribute certificate).

A Stolen Hash Is Abused Without Knowing the Password

NTLM credentials consist of a one-way hash of the domain name, user name, and password, and the client encrypts the challenge with that hash to produce its response.⁵ From this follows the property that stealing the hash is enough to impersonate the user, without ever knowing the plaintext password.

The practical meaning of “there is no mutual authentication” is that simply trying to connect to an SMB share can hand your credentials to a fake server. The reason Microsoft built NTLM blocking into the SMB client is described the same way: to prevent techniques that get NTLM requests sent to malicious servers.⁴

4. Auditing — Building a List of Where NTLM Is Used

This is the heart of the article. Microsoft’s own guidance states explicitly that discovering and auditing the current state of NTLM authentication traffic is necessary before implementing restriction policies.⁹

4.1. Turning On Audit Mode

Note: Audit mode only records; it blocks nothing. On the other hand, in an environment with many machines the log volume jumps immediately. If you are not using event collection (WEF), review the log size limit and retention period before enabling it. Microsoft’s guidance also says the analysis can take several months depending on how complex the environment is.³

Count the audit period from after the settings have reached the target machines. So that you do not miss monthly processing or the routes used during an incident, read section 9.2 on “a full business cycle” first as well.

Where to Configure, and the Three Policies

There are three policies to set. All of them live under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, and no restart is required. Whether you save them locally or distribute them by Group Policy, they take effect the moment the setting is applied.⁷

Do Not Use the Time You Saved the GPO as the Start of the Audit

“No restart required” and “effective on every machine immediately” are, however, different things. When you distribute a domain GPO, saving the GPO only updates the policy in AD and SYSVOL; each machine actually starts auditing at its next background refresh or after you run gpupdate /force. Count the start of the audit period from the time the settings finished reaching the target machines, not from the time you saved the GPO. Get this wrong and the result is skewed in a specific way: only the first aggregation covers fewer machines than you think.

The third one, “Outgoing NTLM traffic to remote servers”, has four values: Allow all, Audit all, Deny all, and Not Defined, and Not Defined is treated the same as Allow all. Microsoft’s recommendation is equally clear: do not jump straight to “Deny all”; set it to “Audit all” first, review the operational log, understand which servers are receiving authentication requests, and only then build the exception list.⁷

Look at NTLM/Operational, Not the Security Log

Events are recorded in Event Viewer > Applications and Services Logs > Microsoft > Windows > NTLM (Microsoft-Windows-NTLM/Operational). There is no corresponding security audit event policy for this auditing, so look at that channel rather than the Security log.⁷

Match Machine Roles to the Events They Record

The single easiest thing to get wrong in the field is the mapping of “which policy goes on which machine, and which event do I look at”. Calling the three policies in the table above (1), (2), and (3), here is the checklist.

The log is the same Microsoft-Windows-NTLM/Operational on every machine. Policy (1) only has any effect on domain controllers, and a machine where you forgot (2) and (3) is not “a machine that does not use NTLM” but “a machine that is not recording”. That difference is the biggest single source of skewed aggregates.

4.2. Trace “Downstream From the Domain Controller”

Start by separating the accounts used for authentication. For domain accounts, trace downstream from the DC; for local accounts, trace from the server and the client.³

Also note that there are cases where no 8004 appears on the domain controller, because when a local user account connects to a file server, that authentication does not go through a domain controller.³ Do not decide “the DC logs were sparse, so we are fine”.

Trace Domain Accounts as 8004 to 8003 to 8001

The trace path for domain accounts given by Microsoft’s guidance is as follows.³

flowchart TD
    DC["Domain controller<br/>Event 8004"]
    MS["Member server<br/>Event 8003"]
    CL["Client<br/>Event 8001"]
    APP["The application at fault"]

    DC -->|"Secure Channel Name =<br/>the server to examine"| MS
    MS -->|"Workstation Name =<br/>the client to examine"| CL
    CL -->|"Client Process Name"| APP
    MS -.->|"PID of 4 (SYSTEM) means<br/>it came via SMB"| CL

Figure 1: The order in which NTLM audit events are traced

The fields to look at in each event are as follows.³

The Last Things to Look At Are the Destination and the Process Name

What makes this path especially valuable is “Target Server” and “Client Process Name” in event 8001. The first tells you directly why it did not become Kerberos, and the second tells you directly who is at fault. Microsoft’s guidance describes the same thing: from this information you can determine that a user is connecting to the IP address of a web server rather than the NetBIOS name or FQDN that would have allowed Kerberos.³

4.3. Aggregating With PowerShell

Step 1: Count the Event IDs Recorded on the Machine

Staring at thousands of entries in the Event Viewer GUI is not realistic, so summarize them with Get-WinEvent. First, check which events appear on the machine and how many of each.

# Aggregate NTLM/Operational events by ID (run as administrator)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

Step 2: Open One 8001 Event and Check the Actual Field Names

Once you have confirmed that events are appearing, group the client-side 8001 events by “destination server times calling process”. The field layout of an event differs per event ID, so the safe approach is to open one event with Format-List and check its structure first, then decide which field names to aggregate on.

# First, inspect a single event
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# To see the structured fields
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

Step 3: Aggregate by Destination Times Calling Process

Once you know the structure, pull the values out by the XML Name attribute and aggregate. Attribute names differ between OS versions, so looking them up by name breaks less often than using positional indexes.

# Aggregate the last 7 days of 8001 by "destination x calling process"
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # Pick up only the field names that actually exist, in priority order
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Step 4: Look at the Destination and the Owning Application, Not the Count

The final aggregation returns two columns: Count and Name (the destination and the calling process joined by a comma). In other words, the output looks like this (the values are illustrative).

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

What to look at is the first half of Name, that is, the destination. Here is how to read each row.

The absolute count means little on its own. Look at two things: whether rows addressed to IP addresses are at the top, and how many rows are resolved all the way to an executable name. The first are dependencies that will certainly go down once fixed; the second are dependencies you can assign an owner to.

If You Get Blanks or PIDs in the Aggregate, Revisit the Field Names

Because field names differ between OS versions, the code lists candidates in a priority-ordered array and picks up only the ones that exist. If you use a partial match such as -match 'Process' here, PID fields such as ClientProcessId get caught too, and you end up aggregating on a PID that changes every time instead of on the executable name (hash table key order is not defined, so which one you get is not stable either). If the Process column comes out empty on every row, that is the sign that your candidate names do not match the actual schema, so add the name you confirmed in the previous step to the array.

Before Scaling Out, Get One Machine Read the Same Way

If you are collecting from multiple machines, running them in parallel with PowerShell Remoting is the fast way (“An Introduction to PowerShell Remoting (WinRM) — Managing Multiple Windows Machines at Once”). Whether or not you use -FilterHashtable makes an order-of-magnitude difference to how long Get-WinEvent filtering takes; the essentials of that are collected in “Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes”.

4.4. Looking From the Security Log Side — Is NTLMv1 Still in Use?

Separately from NTLM/Operational, there is also a way to check the NTLM version from the logon events in the Security log. The procedure is to search the Security log for “Authentication Package” and look at “Detailed Authentication Information” on each event.³

Detailed Authentication Information:
    Logon Process:              NtLmSsp
    Authentication Package:     NTLM
    Transited Services:         -
    Package Name (NTLM only):   NTLM V1
    Key Length:                 128

Treat NTLM V1 Records as a Separate, Higher Priority

This “Package Name (NTLM only)” shows which sub-protocol of the NTLM family was used.³ A host showing NTLM V1 is a candidate for authentication failures the moment you upgrade it to Windows 11 24H2 or Windows Server 2025, because NTLMv1 has been removed in those versions.¹ When you run the audit, raise the priority of this one aspect in particular.

4.5. When Everything Shows PID 4 (SYSTEM) and You Cannot Proceed

Start auditing and you will almost certainly hit this wall. In applications that communicate through the redirector, such as SMB (shared folders), the entity requesting authentication is the kernel-mode redirector, so the PID left in the event is always 4 (SYSTEM).³

Narrow to a Machine With the Logs, Then Chase That One Machine With ProcMon

The remedy given by Microsoft’s guidance is as follows.³

1. Install a process monitoring tool on the client that is sending NTLM credentials (the “Computer” in event 8001).
2. Filter paths by both the peer server’s computer name and its IP address. If you need to capture for a long time, run it in background mode.
3. Correlate the capture with the timestamps of event 8003 on the server side. The user, path, and authentication identifier line up, and from there you can identify the calling application.

The tool is Process Monitor (ProcMon). How to apply filters and how to read the output are collected in “A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes”.

One practical tip to add: it is dramatically faster to narrow down “which machine” with the event logs alone up to this point, and only then set up ProcMon on that one machine. Deploying ProcMon to every machine is not realistic.

5. Typical Patterns That Fall Back to NTLM

Once the audit has told you where, the next step is to classify the causes. Microsoft’s guidance lists the following four as applications that use NTLM even though they theoretically support Kerberos.³

• Applications that let you choose among various security configurations and providers
• Applications whose SPN (service principal name) is not correctly configured
• Applications that use an IP address rather than a DNS name because of a misconfiguration or the vendor’s documentation
• Applications with a legacy codebase that still has NTLM-only parts

The Microsoft Japan support blog lists the representative causes of NTLM usage as server access specified by IP address, firewall restrictions on the ports Kerberos needs, unregistered SPNs, authentication to a trusted partner, and authentication in a workgroup environment.²

Record the Cause and the Fix Priority in the Same Table

Organized into the shapes you actually meet in the field, these become the table below. The two right-hand columns are the criteria for assigning priority. “Blast radius” means how widely it hurts when it stops, and “ease of fixing” means whether you can fix it on your own decision alone. With those two known, the table becomes the work order in your plan as it stands.

Put NTLMv1 First, and Start Long Lead-Time Coordination in Parallel

The work order follows mechanically from those two columns.

1. Regardless of blast radius, the top priority is equipment that can only speak NTLMv1 and hosts where NTLM V1 was recorded (section 4.4). This one sits outside the priority calculation, because its deadline has already arrived.¹
2. Next comes large blast radius and high ease of fixing, that is, hard-coded IP addresses. The counts are high and you can fix them on your own decision. Concentrate on these for the first month.
3. After that, the medium ease of fixing items around SPNs. Work through them together with standardizing names.
4. The low ease of fixing items (device dependent, network path, waiting on phase 2) are not late to start; they simply have long lead times, so start the vendor inquiries and budget requests in parallel with items 1 to 3.

The ones classed as “fixable right away” and “fixed by registering an SPN” should account for most of the audit results. Clearing just those leaves far fewer exceptions.

6. A Decision Table for Fixes

Choose the remedy according to the class you assigned in chapter 5. Do the change to FQDNs and the SPN check first, and treat TryIPSPN as the last resort for when a name cannot be used. There is an exception in where SPNs are registered for IIS, so read section 8.3 on “the identity that decrypts the ticket” before you start.

7. NTLM Blocking on SMB — The Shortest Route to a Real Test

Audit logs tell you that something is being used, but not what happens if you stop it. That is where the SMB client-side NTLM blocking added in Windows Server 2025 and Windows 11 version 24H2 helps.⁴

The feature blocks the SMB client from using NTLM authentication on outbound remote connections. Microsoft states that this prevents techniques that get NTLM requests sent to malicious servers and counters brute force, cracking, and Pass-the-Hash attacks, and positions NTLM blocking as necessary for switching an organization’s authentication protocol to Kerberos. At the same time it writes that this layer of protection can be enabled on its own without disabling NTLM entirely.⁴

Note: This is a feature of the SMB client.⁴ NTLM on routes other than SMB (HTTP traffic from your own applications, connections to SQL Server, WinRM, and so on) is not stopped by it. Those have to be eliminated individually, according to the classification in chapter 5.

There are two prerequisites.⁴

• The SMB client is Windows Server 2025 or later, or Windows 11 version 24H2 or later
• The destination SMB server can use Kerberos (the OS on the SMB server side can be anything that supports PKU2U or Kerberos)

7.1. Test One Machine and One Connection First

Rather than pushing out a policy right away, make use of the fact that blocking can be specified per connection. To judge the result, though, you need to tear down the existing session and confirm that the connection works without the flag. The two commands below are examples of the syntax; run the actual test with the four steps further down.

# Try connecting with NTLM forbidden on this connection only (if it connects, that share does not need NTLM)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# The same thing can be done with a PowerShell mapping
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

If it connects with the prerequisites met, you can conclude that that route works without NTLM. If it fails, compare against a test without the flag to separate the cause. Because you can check one connection at a time without changing a policy, it is well suited to corroborating the audit logs.

Check the result in the following three stages. Do not conclude an NTLM dependency from the wording of an error message alone.

Four Steps to Avoid a False Verdict

This check needs a procedure, though. Run it without thinking and you will get false verdicts in both directions.

$server = 'fileserver.corp.example.com'

# 1. Remove every last mapping to that server
#    If even one other share remains, the per-server session stays alive
net use | Select-String $server              # First see what is connected
net use \\$server\share  /delete
net use \\$server\other  /delete             # And every other share on the same server

# 2. Confirm the session really is gone (do not go on until this is empty)
Get-SmbConnection -ServerName $server

# 3. First confirm that it connects without the flag (a failure here is not an NTLM problem)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # Back to empty here as well

# 4. Only then try it with /BLOCKNTLM
net use \\$server\share /BLOCKNTLM

Steps 1 and 2: Tear Down the Session to the Server, Not Just the Share

SMB sessions are per server, not per share. If an authenticated session to that server remains, the redirector reuses it instead of authenticating again. /BLOCKNTLM only affects the authentication performed for that mapping; it does not retroactively validate a session that is already established (and may have been established with NTLM).

In other words, /delete on the share under test alone is not enough. If another share on the same server is still connected, it will succeed even though an NTLM dependency exists. Bring it down until Get-SmbConnection returns nothing. Besides your own mappings, resident applications and backup jobs can be holding a session. The most reliable and fastest approach is to test from a machine that has never connected to that server.

Step 3: Use Success Without the Flag as the Baseline for Comparison

A run with /BLOCKNTLM also fails on a name resolution failure, wrong credentials, or insufficient permissions on the share itself. If it fails without the flag too, that is not an NTLM dependency but a different problem.

Success Does Not Automatically Settle the Authentication Method

Note that all you can say here is “it did not need NTLM”, not “it authenticated with Kerberos”. The prerequisite for this feature is “an SMB server that can use Kerberos”, but the destination is allowed to be an OS that supports PKU2U.⁴ That leaves the possibility that the reason for success was PKU2U rather than Kerberos. With a domain-joined file server as the peer this is unlikely to matter, but when you want to establish exactly what authenticated, run klist on the client after connecting and see whether a cifs/ ticket for that server was obtained, or check the authentication package of the logon event in the Security log on the server side (section 4.4).

7.2. Enabling It per Machine

Once the corroboration is done, move on to blocking machine-wide on pilot machines.⁴

# Block NTLM across the whole SMB client (run as administrator)
Set-SmbClientConfiguration -BlockNTLM $true

With Group Policy, enable “Block NTLM (LM, NTLM, NTLMv2)” under Computer Configuration > Administrative Templates > Network > Lanman Workstation.⁴

7.3. Put the Peers You Cannot Change on the Exception List

Peers that genuinely need NTLM, such as SMB servers that are not domain joined, can be made exceptions. Enable Lanman Workstation > Block NTLM Server Exception List in Group Policy and list the IP addresses, NetBIOS names, and FQDNs you want to allow.⁴

Separate Permanent Exceptions From Emergency Registry Edits

There is no PowerShell cmdlet for creating the exception list itself, so the first configuration has to be made in the Group Policy Editor; once it exists, individual additions can be made with a registry edit.⁴

# Add entries to an existing exception list
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

Note: In the sample published in Microsoft’s documentation, the branch for “the value does not exist yet” only sets @(""), so the entries you wanted to add are thrown away.⁴ The behavior is that the first run adds no exceptions at all and only the second run does, so the code above writes the entries as they are in the not-yet-created case too. That said, this registry value is territory that Group Policy manages. Manage permanent exceptions on the Group Policy side and keep this operation to emergency, temporary use. The next policy application will overwrite it.

8. NTLM From a Developer’s Point of View — Use Negotiate

If you build Windows applications in house, what to fix is clear. Microsoft states the following explicitly.⁵

Applications should not access the NTLM security package directly; instead, they should use the Negotiate security package. Negotiate allows applications to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

In short, the rule is to change the places that say “NTLM” to “Negotiate”. The deprecated features list says the same thing: calls to NTLM should be replaced by calls to Negotiate.¹

8.1. The Common “Naming NTLM” in .NET

Replace Only the Authentication Type, Not the Account That Authenticates

// Bad: names NTLM as the authentication type
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// Good: only the authentication type changes. The credential is passed as before
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

What changes here is only the authentication type string. If you swap credential for CredentialCache.DefaultNetworkCredentials, you change not only the authentication protocol but the principal that authenticates. Authentication then goes out as the account running the process (a service account or the logged-on user) rather than the account you specified, and depending on the permissions at the destination it can stop working. Keep the protocol replacement and any review of credentials as separate changes.

Changing to Authenticate as the Current User Is a Separate Decision

If, on the other hand, what you want in the first place is to authenticate with the logged-on user’s credentials (integrated Windows authentication), it can be written much more simply. This is how to write it when you are deliberately changing “who you authenticate as”.

// Integrated Windows authentication (authenticate as the currently logged-on user)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

Handling HttpClient itself (not wrapping it in using, creation patterns, timeout design) is covered in “Don’t Wrap HttpClient in a using Block — Practical HTTP Communication in C# Business Apps (Creation Patterns, Timeouts, Retries)”.

When Working With SSPI Directly, Specify Negotiate There Too

If you have to work with SSPI directly, System.Net.Security.NegotiateAuthentication, added in .NET 7, lets you handle authentication over Negotiate from managed code. The key point here too is not to specify NTLM as the package name.

8.2. “How the Destination Is Written” Comes Before the Code

Even if you fix the code, if the destination is still an IP address it ends up on NTLM anyway. By default, when the host name is an IP address, Windows does not attempt Kerberos authentication against that host and falls back to another valid protocol such as NTLM.¹⁰ Specifically, go through the following.

• Server names written in configuration files (appsettings.json, App.config, ini files)
• The server specification in SQL Server connection strings (Data Source)
• Places where UNC paths are assembled. Check for hard-coded IP addresses
• Default values in installers and PC setup procedures
• Places that were rewritten to an IP during a past incident “because name resolution was unstable” and never changed back

That last item really does turn up. A hard-coded IP address was the right stopgap at the time, but today it is technical debt.

8.3. If You Are Building the Service Side

If you want your own Windows service or IIS application to accept Kerberos, you have to register an SPN, using the name clients use for access, on the account that decrypts the ticket. As Microsoft itself lists, an application with no SPN registered is a classic example of one that falls back to NTLM even while claiming Kerberos support.³

With IIS, the App Pool Identity and the Decrypting Identity Are Not Necessarily the Same

Think of the registration target simply as “the account that runs the service” and you will trip over IIS. Windows authentication in IIS has kernel-mode authentication enabled by default, and in that case what decrypts the Kerberos ticket is not the application pool identity but the machine account that HTTP.sys uses. Running the application pool under a dedicated domain account and then registering the site’s HTTP SPN on that account leaves the owner of the SPN and the account that actually decrypts disagreeing, and rather than falling back to NTLM, authentication itself fails with KRB_AP_ERR_MODIFIED.

The point is to make the SPN registration target and the identity that decrypts the ticket the same. There are two workable shapes.

Which to choose depends on whether the same service account is shared across multiple servers (if it is, converging on the pool identity is easier to manage). Note that an SPN can only be registered on one account, so when you switch, do not forget to remove the old registration. Duplicate registrations break Kerberos authentication itself.

Check Delegation to Other Servers Together With the Protocol Change

If your design impersonates the client to access another server (delegation), NTLM and Kerberos differ in how they handle it. Kerberos supports a delegation mechanism by which a service connects to other services on the client’s behalf, whereas what NTLM provides goes only as far as the authorization information needed to impersonate locally.⁸ The implementation side of impersonation is covered in “Handling Windows Impersonation Tokens Correctly — Borrowing Privileges per Thread and Reverting Safely”.

9. A Roadmap for Tightening in Stages

Putting all of the above together, the order to proceed in is as follows. Every stage is conditional on being reversible.

9.1. Stopping SMB Is Only Half of NTLM Remediation

Stages 4 to 6 deal with SMB only. As covered in chapter 7, SMB client NTLM blocking is a feature of the SMB client,⁴ and it has no effect on any other route. Anything you classified in stage 2 as “authenticating over HTTP”, “SQL Server is using NTLM”, or “WinRM is using NTLM” is still untouched when you finish stage 6. And because it does not appear on the SMB exception list either, counting that list will not reveal it.

For Everything but SMB, Go Audit, Exception, Deny With Restrict NTLM

Stage 6b is what closes that gap. It uses exactly the three policies you put into audit mode in chapter 4. The procedure follows the same shape.¹¹

1. Leave “Outgoing NTLM traffic to remote servers” on Audit all and enumerate the destinations that remain
2. Register the peers you genuinely need in “Add remote server exceptions”
3. Switch pilot machines to Deny all and wait for the business to go through a full cycle
4. If there are no problems, roll it out

For the Whole Domain Too, Confirm the Impact With the Matching Audit Before Denying

For the domain as a whole, take “NTLM authentication in this domain” through the same order: audit, exceptions (“Add server exceptions in this domain”), then deny.¹² Microsoft likewise says that before choosing a deny option you should set the corresponding audit policy to the same option and assess the impact.¹²

“We blocked SMB, so NTLM remediation is complete” is not true. If you want a completion metric, count both the SMB exception list and the Restrict NTLM server exception list.

9.2. Set the Audit Period by “a Full Business Cycle”, Not by Days

The easiest thing to get wrong in stage 1 is how you decide the period. Declare it complete because “we collected for two weeks” and anything that did not run in those two weeks is not on the list. And what is not on the list breaks for the first time after you distribute the block in stage 6.

Inventory Recovery Routes and Offline Machines, Not Just Monthly Processing

Concretely, the things most easily missed are the following.

• Monthly and quarterly close processing. A month-end batch that connects to a shared folder or database by hard-coded IP address is the classic example.
• Annual processing. Stocktaking, the fiscal year rollover, anything tied to the financial close.
• Routes taken only during an incident. Restore procedures from backup, failover to a standby server, DR drills.
• Machines that are offline for long periods. Laptops taken off site, the machines of staff on extended leave, spare machines that are normally powered off.
• Business applications used only a few times a year.

If You Cannot Wait, Run the Low-Frequency Processing Deliberately

Microsoft’s guidance itself says the analysis can run to several months depending on the complexity of the deployment.³ The realistic line to draw is one of the following two.

1. Keep the audit running until the business has been through a full cycle. At minimum one monthly close, and preferably across a quarter.
2. Inventory the low-frequency processing and run it deliberately. If you cannot wait out the period, run the close processing and DR procedures in a test environment and add those results to the list. The key is to enumerate in advance, by interviewing the people responsible, the processing that “produced no events only because it never ran”.

In either case, move to the next stage only once you are in a position to distinguish “no event appeared” from “it has not run yet”.

9.3. Do Not Swing Straight to Deny

The key here is not to swing “Outgoing NTLM traffic = Deny all” on in one move. Microsoft likewise says that setting this policy to deny can cause many NTLM authentication requests to fail and reduce productivity, so before implementing it you should review the log with “Audit all”, analyze the servers, and build an exception list of the ones to exclude.⁷ The same warning is written for the “NTLM authentication in this domain” policy that targets the whole domain.¹²

10. Summary

• All versions of NTLM were deprecated in June 2024. It is not a change that stops anything immediately; it is stated to keep working in the next release of Windows Server and the next annual release of Windows.¹
• On the other hand, NTLMv1 has already been removed (Windows 11 24H2 and Windows Server 2025). Equipment that can only speak NTLMv1, and hosts where NTLM V1 has been recorded, are the nearest deadline.¹
• The retirement has three phases: phase 1 is auditing, phase 2 (second half of 2026) is IAKerb and the local KDC, and phase 3 is the default-off.²
• Auditing means putting the three policies into audit mode and collecting Microsoft-Windows-NTLM/Operational. For domain accounts, go 8004 on the DC, 8003 on the member server, then 8001 on the client, and you reach the application name at the end. Authentication with local accounts produces no 8004, so pick it up from the server and client events.³⁷
• Traffic via SMB always shows PID 4 (SYSTEM). Narrow down to the machine with the event logs, then chase that one machine with ProcMon.³
• Most causes are names. Just clearing hard-coded IP addresses and unregistered SPNs greatly reduces the exceptions that remain.³²
• NET USE \\server\share /BLOCKNTLM is the safest way to corroborate, one connection at a time, without changing a policy.⁴
• In in-house applications, replace NTLM-by-name with Negotiate and standardize how destinations are written on FQDNs.⁵
• An exception list is a grace period, not a solution. Use whether the count falls every year as the metric.

Related Articles

• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes
• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• An Introduction to PowerShell Remoting (WinRM) — Managing Multiple Windows Machines at Once
• Handling Credentials Safely in PowerShell — Banishing Plaintext Passwords from Your Scripts
• Integrating Entra ID Authentication into WinForms/WPF Apps — A Practical Architecture with MSAL.NET and the WAM Broker
• What Is the TPM in Windows? — An Illustrated Guide to the “Safe That Never Lets Keys Out” and Measured Boot

Related Consulting Areas

KomuraSoft LLC handles inventories of NTLM dependencies, modification of business applications for migration to a Kerberos-based estate, and investigation of authentication-related defects.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Reuse & Migration Support
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

When NTLM is retired, when will our business grind to a halt?

A "deprecated" announcement on its own stops nothing. Microsoft deprecated all versions of NTLM in June 2024, but the accompanying guidance said that using NTLM will continue to work in the next release of Windows Server and the next annual release of Windows. The concrete change that has already broken things is the removal of NTLMv1 in Windows 11 version 24H2 and Windows Server 2025. There is a published plan to disable network NTLM by default in a future release, but even then it is stated that it can be re-enabled by policy. In other words, this is not the kind of change where the whole company stops one day; it is the kind that tightens a little with each new OS. That is precisely why the only realistic preparation is to inventory your dependencies with audit logs while NTLM still works, rather than investigating after something has broken.

How do I produce a list of the places where NTLM is used?

Put the "Network security: Restrict NTLM" family of Group Policy settings into audit mode and collect the NTLM/Operational log. Set "Audit NTLM authentication in this domain" on domain controllers, and "Audit Incoming NTLM Traffic" plus "Outgoing NTLM traffic to remote servers = Audit all" on servers and clients, and events are recorded under Applications and Services Logs > Microsoft > Windows > NTLM in Event Viewer. For domain-account authentication, the order to follow is: identify the user and the destination server (Secure Channel Name) from event 8004 on the domain controller, look at the process ID in event 8003 on that server, and finally pin down "which application, against which server name" with event 8001 on the client. Event 8001 carries the target server name and the client process name, so once you get that far you know which application is at fault. Note that authentication with local accounts does not go through a domain controller, so no 8004 appears. Routes where a workgroup machine or a local account on a file server connects to a share have to be picked up from 8003 on the server and 8001 on the client. Do not look only at the domain controller logs and conclude "we hardly use it".

I turned on auditing and the events all show PID 4 (SYSTEM). I cannot tell which application it is.

That is because the traffic goes via SMB (shared folders). SMB authentication is performed by the kernel-mode redirector, so the calling application is hidden behind the SMB packets and the PID left in the event is always 4 (SYSTEM). Microsoft's guidance calls out this case explicitly and recommends running Process Monitor (ProcMon) on the client where the events appear, filtering paths by the peer server's computer name and IP address, and correlating with the timestamps of event 8003 on the server side to identify the calling process. In practice, the fast route is to narrow down "which machine" with the event logs first, and then chase only that machine with ProcMon.

Why does an application that supposedly supports Kerberos fall back to NTLM?

Almost always it is a naming problem. Microsoft's guidance lists four kinds of applications that use NTLM even though they theoretically support Kerberos: applications that let you choose the security configuration or provider; applications whose SPN (service principal name) is not registered correctly; applications that connect by IP address rather than DNS name because of a misconfiguration or the vendor's documentation; and applications with a legacy codebase that still contains NTLM-only parts. If the "Target Server" in event 8001 is in neither NetBIOS nor FQDN form (that is, it is an IP address), Kerberos will not be used in the default configuration. The first two moves are to change hard-coded IP addresses to FQDNs, and to register an SPN for the alias if access uses one. There is also a way to configure TryIPSPN on clients and manually register an SPN for the IP address, for cases where the name genuinely cannot be changed, but Microsoft itself says this should be limited to situations where switching to a DNS name is impossible, so treat it strictly as a last resort.

What should we fix in the Windows applications we build ourselves?

Replace anywhere that names NTLM as the authentication package with Negotiate. Microsoft states explicitly that applications should not access the NTLM security package directly and should use the Negotiate package instead. Negotiate selects either Kerberos or NTLM, and selects Kerberos unless one of the systems involved in the authentication cannot use it. In .NET, the typical fix is to change the authentication type passed to CredentialCache.Add from "NTLM" to "Negotiate" (the authentication type is specified on CredentialCache.Add, not on the NetworkCredential constructor). Alongside that, you also need to specify destinations by FQDN rather than by IP address or an alias written into hosts, and, if you want your own service to accept Kerberos, to register an SPN on that service account.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.