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

“Apparently NTLM is being retired. Are we going to be all right?” — since Microsoft announced in June 2024 that all versions of NTLM were deprecated, this question has come up more and more often. The answer is: you can find out whether you’re all right, and if you look now, you have time.

Retiring NTLM is not the kind of change where a patch lands one day and the whole company stops. It tightens a little with each new OS — and only while NTLM still works can you safely produce a list of “where in our estate we depend on NTLM”. Turning everything off and then hunting for what broke is the one order you must not use.

This article focuses on the practical procedure for producing that list and working through it. The mechanics of the protocols themselves (why NTLM is risky, why things fail to reach Kerberos) are split out into the companion article “NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM”.

1. The Bottom Line First

• NTLM was deprecated in June 2024. That covers all versions, including LANMAN, NTLMv1, and NTLMv2, and is a declaration that “there will be no more active feature development”. At the same time, the notice says that “using NTLM will continue to work in the next release of Windows Server and the next annual release of Windows”.¹
• Some parts have already been removed. NTLMv1 was removed in Windows 11 version 24H2 and Windows Server 2025.¹
• Retirement proceeds in three phases. Phase 1 is making usage visible and auditing it; phase 2 (second half of 2026) brings features to remove the situations where NTLM is unavoidable (IAKerb, local KDC); phase 3 disables network NTLM authentication by default in the next major release.²
• There is only one thing to do right now: run audit mode and produce a list of “which machine, which application, against which server” is using NTLM (Section 4).
• Investigate domain accounts starting from the domain controller. Follow event 8004 → 8003 on the member server → 8001 on the client, and you arrive at the application name (Section 4.2). But authentication with local accounts does not pass through a domain controller, so no 8004 appears. Pick that route up from 8003 on the server and 8001 on the client.³
• Most causes come down to “names”. Hard-coded IP addresses and unregistered SPNs are the two biggest factors, and both can be fixed without rebuilding the application (Section 5).³²
• There is a way to test safely on a single machine. On Windows 11 24H2 / Windows Server 2025, NET USE \\server\share /BLOCKNTLM lets you check “does this connect without NTLM?” without changing a single policy (Section 7).⁴
• In your own applications, change the places that name NTLM to Negotiate. Microsoft itself writes “do not access the NTLM security package directly” (Section 8).⁵

2. What “Deprecated” Actually Means

Let’s settle the terminology first. Explain this to the business while it’s still vague and you get “apparently we can’t use it any more” and “apparently we’re fine for years” circulating at the same time, and the conversation falls apart.

Summarised, the NTLM entry in Microsoft’s list of deprecated features makes three points.¹

1. All versions of NTLM, including LANMAN, NTLMv1, and NTLMv2, are no longer under active feature development and are 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, which attempts to authenticate with Kerberos and falls back to NTLM only when necessary.

And as an update, it notes that NTLMv1 was removed in Windows 11 version 24H2 and Windows Server 2025.¹

So the current position is “deprecated”, not “removed”. NTLMv1 alone has gone past deprecation and into the removal phase. If an old multifunction printer or NAS can only authenticate with NTLMv1, updating to Windows 11 24H2 breaks it there and then. This is not a future problem; it is happening now.

The other thing to keep in mind is that NTLM still has uses for which no replacement exists. Microsoft states explicitly that NTLM is, and must be, still 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 intended to fill that “NTLM is needed for local accounts” hole.²

3. Why It’s Going Away — Three Minutes Only

Just enough to inform the migration decision. The detailed illustrated version is left to the companion article.

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

• No mutual authentication. With NTLM, a client cannot verify a server’s identity, nor can one server verify another server’s identity. NTLM was designed for network environments where it can be assumed that servers are genuine. Kerberos makes no such assumption. That difference is what makes relay attacks — getting credentials sent to a fake server — possible.
• The server contacts a domain controller every time (for domain accounts). With NTLM, an application server must 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 for itself).⁶ With Kerberos, renewable session tickets replace this pass-through authentication, and the server does not need to go to a domain controller except when PAC (privilege attribute certificate) validation is required.
• The authentication material is the password hash itself. 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 and returns the response.⁵ From this follows the property that stealing the hash lets you impersonate the user without knowing the plaintext password.

