KB5127648, BlockNtlmv1SSO and PEAP-MSCHAPv2: what we hit, the rollback we almost shipped, the one registry value that fixed it, how to hunt for exposure, and the exit plan Microsoft expects you to have.
- What broke: After the October 13, 2026 cumulative update (KB5127648 on Windows 11, KB5126646 on Server 2025), devices on WPA2-Enterprise Wi-Fi using PEAP-MSCHAPv2 with automatic Windows sign-in stopped connecting.
- Why: The update flipped the default of BlockNtlmv1SSO from Audit (0) to Enforce (1) on every device where the value was never set and Credential Guard is off. MS-CHAPv2 is NTLMv1-derived, so Windows now refuses to hand it the credentials.
- Fix (temporary): BlockNtlmv1SSO = 0. Keep the October patch installed. Do not roll it back.
Real fix: Move Wi-Fi, wired 802.1X and VPN off MS-CHAPv2 to certificate-based authentication (EAP-TLS / PEAP-TLS), then set the value back to 1.
1. What we saw
On the morning after October Patch Tuesday, a managed-services client reported that Windows 11 laptops could no longer join the corporate wireless network. Everything else looked normal:
- The corporate SSID was visible; the device started 802.1X authentication and never completed it.
- Phone hotspots and WPA2-Personal networks worked fine on the same laptops.
- Every affected device had the October cumulative update installed. Devices that hadn’t patched yet were unaffected.
- Multiple hardware models and wireless chipsets were affected, so this was not a driver problem.
The pattern pointed squarely at the update. The client also didn’t run Intune, endpoints were managed with on-prem Group Policy and a third-party RMM tool, which shaped every decision that followed.
2. The rollback we almost shipped
With users offline, the first ask was the obvious one: roll the October update back, silently, across the fleet. We built that script before we knew the root cause. It’s worth walking through because it was the wrong fix, and because the mechanics of removing a modern LCU trip a lot of people up.
Why wusa.exe /uninstall doesn’t work any more
Since 2021, Windows 10/11 cumulative updates ship as a combined SSU + LCU package. The servicing stack part can’t be removed, so wusa.exe /uninstall /kb: fails. You have to find the LCU’s CBS package (named Package_for_RollupFix~…) and remove it with DISM:
FIND AND REMOVE THE LCU PACKAGE (ADMIN)
dism /Online /Get-Packages /English | findstr /i "RollupFix"FIND AND REMOVE THE LCU PACKAGE (ADMIN)
dism /Online /Get-Packages /English | findstr /i "RollupFix"
dism /Online /Get-PackageInfo /PackageName:<RollupFix package> /English | findstr /i "KB" dism /Online /Remove-Package /PackageName:<RollupFix package> /Quiet /NoRestartOur production version wrapped this with everything an unattended RMM run needs:
- Relaunches itself in 64-bit PowerShell (32-bit DISM can’t service a 64-bit OS, and many RMM agents are 32-bit).
- Maps each RollupFix package back to its KB with /Get-PackageInfo, so it only removes the KB you name.
- Pauses quality updates for 35 days via PauseQualityUpdatesStartTime/EndTime so Windows Update doesn’t reinstall the KB overnight.
- Gives the user a 6-hour restart window: a toast now, a reminder at T-1h, and a forced restart with a 15-minute warning at the deadline. Rebooting early cancels the forced restart.
In testing, the DISM removal took several minutes with no progress output (normal: /Quiet hides the progress bar, and LCU removal routinely takes 5–20 minutes). It worked, but while it ran we found the real cause.
Lesson
Rolling back a cumulative update removes a month of security fixes to work around a configuration default. Before you roll back a Patch Tuesday LCU, check whether the update changed a default you can set explicitly. This month it did.
3. Root cause: BlockNtlmv1SSO flips to Enforce
The fix that the community converged on (and that worked for us) was a single registry value: HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BlockNtlmv1SSO. This is part of Microsoft’s staged NTLMv1 hardening, which was announced over a year ago in KB5066470.
| Value | Mode | Behaviour | Event logged |
| 0 | Audit | NTLMv1-derived credential use is logged and allowed | 4024 (Warning) |
| 1 | Enforce | NTLMv1-derived credential use for SSO is blocked | 4025 (Error) |
| Not set | Depends on patch level | Audit before Oct 2026; Enforce from the Oct 2026 update | 4024 or 4025 |
Both events are written to Applications and Services Logs → Microsoft → Windows → NTLM → Operational.
The timeline Microsoft published
| Date | Change |
| Late August 2025 | NTLMv1-derived credential auditing enabled on Windows 11 24H2 and later (Audit mode) |
| September 2025 onward | Changes roll out to Windows 11 24H2+ clients in Audit mode |
| November 2025 | Rollout to Windows Server 2025 begins |
| October 2026 | Default changes from Audit (0) to Enforce (1), only where BlockNtlmv1SSO has not been deployed |
So this wasn’t a bug. Microsoft’s Message Center post MC1508562 (published October 15, 2026) describes it as a planned change, not a known issue. Every affected device had been logging Event 4024 for over a year; nobody was collecting that log.
Why PEAP-MSCHAPv2 is caught by an NTLMv1 control
This is the part that confuses people, because nobody configured “NTLMv1” anywhere. The chain is:
- MS-CHAPv2 is NTLMv1 cryptography. It’s a challenge-response built on the NT hash of the password, with the same weak DES-based construction as NTLMv1. A captured exchange can be cracked offline, which is exactly why Microsoft is retiring it.
- “Automatically use my Windows logon name and password” is SSO. With that box ticked, Windows derives the MS-CHAPv2 response from the cached logon credentials, silently, with no prompt. That derivation is the “NTLMv1-derived credential for SSO” that BlockNtlmv1SSO controls.
- Enforce blocks the derivation. LSA refuses to generate the response, the EAP supplicant has nothing to send, the RADIUS (NPS) server rejects the attempt, and the device never gets on the network.
MC1508562 lists the affected scope explicitly: Wi-Fi, Ethernet (wired 802.1X) and VPN connections using MS-CHAPv2, including PEAP-MSCHAPv2 and EAP-MSCHAPv2, on devices with Credential Guard disabled. Manually typed credentials still work, but they can’t be saved.
Why Credential Guard devices were fine
Credential Guard already isolates the NT hash and blocks NTLMv1-derived SSO. If any of your devices have it on, they were already unable to do PEAP-MSCHAPv2 SSO before October, so the October change does nothing to them. If you’ve ever had “Wi-Fi breaks when we enable Credential Guard”, this is the same root cause.
What the client’s Wi-Fi policy actually looked like
The client initially said “we use EAP”. That’s true of every 802.1X network; EAP is the framework, not the method. The Group Policy wireless profile showed the real configuration:
| Setting | Configured value | Why it matters |
| Authentication / Encryption | WPA2-Enterprise, AES, 802.1X | Enterprise auth via RADIUS |
| Computer Authentication | Computer only | Device authenticates with its computer account |
| Authentication method | Protected EAP (PEAP) | Outer TLS tunnel |
| Inner method | Secured password (EAP-MSCHAP v2) | NTLMv1-derived: in scope |
| Use Windows logon name and password | Enabled | SSO: exactly what Enforce blocks |
| Validate server certificate | Enabled | Good |
| Connect to these servers | (blank) | RADIUS server names not pinned |
Note the Computer only setting. Microsoft’s documentation frames the change as protecting user credentials, but in our case machine-account PEAP-MSCHAPv2 was blocked too, and setting the value to 0 restored it. Don’t assume a computer-auth Wi-Fi profile is out of scope.
4. Are you affected? Three checks
Check 1: Which EAP method does the profile use?
COMMAND PROMPT (ADMIN)
netsh wlan show profiles
netsh wlan export profile name="<Corporate SSID>" folder=C:\Temp
Open the exported XML and look at the <Type> values in the EAP section:
| EAP Type | Method | Affected? |
| 25 | PEAP (outer) | Depends on inner method |
| 26 | EAP-MSCHAPv2 | Yes |
| 21 | EAP-TTLS | Yes, if inner method is MSCHAPv2 |
| 13 | EAP-TLS (certificates) | No |
25 with 26 nested inside it is PEAP-MSCHAPv2, the most common enterprise Wi-Fi configuration still in the wild.
Check 2: Is the registry value set?
COMMAND PROMPT
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO
| Output | Meaning |
| REG_DWORD 0x0 | Audit: workaround applied, SSO allowed |
| REG_DWORD 0x1 | Enforce: explicitly blocked |
| ERROR: unable to find… | Not set: the October default (Enforce) applies |
Check 3: What does the NTLM log say?
This PowerShell one-liner gives you a per-device verdict and is ideal for an RMM script or Defender Live Response:
POWERSHELL (RUN AS SYSTEM OR ADMIN)
$e = Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -ErrorAction SilentlyContinue
$v = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue).BlockNtlmv1SSO
"{0} | Audit(4024): {1} | Blocked(4025): {2} | BlockNtlmv1SSO: {3}" -f $env:COMPUTERNAME,
@($e | Where-Object Id -eq 4024).Count, @($e | Where-Object Id -eq 4025).Count,
$(if ($null -eq $v) {'not set'} else {$v})
- 4025 present: blocked right now.
- 4024 present, value not set: will break as soon as it takes the October update.
- No events: this device isn’t using NTLMv1-derived SSO.
5. The fix: set BlockNtlmv1SSO = 0
We validated this on the first affected laptop: set the value, restarted, and the device rejoined corporate Wi-Fi with the October update still installed. A restart may not be strictly required, but in practice restart to make sure LSA and the WLAN service pick it up.
Option A: Command Prompt / RMM one-liner
APPLY (ADMIN)
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f
REVERT (ONLY AFTER MIGRATING OFF MS-CHAPV2)
reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f
:: or be explicit:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 1 /f
Option B: Group Policy Preferences (on-prem AD)
This is what we recommended for the client, scoped to the same computers as the wireless GPO:
| Field | Value |
| Location | Computer Configuration → Preferences → Windows Settings → Registry |
| Action | Update |
| Hive | HKEY_LOCAL_MACHINE |
| Key Path | SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 |
| Value name | BlockNtlmv1SSO |
| Value type / data | REG_DWORD / 0 |
Option C: Intune Remediation
For Intune-managed fleets, a Remediation keeps the value enforced and gives you a per-device compliance report. Run as SYSTEM, in 64-bit PowerShell.
DETECT-BLOCKNTLMV1SSO.PS1 $v = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue).BlockNtlmv1SSO if ($v -eq 0) { Write-Output "Compliant: BlockNtlmv1SSO = 0 (Audit)"; exit 0 } Write-Output ("Non-compliant: BlockNtlmv1SSO = {0}" -f $(if ($null -eq $v) {'not set'} else {$v})) exit 1Scope it, don’t blanket it
Only devices that actually depend on MS-CHAPv2 SSO need the exception. Target the group that receives the PEAP-MSCHAPv2 Wi-Fi or VPN profile, not “All devices”. Every device you put in Audit mode is a device generating crackable NTLMv1-derived responses.
6. Hunting for exposure across tenants
With Sentinel / Log Analytics
Add a Data Collection Rule with the XPath Microsoft-Windows-NTLM/Operational!*[System[(EventID=4024 or EventID=4025)]], then:
KQL: SENTINEL
Event
| where TimeGenerated > ago(30d)
| where EventLog == "Microsoft-Windows-NTLM/Operational" and EventID in (4024, 4025)
| summarize AuditHits = countif(EventID == 4024),
Blocked = countif(EventID == 4025),
LastSeen = max(TimeGenerated) by Computer
| extend Status = iff(Blocked > 0, "BLOCKED - impacted now", "Audit - breaks under Enforce")
| order by Blocked desc, AuditHits desc
REMEDIATE-BLOCKNTLMV1SSO.PS1 $path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' try { if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null } New-ItemProperty -Path $path -Name BlockNtlmv1SSO -PropertyType DWord -Value 0 -Force | Out-Null $v = (Get-ItemProperty -Path $path -Name BlockNtlmv1SSO).BlockNtlmv1SSO if ($v -ne 0) { throw "Value reads $v after write" } Write-Output "BlockNtlmv1SSO set to 0 (Audit). Restart recommended." exit 0 } catch { Write-Output "Failed: $($_.Exception.Message)" exit 1 }If the NPS servers’ Security log is collected (with “Audit Network Policy Server” enabled), you can also see who is still authenticating with MS-CHAPv2 from the RADIUS side. Events 6272 (granted) and 6273 (denied) carry the EAP type. A spike in 6273 after Patch Tuesday is your outage signal.
With Defender for Endpoint only
MDE doesn’t ingest the NTLM Operational log, so you can’t see 4024/4025 directly. You can still triage. This query finds devices that used to join the corporate SSID and stopped after the update, while still reporting in over another network:
KQL: DEFENDER XDR ADVANCED HUNTING
let CorpSSIDs = dynamic(["CorpWiFi"]); // your 802.1X SSID name(s)
let UpdateDate = datetime(2026-10-13); // October Patch Tuesday
DeviceNetworkInfo
| where Timestamp > ago(30d) and NetworkAdapterType == "Wireless80211"
| mv-expand cn = ConnectedNetworks
| extend SSID = tostring(cn.Name)
| summarize LastOnCorp = maxif(Timestamp, SSID in~ (CorpSSIDs)),
LastReport = max(Timestamp)
by DeviceId, DeviceName
| where isnotempty(LastOnCorp) and LastOnCorp < UpdateDate and LastReport > UpdateDate
| order by LastOnCorp desc
And to track where the workaround has been deployed (and later, rolled back):
KQL: DEFENDER XDR ADVANCED HUNTING
DeviceRegistryEvents
| where Timestamp > ago(30d)
| where RegistryKey has @"Control\Lsa\MSV1_0" and RegistryValueName =~ "BlockNtlmv1SSO"
| summarize arg_max(Timestamp, RegistryValueData, InitiatingProcessFileName) by DeviceName
| project DeviceName, Timestamp, Value = RegistryValueData, SetBy = InitiatingProcessFileName
Confirm the shortlist with the PowerShell check from section 4 via your RMM or Live Response. DeviceRegistryEvents only records changes, so “no row” means “not changed in the window”, not “not set”.
7. What Microsoft told us
We opened a Microsoft support case in parallel to confirm the workaround was supported and to get a removal timeline. The guidance back from the investigation was clear:
Microsoft support guidance
BlockNtlmv1SSO = 0 should be considered a temporary workaround and not a permanent solution. Microsoft is moving toward NTLM deprecation.
The long-term recommendation is to move away from PEAP-MSCHAPv2 and migrate corporate Wi-Fi authentication to a certificate-based method such as EAP-TLS. Microsoft currently has no stated timeline for removal of the BlockNtlmv1SSO = 0 workaround, but the investigation explicitly identifies the approach as temporary.
That lines up with MC1508562, which says the Audit option should be “evaluated carefully and not used long-term”, and asks organizations that use it to:
- Assess continued NTLMv1-derived credential generation against their security and compliance requirements.
- Document the exception and limit its duration.
- Monitor Event ID 4024.
- Plan to return devices to Enforce mode.
Read “no stated timeline” as “no guaranteed timeline”. Microsoft’s broader direction (see Advancing Windows security: Disabling NTLM by default) is NTLM off by default. Build your exit plan now, not when the next default flips.
8. The exit plan: certificate-based 802.1X
MS-CHAPv2 isn’t just deprecated, it’s weak. Any PEAP-MSCHAPv2 network without pinned RADIUS server names is open to evil-twin access points that capture crackable challenge/responses. Certificate-based EAP removes passwords from the exchange entirely and is unaffected by any of this.
| Phase | Action | Intune-managed | On-prem / GPO |
| 0. Stabilise | Apply BlockNtlmv1SSO = 0 to affected devices only | Remediation (section 5) | GPP registry item |
| 1. Harden | Pin RADIUS server names (“Connect to these servers”) and trusted root CA in the Wi-Fi profile | Wi-Fi profile: server trust | Wireless GPO: PEAP properties |
| 2. Certificates | Issue device (and/or user) certificates | SCEP or PKCS via Intune Certificate Connector / Cloud PKI | AD CS template + autoenrollment GPO |
| 3. Profile | New Wi-Fi/VPN profile using EAP-TLS (or PEAP-TLS) | Wi-Fi (Enterprise) profile, EAP-TLS, linked to the cert profile | “Smart Card or other certificate” in the wireless GPO |
| 4. RADIUS | Add a certificate-based EAP method to the NPS network policy; run both side by side | NPS / cloud RADIUS policy | NPS network policy |
| 5. Validate | Confirm 6272 events show certificate EAP; 4024 events stop | Advanced Hunting + NPS logs | NPS logs + event check |
| 6. Close out | Remove PEAP-MSCHAPv2 profile, set BlockNtlmv1SSO = 1, remove the MSCHAPv2 NPS method | Flip Remediation to enforce 1 | Change GPP value to 1 |