A login that worked yesterday can simply stop going through after the next Windows update – without you having changed anything on your server.
- From October 13, 2026, Microsoft begins blocking the remnants of NTLMv1 in Windows 11 from 24H2 and Windows Server 2025 via update.
- The registry value
BlockNTLMv1SSOchanges from 0 (audit only) to 1 (enforce). The update is rolled out in stages, not to everyone at the same time. - Mainly affected are old applications, shares and mechanisms such as MS-CHAPv2 in domain-joined environments. If you use Kerberos, you will usually notice nothing.
What Microsoft is changing now
NTLM (NT LAN Manager) has been an authentication method in Windows networks for over three decades. In domains, Kerberos replaced it long ago, but NTLM remained as a fallback: if a participant cannot do Kerberos, Windows falls back to NTLM. That fallback is exactly the problem. At the latest since Mandiant published rainbow tables for cracking it, NTLMv1 has been considered finished from a security standpoint.
Microsoft has already removed the protocol itself from Windows 11 24H2 and Windows Server 2025. In some scenarios, however, remnants of the NTLMv1 cryptography remain, for example with MS-CHAPv2 in a domain-joined environment. Microsoft is now switching these remnants off by no longer using credentials derived from NTLMv1. Technically, this is the default value of BlockNTLMv1SSO:
| Phase | Value of BlockNTLMv1SSO | Effect |
|---|---|---|
| Since September 2025 | 0 | Audit mode: NTLMv1 usage is logged, nothing is blocked |
| From October 13, 2026 | 1 | Enforce mode: NTLMv1 SSO is disabled |
Who is affected – and who is not
The change affects Windows 11 from 24H2 and Windows Server 2025. If your root server runs an older Windows Server, the update topic is secondary for you for now. It is still worth a look: in spring 2026 Microsoft declared NTLM “deprecated” and announced its deactivation for the next Windows version. The road only goes in one direction.
It becomes critical wherever something on the network still depends on old mechanisms:
- Old applications: Software that cannot authenticate via Kerberos and relies on the NTLM fallback.
- Shares and devices: NAS, scanners or third-party systems that access directory shares only with the old sign-in method. There is already a known case from practice in which an app had problems with directory shares after the NTLM change.
- MS-CHAPv2: Mechanisms built on it, such as some VPN or access solutions in domain-joined environments.
- A known, practically cracked method disappears.
- The pressure helps to finally clean up old dependencies.
- Old systems can fail without warning.
- The staged rollout makes the timing hard to predict.
Check in five steps whether your server is affected
The following steps run in a PowerShell with administrator rights. Take a snapshot or a backup beforehand – you are not changing anything at first, but when you make adjustments you want a way back.
- Determine the Windows version. The change affects Windows Server 2025 and Windows 11 from 24H2.
Get-ComputerInfo | Select-Object OsName, OsVersion - Look up the current value of BlockNTLMv1SSO. The command searches the Control branch of the registry. If the value does not exist yet, the default applies – and that changes with the update.
reg query HKLM\SYSTEM\CurrentControlSet\Control /s /f BlockNTLMv1SSO - Evaluate the audit results. In audit mode, Windows logs where NTLMv1 is still used. How to enable and evaluate auditing is described by Microsoft under “Disabling NTLM”. Note down every application and every device that shows up there.
- Switch dependencies to Kerberos. This is the actual solution. Connect with server names instead of IP addresses, because Windows often falls back to NTLM when you use an IP. Check whether the affected software supports Kerberos, and update it if so.
- Test before the update. Apply the change to a copy of the server first, not to the production system, and test every login path once.
BlockNTLMv1SSO back to 0 when something breaks. At best, that is a stopgap to buy time for the migration. A method that can be cracked publicly with a rainbow table is not something you want to permanently allow on a server close to the internet.How you know it worked
After switching to Kerberos and installing the update, you check three things:
- Sign-ins: Every documented application and every share still signs in.
- Audit log: No new NTLMv1 entries appear anymore.
- Registry value: Running the
reg querycommand again shows either the value 1 or no entry anymore, in which case the new default applies.
With NTLMv1, the question is not “if” but “when it reaches you”.
The Windows server in the bigger picture
NTLMv1 is only one building block. If your Windows server is reachable from the internet, you should first get remote access under control – how to do that is covered in our article Windows RDP reachable from the internet: How to secure access properly. If you would rather offer access only through an encrypted tunnel, the VPN server on the root server shows an approach for not exposing RDP to the internet in the first place.
If you are planning a new Windows server and want to start directly with Windows Server 2025 and Kerberos basics, take a look at the Windows VPS. That way you test the new default setting from the start instead of switching later.
Your checklist for this week
- Inventory: List all services and devices that sign in to your Windows server.
- Audit: Evaluate the NTLMv1 logging, provided it is active.
- Kerberos: Switch over everything that can do it – and plan the replacement for the rest.
- Test: Check the change on a copy before the update reaches the production server.
You can find the details on the schedule and the registry settings in the Microsoft support article “Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025”. We summarized the key facts here from the notice on Born’s IT and Windows blog dated October 13, 2026.