The practical meaning of “no mutual authentication” is that simply trying to connect to an SMB share can hand your credentials to a fake server. Microsoft’s stated reason for providing NTLM blocking on the SMB client side is exactly this: “to prevent techniques that get NTLM requests sent to malicious servers”.⁴

4. Auditing — Listing Where NTLM Is Used

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

4.1. Enabling Audit Mode

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 saved locally or distributed by Group Policy, they take effect the moment the setting is applied.⁷

That said, “no restart required” and “effective on every machine immediately” are different things. When distributing via a domain GPO, saving the GPO only updates the policy in AD/SYSVOL; each machine actually starts auditing at its next background refresh or after a gpupdate /force. Count the start of the audit period not as “the date and time the GPO was saved” but as “the date and time the setting had propagated to the target machines”. Get this wrong and only the first round of aggregation covers fewer machines, skewing your results.

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

Events are recorded to 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 you look at this channel rather than the Security log.⁷

Caution: Audit mode only records; it blocks nothing. On the other hand, in a large estate the log volume goes up sharply. If you are not using event forwarding (WEF), review the log size limit and retention period before enabling it. Microsoft’s guidance also notes that analysis can take several months depending on the complexity of the environment.³

4.2. Trace “Downstream From the Domain Controller”

There is a fixed order in which to read the events you collect. The trace path shown in 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 look at"| MS
    MS -->|"Workstation Name =<br/>the client to look at"| CL
    CL -->|"Client Process Name"| APP
    MS -.->|"PID 4 (SYSTEM) means<br/>it went via SMB"| CL

Figure 1: The order in which to trace NTLM audit events

Here is what to look at in each event.³

What is especially valuable on this path is the “Target Server” and “Client Process Name” in 8001. The former tells you directly why it did not become Kerberos; the latter tells you who is to blame. Microsoft’s guidance explains that this information lets you identify that a user is connecting to a web server’s IP address rather than the NetBIOS name or FQDN with which Kerberos could have been used.³

Note that there are cases where no 8004 appears on the domain controller. When a local user account is used to connect to a file server, that authentication does not go through a domain controller.³ Do not look at the DC logs, see very little, and conclude that you are fine.

4.3. Aggregating With PowerShell

Staring at thousands of entries in the Event Viewer GUI is not realistic, so use Get-WinEvent to summarise. First, check which events are present on the machine and in what numbers.

# 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 } }

Once you have confirmed that events are being generated, group the client-side 8001 events by “destination server × calling process”. The field layout differs per event ID, so it is safest to open one event with Format-List and check the structure before deciding on indices.

# First, inspect the contents of 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'

Once you know the structure, extract by the XML Name attribute and aggregate. Attribute names vary between OS versions, so looking them up by name is less brittle than positional indexing.

# 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 existed, 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

Because field names differ between OS versions, the code lists candidates in a priority-ordered array and picks up only the ones that actually exist. If you use a partial match such as -match 'Process' here, you can also catch PID fields like ClientProcessId and end up aggregating by a PID that changes every time rather than by the executable name (and since hash table key order is undefined, which one you get is not even stable). If the Process column comes back entirely empty, that is a sign that your candidate names do not match the actual schema — add the names you confirmed in the previous step to the array.

To collect from multiple machines, running them in parallel with PowerShell Remoting is fastest (“Getting Started with PowerShell Remoting (WinRM) — Managing Multiple Windows Machines at Once”). Filtering with Get-WinEvent differs by orders of magnitude in run time depending on whether you use -FilterHashtable, and the essentials are set out in “Investigating Event Logs Practically with Get-WinEvent — Filtering Speed Determines Investigation Time”.

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

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

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

