Tag Archives: Windows Update

KB5127648 breaks 802.1X PEAP Wi-Fi authentication on Windows 11: cause and workarounds

Posted on by
Reply

Update, 14 October 2026: Microsoft has not yet listed the KB5127648 802.1X PEAP authentication failure as a known issue on the Windows release health dashboard or in the KB article. Everything below is based on reproducible reports from administrators, Microsoft’s own NTLMv1 documentation and my own customer cases. I will update this post when Microsoft publishes an official statement.

The October 2026 Patch Tuesday update for Windows 11, KB5127648 (OS builds 26100.9711, 26200.9711 and 26300.9711 for 24H2, 25H2 and 26H2), was released on 13 October 2026. Within hours, administrators started reporting that domain-joined clients could no longer authenticate to WPA2-Enterprise Wi-Fi using 802.1X PEAP. Wired 802.1X PEAP is affected too. WPA2-Personal and WPA3-Personal networks keep working, which is why the problem often looks like “the Wi-Fi is broken at the office but fine at home”.

I got the first call from a customer this morning: “Clients suddenly refuse to connect to our Wi-Fi, and there were no problems yesterday.” That is the fingerprint of this issue. Here is what we know, how to confirm it on an affected device, and what you can do about it today.

Symptoms of the KB5127648 802.1X PEAP issue

  • Clients on Windows 11 24H2, 25H2 or 26H2 with KB5127648 installed fail to connect to WPA2-Enterprise (802.1X) Wi-Fi.
  • Wired 802.1X PEAP on Ethernet shows “Connected, not authenticated” and loops on a 600 second block timer.
  • Authentication starts but never completes. The request never reaches the RADIUS/NPS server, so there is nothing to find in the NPS log.
  • Both machine authentication and user authentication with “Use my Windows user account” fail. Manually typing DOMAIN\username and password in the Wi-Fi prompt has been reported to work.
  • Intel and Qualcomm Wi-Fi chipsets are both affected, so this is not a driver problem.
  • Uninstalling KB5127648 and rebooting restores connectivity. Reinstalling it breaks it again.

How to confirm it in Event Viewer

Open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational (or Wired-AutoConfig > Operational for Ethernet). On an affected device you will see this sequence:

LogEvent IDMessage
WLAN-AutoConfig12011Wireless 802.1X authentication started successfully (PEAP)
WLAN-AutoConfig12014Authentication restarted, reason: OneX Held State timeout
WLAN-AutoConfig12013Authentication failed, error 0x80070285 (internal authentication error)
Wired-AutoConfig15514Authentication FAILED, reason 0x50005, error 0x80070285
Wired-AutoConfig15506Authentication suspended, Explicit EAP failure received, BlockingTime 600
EapHost2088User uses saved credentials (the only EapHost event, no Schannel certificate errors)

If the root cause below is correct, you will also find Event ID 4025 in Microsoft-Windows-NTLM > Operational: “An attempt to use NTLMv1-derived credentials for Single Sign-On was blocked due to policy.” Before the update, the same device would have logged the audit-only Event ID 4024 instead.

The likely root cause: NTLMv1 SSO is now blocked by default

Microsoft announced in 2025 that it would tighten NTLMv1 handling in Windows 11 24H2 and Windows Server 2025. The timeline in the support article Upcoming changes to NTLMv1 in Windows 11, version 24H2 and Windows Server 2025 is explicit:

  • Late August 2025: Audit logging for NTLMv1 usage enabled on Windows 11 24H2 and newer.
  • November 2025: Rollout of the changes to Windows Server 2025.
  • October 2026: The default value of the BlockNtlmv1SSO registry key changes from Audit mode (0) to Enforce mode (1). This only takes effect if the key has not been deployed explicitly.

The same article names the exact scenario that breaks: remnants of NTLMv1 cryptography are still used “when using MS-CHAPv2 in a domain-joined environment”, and the examples given are “Wi-Fi, Ethernet, and VPN deployments using MS-CHAPv2 authentication”. PEAP with the MS-CHAPv2 inner method, which is what most password-based enterprise Wi-Fi still runs on, needs the NTLMv1-derived credential for single sign-on with the logged-on user or the machine account. When Enforce mode blocks that request, EAP fails locally with 0x80070285 before a single packet reaches your RADIUS server.

The KB5127648 article does not mention NTLM, 802.1X or PEAP at all, and Microsoft’s release notes said it was not aware of any new issues apart from a USB audio problem. So the causal link is inferred from the timeline and the fact that setting the key back to 0 fixes the problem. Treat it as very likely, not confirmed.

