When NTLM breaks in an office, the culprit is rarely a Windows PC. It is the ten-year-old printer that scans to a folder, the NAS nobody has updated since installation day, or the Wi-Fi sign-in that quietly relied on NTLMv1 cryptography all along.
Microsoft has removed the NTLMv1 protocol from Windows 11 version 24H2 and Windows Server 2025. That is a fact, not a plan. But plenty of hardware and software in real offices still speaks only NTLMv1 - or uses credentials derived from it. When such a device meets a modern Windows machine, authentication simply fails, and the error rarely names the real reason. This page lists the usual suspects, the exact October 2026 change that broke office Wi-Fi sign-ins, and what you can honestly do about each one.
The devices and flows that most often turn out to depend on NTLMv1 when it stops working.
Scan-to-folder is the classic casualty. The printer logs into a Windows share with a stored account, and old firmware often offers only NTLMv1. On a hardened or 24H2 machine, the share refuses it and the printer reports a vague send error. Your options, in order:
This one caught whole offices by surprise. Connections that use MS-CHAPv2 single sign-on - typical for domain Wi-Fi (WPA2-Enterprise with PEAP), wired 802.1X and some VPNs - use credentials derived from NTLMv1 even on modern Windows. Microsoft documented the roadmap honestly: audit mode arrived with the September 2025 updates, and the October 2026 updates (including KB5127648) changed the default of BlockNtlmv1SSO from Audit to Enforce where the value had not been set explicitly.
Treat the bridge as a bridge: the real fix is moving the network sign-in to certificate-based authentication (EAP-TLS) or another method that does not depend on NTLMv1 cryptography.
0x80070285 (WLAN-AutoConfig event 12013), yet typing the same user name and password manually succeedsHKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 - BlockNtlmv1SSO set to 0 restores Audit mode as a temporary bridgeBudget NAS boxes and old Linux-based devices often ship an SMB stack that tops out at NTLMv1, and legacy business software sometimes calls NTLM directly instead of the Negotiate package that would try Kerberos first. Microsoft's documented advice for applications is mechanical: replace explicit NTLM calls with Negotiate, which tries Kerberos first.
Whatever the suspect, the sequence is the same. Identify it with the audit logs (events 8001 to 8004 and the Package Name field in event 4624). Try the vendor fix - firmware, settings, or a newer version. If no fix exists, contain it: a dedicated account with the least rights possible, its own network corner, and an exception scoped to that one server. A legacy device is a reason for a small, watched exception - it is never a reason to switch NTLMv1 back on for the whole network.
BlockNtlmv1SSO back to Audit, or lowering authentication levels so an old printer works, makes your network measurably weaker - NTLMv1 can be cracked trivially. If you use such a bridge, write down an expiry date and the real fix beside it. A bridge without a date quietly becomes the permanent road.The full process with live demonstration - every setting shown on screen, step by step.
Watch Full VideoBecause that update changed the BlockNtlmv1SSO default from Audit to Enforce. Wi-Fi single sign-on using MS-CHAPv2 relies on NTLMv1-derived credentials, so single sign-on is rejected (error 0x80070285) while typing credentials manually still works. The durable fix is certificate-based network authentication.
Yes - scan-to-folder on old firmware is one of the most common reasons. Check for a firmware update and an NTLMv2 setting first; if neither exists, move the workflow to scan-to-email or isolate that one printer instead of weakening the server.
NTLMv2 still works today and Microsoft says in-market Windows versions continue to support NTLM, but NTLM as a whole is deprecated and no longer under active development. Plan the move to Kerberos; do not treat NTLMv2 as a permanent home.