That “Package Name (NTLM only)” tells you which sub-protocol of the NTLM family was used.³ A host showing NTLM V1 is a candidate for authentication failure if you upgrade it as-is to Windows 11 24H2 / 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 Is PID 4 (SYSTEM) and You Can’t Get Any Further

Start auditing and you will almost certainly hit this wall. For 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).³

Microsoft’s guidance gives this remedy.³

1. Install a process monitoring tool on the client that is sending the NTLM credentials (the “Computer” in 8001).
2. Filter paths by both the peer server’s computer name and its IP address. If a long capture is needed, 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 read the output is covered in “A Practical Guide to Process Monitor (ProcMon) — Pinpointing "Settings Not Applied" and "ACCESS DENIED" in 10 Minutes”.

One practical tip to add: narrow down “which machine” using the event logs alone up to this point, and then deploy ProcMon on that one machine only. Rolling ProcMon out to every machine is not realistic.

5. The Typical Patterns That Fall Back to NTLM

Once the audit has told you where, the next step is classifying the cause. Microsoft’s guidance lists four kinds of 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 IP addresses rather than DNS names, because of a misconfiguration or the vendor’s documentation
• Applications with a legacy codebase that still contains NTLM-only parts

The Microsoft Japan support blog lists, as the representative causes of NTLM being used, 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.²

Recast into the shapes you actually encounter in the field, they produce the following table.

The items classified as “Fixable right away” and “Fixed by registering an SPN” should account for the bulk of your audit results. Clearing those alone leaves far fewer exceptions.

6. A Decision Table for Fixes

7. NTLM Blocking on SMB — The Shortest Route to Field Verification

Audit logs tell you what is being used; they do not tell you what happens if you stop it. That is where the NTLM blocking on the SMB client side, added in Windows Server 2025 and Windows 11 version 24H2, comes in.⁴

This feature blocks the SMB client from using NTLM authentication on outbound connections to remote machines. Microsoft says it 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 organisation’s authentication protocol to Kerberos. At the same time, it notes that you can enable this layer of protection without disabling NTLM completely.⁴

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 SMB server’s own OS can be anything that supports PKU2U or Kerberos)

7.1. Test One Machine and One Connection First

Rather than distributing a policy straight away, use the fact that blocking can be specified per connection. This is the shortest route to field verification.

# Connect with NTLM forbidden for that connection only
# (if it connects, that share is fine without 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, that route works without NTLM. If it fails, that is an NTLM dependency. You can verify “will this break in production?” one connection at a time, without changing a single policy, which makes it ideal for corroborating the audit logs.

However, this check requires a procedure. Run it without thinking and you will get false results in both directions.

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

# 1. Remove *every* 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 proceed until this is empty)
Get-SmbConnection -ServerName $server

# 3. First confirm it connects without the flag
#    (if this fails, the problem is something other than NTLM)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # Empty it again here too

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

• Why steps 1-2 are needed: SMB sessions are per server, not per share. If an authenticated session to that server remains, the redirector reuses it rather than re-authenticating. /BLOCKNTLM only affects the authentication performed for that mapping; it does not retroactively validate an already-established session (which may have been set up with NTLM). In other words, deleting only the share under test is not enough. If another share on the same server is still connected, the test succeeds despite an NTLM dependency. Bring it down until Get-SmbConnection returns nothing. Besides your own mappings, resident applications and backup jobs can be holding sessions. If you want certainty, the fastest route is to test from a machine that has never connected to that server.
• Why step 3 is needed: a failure to resolve the name, wrong credentials, or insufficient permissions on the share itself will also make the /BLOCKNTLM run fail. If it fails without the flag too, that is not an NTLM dependency but a different problem.