Workaround 1: Pause the update and uninstall it on affected devices

If you manage updates with Windows Autopatch, Intune update rings or WSUS, pause the October quality update now so it does not reach more devices. If you are mid-way through a 26H2 rollout, see my post on getting ready for Windows 11 26H2 with Autopatch for how the rings and pause controls fit together. On devices that are already broken, uninstall the update and reboot:

wusa /uninstall /kb:5127648

Keep in mind that this removes the October security fixes, and that the device needs a working network to receive anything from Intune. A device without Wi-Fi cannot download a remediation script, so plan for a wired connection, a phone hotspot or hands-on work.

Workaround 2: Set BlockNtlmv1SSO back to Audit mode

Several administrators have confirmed that explicitly deploying the registry value restores PEAP authentication while keeping KB5127648 installed. This is the approach Neowin and Windows Report describe:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Reboot afterwards. The value means:

  • 0 (Audit): The request to generate NTLMv1 credentials for a logged-on user is audited but allowed. Event 4024 is logged.
  • 1 (Enforce): The request is blocked and Event 4025 is logged. This is the new default after KB5127648.

Be honest with yourself about what this does: you are rolling back a security hardening that Microsoft has been announcing for over a year. It buys time, nothing more. One administrator in the Microsoft Q&A thread put it well: setting it to 0 “only bought us time”.

Deploying the value with Intune

There is no Settings Catalog entry or Policy CSP node for this value, so use a Remediation script (Devices > Scripts and remediations) or a PowerShell script. A minimal pair that is safe to run repeatedly:

# Detect-BlockNtlmv1SSO.ps1
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
$value = (Get-ItemProperty -Path $path -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($value -eq 0) { Write-Output 'Compliant'; exit 0 }
Write-Output "Non-compliant (value: $value)"; exit 1

# Remediate-BlockNtlmv1SSO.ps1
$path = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0'
New-ItemProperty -Path $path -Name BlockNtlmv1SSO -PropertyType DWord -Value 0 -Force | Out-Null
Write-Output 'BlockNtlmv1SSO set to 0 (Audit). Reboot required.'
exit 0

Run it in the 64-bit PowerShell host, in system context, and target it at the devices that are not yet updated first. Devices that are already off the network will pick it up as soon as they get any connectivity.

The real fix: move from PEAP-MSCHAPv2 to EAP-TLS

Password-based PEAP-MSCHAPv2 has been on borrowed time for years. It depends on NTLM-era cryptography, it is vulnerable to credential relay if clients do not validate the server certificate strictly, and Microsoft is clearly moving toward blocking it. The durable answer is certificate-based EAP-TLS, which does not touch NTLM at all and is unaffected by this change.

  • Cloud-native tenants: Microsoft Cloud PKI in Intune Suite can issue device and user certificates via SCEP, and your NPS or cloud RADIUS validates them. No on-premises CA required.
  • Hybrid tenants with AD CS: Use your existing enterprise CA with an Intune Certificate Connector (SCEP or PKCS) and switch the NPS network policy to Microsoft: Smart Card or other certificate.
  • Either way: Push a new Wi-Fi profile from Intune with EAP-TLS, keep the PEAP SSID running in parallel until every device has a certificate, then retire it.

If you are also deploying Credential Guard (and you should be), note that Microsoft’s NTLMv1 article recommends it strongly. Credential Guard already blocks NTLMv1 and unconstrained delegation on its own, so a device with Credential Guard enabled is likely to have hit this wall earlier in testing.

What to tell your users and your helpdesk

  • Home Wi-Fi, hotspots and guest networks with a simple passphrase still work. Only the corporate 802.1X network is affected.
  • Typing the domain username and password manually in the Wi-Fi prompt is a usable emergency workaround for individual users.
  • Do not let users “reset network settings” or reinstall Wi-Fi drivers. It wastes time and changes nothing.

References

Windows Autopatch Groups

Posted on by
2

Every business is now very much aware of the very real threats of attacks that are lurking out there. And for any that aren’t aware, then those threats are even greater. Time and again, we hear of businesses under cyber attacks and critical data compromised. With this in mind, we all need to be looking at ways to enhance our data security.

Otherwise, your business could soon fall victim to hackers. Given the multitude of threats that businesses are constantly dealing with, Microsoft has introduced Windows Autopatch to help improve security. This solution intends to streamline the update process, thus enabling businesses to operate better. In this business solutions article, we will be exploring Windows Autopatch groups and how they function.

Windows Autopatch Recap

For the benefit of those who may not yet be familiar with the service, I’m going to start by going over what Windows Autopatch is. IT admins can attest to the challenges that they sometimes face when it comes to keeping the devices in their environments up to date. Although service providers may offer updates regularly, the process of implementing these updates can sometimes present plenty of challenges to IT staff.

With that in mind, what you get with Windows Autopatch is a cloud-based service that seeks to automate the updates for Windows, Microsoft 365 Apps for Enterprise, Microsoft Teams, and Microsoft Edge.

Due to the automation of these updates, your business can expect to improve security and productivity across the organization. Over the years, we have grown accustomed to getting regular updates. Despite that, the process of implementing them is not always a seamless one. And that’s in addition to the plethora of other tasks that IT admins are responsible for managing. The Windows Autopatch solution gives you a more reliable update method that improves efficiency.

Windows Autopatch Groups

Additionally, Windows Autopatch uses groups to better manage updates in a way that minimizes issues and improves the experience for your business. Autopatch groups, by definition, are logical containers or units that bring together several Azure AD groups and software update policies. These include:

BENEFITS OF AUTOPATCH GROUPS

Windows Autopatch aims to adapt to the needs of businesses that are using Microsoft Cloud-Managed services. It is going to meet you wherever you may be in your update management journey. The first benefit that you’ll be able to get from Autopatch groups is that they can replicate your organizational structure.

What this means is that you can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Azure AD group targeting logic. Furthermore, the use of Autopatch groups allows you to choose which software update deployment cadence is most ideal for your business.

Another benefit is a flexible number of deployments. As a result of this flexibility, you get to have the ideal number of deployment rings that will work perfectly for your business. Depending on your needs, you can have as many as 15 deployment rings per Autopatch group.

The next benefit you’ll get is being able to decide which device or devices will belong to deployment rings. In addition to your existing device-based Azure AD groups, as well as choosing the number of deployment rings, your business also has the option to select which devices belong to deployment rings during the device registration process when setting up Autopatch groups.

AUTOPATCH GROUPS WORKFLOW

There are a few steps in this high-level workflow, including these below:

  • The first step requires the creation of an Autopatch group.
  • Next, the Windows Autopatch service is going to leverage Microsoft Graph to facilitate the creation of:
  • Azure AD groups.
  • Software update policy assignments with other Microsoft services, such as Azure AD, Intune, and Windows Update for Business (WUfB,) based on IT admin choices when you create or edit an Autopatch group.
  • Intune assigns software update policies. You’re going to find that Intune assigns the software update policies to these groups as soon as the Azure AD groups become available in the Azure AD service. In addition, Intune will also provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service.
  • Lastly, we’ll go over the Windows Update for Business responsibilities and these include:
  • Delivering update policies.
  • Retrieving update deployment statuses back from devices.
  • Sending back the status information to Microsoft Intune and then to the Windows Autopatch service

Things to know

Before you can proceed to use Windows Autopatch groups, there are a few key concepts that you’ll need to familiarize yourself with.

DEFAULT AUTOPATCH GROUP

If your organization can meet its business needs using the pre-configured five-deployment ring composition, then you are the ideal candidate for the Default Autopatch group. The group has the intention of serving businesses that want to enroll in the service as well as those that want to align to Autopatch’s default update management process without the need for additional customizations. Furthermore, this group uses Windows Autopatch’s default update management process recommendation and contains:

  • A set of 5 deployment rings.
  • A default update deployment cadence for both Windows feature and quality updates.

You should also note that you cannot delete or rename the Autopatch group. But you do still get the option to customize its deployment ring composition to add and/or remove deployment rings. Additionally, you can customize the update deployment cadences for each deployment within it.

Default deployment ring composition

The software update-based deployment rings that will be used are determined by default. These deployment rings, represented by Azure AD assigned groups, are as follows:

Deployment ringUse
Windows Autopatch – TestCan only be used as Assigned device distributions.
Windows Autopatch – Ring1Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types.
Windows Autopatch – Ring2Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types.
Windows Autopatch – Ring3Can be used with either Assigned or Dynamic device distributions or have a combination of both device distribution types.
Windows Autopatch – LastCan only be used as Assigned device distributions.

An additional thing to note for instances where a group of specialized devices and/or VIP/Executive users coverage is provided by the Last deployment ring, the fifth deployment ring in the Default Autopatch group. Furthermore, to minimize any potential disruptions that your business may encounter, software updates for the aforementioned should be received after the organization’s general population.

Default update deployment cadences

Default update deployment cadences are going to be provided by the Default Autopatch group for deployment rings, with the exception of the Last (fifth) deployment ring.

Update rings policy for Windows 10 and later

Each of the default rings in the Default Autopatch group is going to get Update rings policy for Windows 10 and later set up by Windows Autopatch groups. Below is some data concerning the default policy values:

Policy nameAzure AD group assignmentQuality updates deferral in daysFeature updates deferral in daysFeature updates uninstall window in daysDeadline for quality updates in daysDeadline for feature updates in daysGrace periodAuto restart before deadline
Windows Autopatch Update Policy – default – TestWindows Autopatch – Test0030050Yes
Windows Autopatch Update Policy – default – Ring1Windows Autopatch – Ring11030252Yes
Windows Autopatch Update Policy – default – Ring2Windows Autopatch – Ring26030252Yes
Windows Autopatch Update Policy – default – Ring3Windows Autopatch – Ring39030552Yes
Windows Autopatch Update Policy – default – LastWindows Autopatch – Last11030352Yes

Feature update policy for Windows 10 and later

Each of the default rings in the Default Autopatch group is going to get feature updates for Windows 10 and later set up by Windows Autopatch groups. Below is some data concerning the default policy values:

Policy nameAzure AD group assignmentFeature update versionRollout optionsFirst deployment ring availabilityFinal deployment ring availabilityDay between deployment ringsSupport end date
Windows Autopatch – DSS Policy [Test]Windows Autopatch – TestWindows 10 21H2Make update available as soon as possibleN/AN/AN/AJune 11, 2024; 1:00AM
Windows Autopatch – DSS Policy [Ring1]Windows Autopatch – Ring1Windows 10 21H2Make update available as soon as possibleN/AN/AN/AJune 11, 2024; 1:00AM
Windows Autopatch – DSS Policy [Ring2]Windows Autopatch – Ring2Windows 10 21H2Make update available as soon as possibleDecember 14, 2022December 21, 20221June 11, 2024; 1:00AM
Windows Autopatch – DSS Policy [Ring3]Windows Autopatch – Ring3Windows 10 21H2Make update available as soon as possibleDecember 15, 2022December 29, 20221June 11, 2024; 1:00AM
Windows Autopatch – DSS Policy [Last]Windows Autopatch – LastWindows 10 21H2Make update available as soon as possibleDecember 15, 2022December 29, 20221June 11, 2024; 1:00AM

CUSTOM AUTOPATCH GROUPS

If your business needs a more precise representation of its structures as well as its own update cadence in the service, then the Custom Autopatch groups are ideal for you. You’ll also find that the Test and Last deployment rings are automatically present by default.

TEST AND LAST DEPLOYMENT RINGS

Both of these are default deployment rings, and they will be automatically present in both the Default Autopatch group and Custom Autopatch groups. These deployment rings are an essential component because they allow the recommended minimum number of deployment rings needed by each Autopatch group to be provided. In a couple of instances, you’ll find that the Test deployment ring can serve as the pilot deployment ring, with the Last serving as the production deployment ring. This can happen:

  • If only the Test and Last deployment rings are within your Default Autopatch group.
  • If at the time you are creating a Custom Autopatch group, you don’t add more deployment rings.

Something else that you need to know is that you cannot remove or even rename the Test and Last deployment rings from the Default or Custom Autopatch groups. Because these Autopatch groups require a minimum of 2 deployment rings for their gradual rollout, they won’t support using a single deployment ring as part of its deployment ring composition.

So, you will need to consider managing devices outside Windows Autopatch whenever you have a specific scenario that you want to implement using a single deployment ring and where the gradual rollout is not necessary.

Deployment rings

Autopatch groups intend to have software update deployments delivered sequentially in a gradual rollout within the. Autopatch group. Deployment rings are the tools that make this possible. Windows Autopatch can align with Azure AD and Intune terminology for device group management. As far as deployment ring group distribution in Autopatch groups is concerned, there are two types that you need to know about:

Deployment ring distributionDescription
DynamicFor this situation, one or more device-based Azure AD groups can be used. And these can be either dynamic query-based or assigned to use in your deployment ring composition. Moreover, you can use the Azure AD groups that are available with the Dynamic distribution type for the distribution of devices across several deployment rings according to the percentage values that can be customized.
AssignedFor this type of deployment ring distribution, a single device-based Azure AD group is best. And this can be either dynamic query-based or assigned to use in your deployment ring composition.
Combination of Dynamic and AssignedIn some cases, you’ll find yourself needing a greater level of flexibility when working on deployment ring compositions. And this option will prove to be the most ideal. It allows you to combine both device distribution types in Autopatch groups. You will, however, need to note that this particular combination of device distribution will not be supported for the Test and Last deployment ring in Autopatch groups.

Service-based versus software update-based deployment rings

Another thing you will discover is that Autopatch groups create 2 different layers. And each of those layers will have its own deployment ring set. By default, both of the deployment ring sets that we are looking at will assign to devices that have completed successful registration with Windows Autopatch.

SERVICE-BASED DEPLOYMENT RINGS

This deployment ring set is only going to be for keeping Windows Autopatch updated. It does so with service and device-level configuration policies, apps, and the APIs required for the core functions of the service. Below is the list of Azure AD-assigned groups representing the service-based deployment rings.

  • Modern Workplace Devices-Windows Autopatch-Test
  • Modern Workplace Devices-Windows Autopatch-First
  • Modern Workplace Devices-Windows Autopatch-Fast
  • Modern Workplace Devices-Windows Autopatch-Broad

Please note that you should absolutely avoid making any modifications to the Azure AD group membership types (Assigned and Dynamic). If you make those changes, Windows Autopatch won’t be able to read the device group membership from these groups.

As a result, the Autopatch groups feature, along with other service-related operations, will not function correctly. Not only that, but you should also know that having Configuration Manager collections directly synced to any Azure AD group and created by Autopatch groups is an unsupported option.

SOFTWARE-BASED DEPLOYMENT RINGS

The second type of deployment ring set is only going to be compatible with software update management policies, such as the Windows update ring and feature update policies, in the Default Windows Autopatch group. Below is the list of Azure AD-assigned groups representing the software updates-based deployment rings.

  • Windows Autopatch – Test
  • Windows Autopatch – Ring1
  • Windows Autopatch – Ring2
  • Windows Autopatch – Ring3
  • Windows Autopatch – Last

IT admins should note that any additional Azure AD assigned groups will be created and added to the list at the same time you’ll be adding more deployment rings to the Default Autopatch group. Moreover, similar to the previous type of deployment ring set, you can’t make any modifications to the Azure AD group membership types (Assigned and Dynamic). If you make those changes, Windows Autopatch won’t be able to read the device group membership from these groups.

As a result, the Autopatch groups feature, along with other service-related operations, will not function correctly. Not only that, but you should also know that having Configuration Manager collections directly synced to any Azure AD group and created by Autopatch groups is an unsupported option.

How to use Autopatch groups

There are a few examples that we can look at that describe certain scenarios and how we use Autopatch groups for those cases.

EXAMPLE NUMBER 1

Imagine a scenario where you are an IT admin who is responsible for several Microsoft and non-Microsoft cloud services. In this example, you don’t have the time necessary to set up and manage multiple Autopatch groups. At present, your company relies on using five deployment rings to operate it’s update management. However, you do have the option for flexible deployment cadences if you were to communicate to your end-users.

The solution, in this case, will involve using the Default Autopatch group if you currently don’t have thousands of devices under your management. The Default Autopatch group is editable to include additional deployment rings and/or slightly modify some of its default deployment cadences.

Additionally, because this Default Autopatch group comes preconfigured and doesn’t require extra configurations when registering devices with the Windows Autopatch service, it will offer greater convenience to IT admins.

EXAMPLE NUMBER 2

For the second example, you’re going to be an IT admin for a business that is looking to implement a gradual rollout of software updates within certain critical business units or departments to help mitigate the risk of end-user disruption.

What you can do in this case is to create a Custom Autopatch group for all your business units. This means that you can create a Custom Autopatch group for each department. And then, you can proceed to break down the deployment ring composition according to the various user personas. You could also perform the breakdown by categorizing how essential certain users may be for not only a particular department but for the business as a whole.

EXAMPLE NUMBER 3

In the final example, imagine being an IT admin working in the New York branch of a particular company. And in this scenario, you’re looking to implement a gradual rollout of software updates within certain departments in a way that does not disrupt operations in that New York branch.

Similar to the second example, you’re going to create a Custom Autopatch group. But this time, it will be for the New York branch. Then, you will proceed to break down the deployment ring composition according to the various departments within that branch location.

Wrap up

With the threat of cyber-attacks seemingly increasing each and every year, businesses need to be highly proactive about their security. They need to put in place measures that help to improve security and minimize vulnerabilities. Microsoft is looking to help businesses do that with the Windows Autopatch service. It is a highly efficient tool that streamlines the management of software updates and patches.

Autopatch leverages groups to enable businesses to get the maximum benefits from the service. This is also while taking into account the unique needs of the business. Therefore, what you ultimately get is a solution that can cut the security gap. And one that optimizes your IT resources in a way that improves productivity.