DEV Community

Michael Oteng
Michael Oteng

Posted on

Wi-Fi or VPN sign-in failing after a Windows update? What to check

#windows #networking #security #powershell

When a user says their Wi-Fi or VPN stopped working after an update, there are quite a few things to check. Drivers, connection profiles, credentials and the network itself can all come into it.

One more thing worth checking after the October 2026 Windows updates is how the connection handles automatic sign-in.

This walkthrough is based on Microsoft’s published guidance. It is a troubleshooting reference, rather than a report of an incident I have personally reproduced.

What changed?

Microsoft’s 13 October 2026 update changes the default handling of NTLMv1-derived single sign-on credentials from auditing to blocking.

The documented scope covers Windows 11 24H2, 25H2, 26H2 and Windows Server 2025 where Credential Guard is disabled and BlockNtlmv1SSO is unset.

Connections using MS-CHAPv2, including certain Wi-Fi, wired network and VPN configurations, can be affected.

A useful clue is that automatic sign-in may fail while manually entering credentials still works.

That gives you a direction to investigate. It does not, on its own, confirm the cause.

Start with the affected computer

Before changing anything, record:

  • The Windows version and OS build from winver.
  • The installed update from Windows Update history.
  • When the failure started.
  • Whether it affects Wi-Fi, wired access, VPN, or more than one.
  • Whether manual sign-in behaves differently.

I would also compare an affected device with a working one, where possible. Keep the comparison specific: the same connection, similar configuration and the same test.

Check whether Credential Guard is running

Open System Information by running:

msinfo32
Enter fullscreen mode Exit fullscreen mode

Under System Summary, look for Virtualization-based security Services Running and check whether Credential Guard appears.

You can also query it from an elevated PowerShell session:

$deviceGuard = Get-CimInstance `
    -Namespace 'root\Microsoft\Windows\DeviceGuard' `
    -ClassName Win32_DeviceGuard `
    -ErrorAction Stop

[pscustomobject]@{
    CredentialGuardRunning = (
        $deviceGuard.SecurityServicesRunning -contains 1
    )
}
Enter fullscreen mode Exit fullscreen mode

True means the returned running-services list includes Credential Guard.

If the query fails, treat the result as unknown. A failed query does not prove that the feature is disabled.

Microsoft documents these verification methods in its Credential Guard configuration guide.

Check the authentication method

Review the deployed Wi-Fi, wired or VPN profile with whoever manages it. Look specifically for MS-CHAPv2, including PEAP-MSCHAPv2 and EAP-MSCHAPv2.

Record the actual configuration rather than assuming every device receives the same settings.

Look for matching events

In Event Viewer, open:

Applications and Services Logs → Microsoft → Windows → NTLM → Operational

Microsoft identifies:

  • 4024: an audited attempt.
  • 4025: a blocked attempt.

This read-only PowerShell query retrieves those events from the last seven days:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 4024, 4025
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction Stop |
    Select-Object TimeCreated, Id, Message |
    Format-List
Enter fullscreen mode Exit fullscreen mode

Compare the timestamps and event details with the failed connection attempt. An unrelated event elsewhere in the week is not enough to explain the user's problem.

If no matching events are returned, keep investigating. If access is denied or the log cannot be read, resolve that before interpreting the result.

What about a temporary fix?

Microsoft documents an audit-mode exception, but it reduces protection and should be scoped and temporary. Follow KB5066470 for the settings and current guidance.

Before making an exception, record the affected devices, the reason, who owns the remediation and when it will be reviewed.

Add sign-in to the update test

For a pilot deployment, I would include:

  • Automatic network sign-in after a restart.
  • VPN connection and reconnection.
  • Access to the internal resources users actually need.
  • A check for new authentication errors.

It is easy to focus on whether an update installed successfully. For the person using the computer, the more useful test is whether they can still connect and get on with their work.

Top comments (0)