Note that all you can say from this is “NTLM was not required” — not “it authenticated with Kerberos”. The prerequisite for this feature is “an SMB server that can use Kerberos”, but the destination is also allowed to be an OS that can use PKU2U.⁴ So the possibility remains that the reason for success was PKU2U rather than Kerberos. With a domain-joined file server this is unlikely to matter, but when you want to pin down what actually authenticated, either run klist on the client after connecting and check whether a cifs/ ticket for that server was obtained, or check the authentication package in the logon event in the server’s Security log (Section 4.4).

7.2. Enabling It Per Machine

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

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

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

7.3. Peers That Must Remain Go on the Exception List

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

There is no PowerShell cmdlet for creating the exception list itself, so the first time you have to configure it in the Group Policy Editor; once created, individual additions can be made by editing the registry.⁴

# 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

Caution: the sample in Microsoft’s documentation has a branch for the case where the value does not yet exist that merely sets @(""), so the entries you wanted to add are silently thrown away.⁴ The behaviour is that the first run adds no exceptions at all and only the second run does, so the code above writes the entries directly even when the value has not been created. That said, this registry value is an area managed by Group Policy in the first place. Manage permanent exceptions on the Group Policy side, and keep this operation to emergency stopgaps. The next policy application will overwrite it.

Caution: this is a feature of the SMB client.⁴ NTLM over other routes (HTTP traffic from your own applications, connections to SQL Server, WinRM, and so on) is not stopped by it. Those have to be dealt with individually according to the classification in Section 5.

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 it 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.

So the principle is to change every place that says “NTLM” to “Negotiate”. The deprecated-features entry says the same: calls to NTLM should be replaced by calls to Negotiate.¹

8.1. The Common “Explicit NTLM” in .NET

// Bad: naming 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: change only the authentication type. Pass the credentials as they were
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 you change here is only the authentication type string. If you replace credential with CredentialCache.DefaultNetworkCredentials, you change not just the authentication protocol but the identity doing the authenticating. It will authenticate 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 may stop working. Keep the protocol replacement and any review of credentials as separate changes.

If, on the other hand, you actually want to authenticate as the logged-on user (integrated Windows authentication), you can write it more simply. This is the form to use when you deliberately change “who is authenticating”.

// Integrated Windows authentication (authenticate as the current 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)”.

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

8.2. Look at “How Destinations Are Written” Before You Look at the Code

Even after you fix the code, if the destination is still an IP address, it will end 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, comb through the following.

• Server names written in config 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 provisioning documents
• Places that were rewritten to an IP during a past incident “because name resolution was flaky” and never reverted

That last item really does turn up all the time. A hard-coded IP address was the correct emergency fix at the time; 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 must register an SPN, under the name clients use for access, on the account that decrypts the ticket. As Microsoft itself notes, an application without a registered SPN falls back to NTLM even if it claims Kerberos support.³

Thinking of the registration target simply as “the account running the service” is where IIS trips you up. IIS Windows authentication 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 used by HTTP.sys. If you run the application pool under a dedicated domain account and therefore register the site’s HTTP SPN on that account, the SPN owner and the account that actually decrypts diverge, and rather than merely 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.

• Decrypt with the machine account (leave the default): if the site is published under a host name, register that host name’s HTTP SPN on the machine account.
• Decrypt with the application pool identity: enable useAppPoolCredentials and register the HTTP SPN on the application pool’s account.

Which you choose comes down to whether multiple servers share the same service account (if they do, standardising on the pool identity is easier to manage). Note that an SPN can only be registered on one account, so when switching, do not forget to delete the old registration. Duplicate registrations break Kerberos authentication itself.

If your design has the service impersonate the client to reach other servers (delegation), NTLM and Kerberos differ. Kerberos supports a delegation mechanism where a service connects to another service on the client’s behalf, whereas what NTLM provides goes only as far as the authorisation information needed for local impersonation.⁸ Implementing 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 this together, the order of work is as follows. Every stage is conditional on being reversible.

