Windows’ October NTLMv1 Change Could Break Old VPN and Wi-Fi Sign-Ins

A Windows update can expose a network dependency that has been invisible for years. Microsoft says its October 2026 security update applies a planned hardening change that restricts generation of NTLMv1-derived credentials for single sign-on. The affected path is specific: devices without Credential Guard may be unable to connect through Wi-Fi, Ethernet or VPN configurations that rely on MS-CHAPv2. For IT teams, this is a compatibility warning with a security deadline behind it, not a reason to disable the update across the fleet.

What changes, and on which devices

Microsoft lists Windows 11 versions 24H2, 25H2 and 26H2, and Windows Server 2025. The notice says that beginning with the October 2026 security update, these systems enforce restrictions by default on generating NTLMv1-derived credentials for SSO. Microsoft frames this as part of its broader effort to phase out NTLM and says the impact is limited to devices without Credential Guard that use MS-CHAPv2 authentication pathways. ^{[1] [2]}

The symptom Microsoft calls out is not a generic failure of all Wi-Fi or VPN connections. It is a sign-in problem for a narrower class of networks where MS-CHAPv2 is used to derive or reuse credentials for single sign-on. An affected user may still connect using a different authentication method or a separate prompt, depending on the deployment. The exact behavior depends on the network’s identity provider, device policy and configuration; Microsoft’s notice does not say that every organization will see an outage. ^[1]

This distinction matters for incident response. The change was documented as planned and is not listed as a known defect in the October update. If connections fail after patching, compare the affected devices’ Windows versions, Credential Guard state and network authentication method before attributing the failure to the patch generally. Our Exchange update incident guide covers a separate October Windows issue with different symptoms and guidance.

Why the old pathway is being removed

NTLMv1 and password-derived authentication methods persist in networks built around older compatibility requirements. That convenience can leave reusable credential material exposed to attack or relay in ways that modern authentication protocols are designed to reduce. Microsoft has been documenting a broader transition away from NTLM and its reliance on legacy mechanisms. Credential Guard helps protect credentials by isolating secrets using virtualization-based security, but it does not make every legacy authentication dependency a good long-term choice. ^{[2] [3]}

A hardening change can therefore be both a breaking change for an old configuration and a security improvement. The operational task is to find the dependency before the user reports it: identify wireless and VPN profiles using MS-CHAPv2, determine whether the affected SSO flow is actually enabled, and map which device classes have Credential Guard off. Avoid broad assumptions based only on the product name “VPN”; certificate-based EAP-TLS and other modern configurations do not become MS-CHAPv2 just because they connect remotely.

A practical migration path

1. Inventory the network methods. Export managed Wi-Fi and VPN profiles, authentication policies and RADIUS/NPS settings. Identify MS-CHAPv2 explicitly rather than relying on a vendor or profile label.
2. Map the Windows estate. Separate supported Windows versions and build numbers, then establish Credential Guard status through the management tools already used by your organization.
3. Test representative sign-ins. Use a small pilot covering remote VPN, campus or office Wi-Fi, Ethernet 802.1X and any special device classes. Capture the authentication exchange and user-facing result before broad rollout.
4. Replace the dependency. Microsoft recommends removing MS-CHAPv2 dependencies and migrating Wi-Fi and VPN connections to certificate-based authentication. Build certificate enrollment, renewal, revocation and help-desk recovery into the plan. ^[1]
5. Use temporary audit or allow settings only under change control. Microsoft documents a temporary registry option to allow and audit affected connections while dependencies are removed. Treat it as a time-bounded migration aid, record the owner and expiry, and return systems to enforcement after cutover. Follow the current Microsoft guidance for the exact configuration. ^[1]

The often-missed work is certificate lifecycle management. Replacing one password prompt with a certificate does not complete the job if users cannot enroll or renew certificates away from the corporate network. Build that recovery path and test it before the old method is blocked.

What administrators should verify now

Microsoft’s current notice is the source of truth for supported versions, impact conditions and migration advice. Check it alongside the relevant Windows release-health and NTLM documentation because rollout behavior and guidance can change. Do not broadly disable Credential Guard or remove the October update as a first response; those actions can weaken the protection the change is meant to strengthen while leaving the authentication dependency unresolved.

If your organization does not use MS-CHAPv2, or already has a certificate-based network design, this specific warning may not require a change. If it does, an inventory and pilot now can turn a surprise sign-in failure into a managed migration with clear scope and rollback criteria.