9.1. Stopping SMB Is Only Half of NTLM Remediation

Stages 4 to 6 cover SMB only. As noted in Section 7, NTLM blocking on the SMB client is a feature of the SMB client,⁴ and it does not affect other routes. Whatever you classified in stage 2 as “authenticating over HTTP”, “SQL Server is using NTLM”, or “WinRM is using NTLM” remains untouched even after you complete stage 6. And because it does not appear on the SMB exception list either, counting that list will not reveal it.

Stage 6b is where you tighten those. What you use is exactly the three policies you put into audit mode in Section 4. The procedure follows the same shape.

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

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

“We blocked SMB, so NTLM remediation is complete” is wrong. 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 “One Full Business Cycle”, Not by Number of Days

The most common failure in stage 1 is how the period is decided. Declare it complete “because we collected for two weeks” and anything that did not run during those two weeks is not on the list. And whatever is not on the list breaks for the first time after you distribute the block in stage 6.

The things most easily missed are, concretely:

• Monthly and quarterly closing processes. A month-end batch connecting to a shared folder or a database by hard-coded IP is the classic case.
• Annual processes. Stocktakes, fiscal-year rollovers, year-end accounts.
• Routes that are only exercised during an incident. Restore-from-backup procedures, failover to a standby server, DR drills.
• Machines that are offline for long periods. Laptops taken off-site, machines belonging to staff on extended leave, spare machines normally left powered off.
• Business applications used only a few times a year.

Microsoft’s own guidance notes that analysis can extend to several months depending on the complexity of the deployment.³ The realistic line to draw is one of the following.

1. Keep the audit running until the business has gone round once. At minimum one month-end close, and ideally spanning a quarter.
2. Enumerate low-frequency processes and deliberately execute them. If you cannot wait out the period, run the closing processes and DR procedures in a test environment and add the results to the list. The key is to interview the owners in advance and enumerate the processes that “produce no events only because they haven’t been run”.

In either case, get to a state where you can distinguish “no event was produced” from “it hasn’t run yet” before moving to the next stage.

9.3. Don’t Swing Straight to Deny

The key point here is not to swing “Outgoing NTLM traffic = Deny all” in one move. Microsoft says that setting this policy to deny can cause many NTLM authentication requests to fail and reduce productivity, so before implementing it you should check the logs with “Audit all”, analyse the servers, and build an exception list of what to exclude.⁷ The same warning is given for the domain-wide “NTLM authentication in this domain” policy.¹¹

10. Summary

• All versions of NTLM were deprecated in June 2024. This is not a change that stops anything immediately; NTLM 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 / Windows Server 2025). Devices that can only speak NTLMv1, and hosts recorded with NTLM V1, are your nearest deadline.¹
• Retirement has three phases: phase 1 is auditing, phase 2 (second half of 2026) is IAKerb and the local KDC, and phase 3 is disabling by default.²
• Auditing means putting three policies into audit mode and collecting Microsoft-Windows-NTLM/Operational. For domain accounts, follow 8004 on the DC → 8003 on the member server → 8001 on the client, which finally gets you to the application name. Authentication with local accounts produces no 8004, so pick that 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 come down to “names”. Simply clearing hard-coded IP addresses and unregistered SPNs greatly reduces the remaining exceptions.³²
• NET USE \\server\share /BLOCKNTLM is the safest way to corroborate, one connection at a time, without changing a policy.⁴
• In your own applications, replace explicit NTLM with Negotiate and standardise destination names on FQDNs.⁵
• An exception list is a stay of execution, not a solution. Use “is the count going down year on year?” as your 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 Practically with Get-WinEvent — Filtering Speed Determines Investigation Time
• A Practical Guide to Process Monitor (ProcMon) — Pinpointing “Settings Not Applied” and “ACCESS DENIED” in 10 Minutes
• Getting Started with 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 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 can't tell which application it is.

That's 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's 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's 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; they 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.