Windows 11 22H2 breaks MSCHAPv2 authentication for WiFi and wired connections

Kind of a big deal
Kind of a big deal

Windows 11 22H2 breaks MSCHAPv2 authentication for WiFi and wired connections

This is a heads up - a big problem that is going to affect a huge number of WiFi networks.


Windows 11 22H2 enables credential guard by default - which disables MSCHAPv2 by default for single sign-on.  Many companies use MSCHAPv2 for authenticating to WiFi and wired connections (because it was the default setting in Windows 10 and 11 till now).


If you use this configuration, as users upgrade to Windows 11 22H2 they will no longer be able to authenticate to the network "at login" (as in automatically - single sign-on).  If enabled, users will still have the ability to click on the connection concerned and manually re-authenticate - but this breaks the whole user experience of seamless connectivity.


Microsoft recommends migrating to certificate-based authentication. 



This is going to be a lot of work ...

10 Replies 10
Kind of a big deal
Kind of a big deal

Ah great. Thanks for sharing I am sure a lot of people are going to be scratching their heads soon. 

Kind of a big deal
Kind of a big deal

Thanks for the info. Just not sure why MS does this also when MSCHAPv2 is done through a TLS tunnel ...

Kind of a big deal
Kind of a big deal

Holy crap... this is going to be a tough one.

I always enjoy a company just pushing changes through an update without actually announcing this a year before so administrators get time to implement.

Here to help

Thank you, PhilipDAth!!  We just ran up against this problem on a new batch of Win11 22H2 laptops using their domain machine accounts for Windows NPS RADIUS authentication to wifi, so your post was a HUGE help in determining how to overcome the connectivity issue until we can fully implement certificate-based authentication.


We were able to get the new 22H2 laptops to automatically connect by first disabling Windows Defender Credential Guard using the registry key method found in this MS doc, and then manually enabling NTLMv2 authentication by adding the registry key found in this MS doc.  Hope this helps somebody else like me who hasn't fully implemented certificate-based authentication and was caught off guard by this change.



This caught us out too, but our IT Security team (rightly) felt that disabling key security functionality in Windows 11 wasn't an appropriate long term solution, a short term workaround for key individuals at most.


We now have certificate based authentication in place for Windows 11 users.  This is a bit of a pain as devices have to register with the certificate server and have a cert issued to them before they can connect to wireless. This means that new devices (and devices just upgraded to Windows 11) have to connect to a cabled connection first, but it's what we've got to work with.


We are rolling out Windows 11 Enterprise and are having the same issue, its not an issue with Win 11 Pro.The article below explains how to configure EAP in NPS, you can use your existing SSID when you go live.I would recommend testing beforehand. We stood up a new test SSID and used a new Radius server prior to importing the config onto our production NPS servers. Import/export will save some time when testing and rolling to production. Make sure you move the EAP policy above the CHAP policy in order of precedence, we plan to leave the older policy in place, some Windows 10 machines were having issues with EAP.  

Creating a Policy in NPS to support EAP-TLS authentication - Cisco Meraki Documentation

Credential guard is only enabled by default from W11 Education and Enterprise 22H2 (for now), YMMV getting Security teams to approve disabling CG on managed devices, even if only temporarily.

If the end user devices in your environment are fully managed by policy then it's not so bad, much more of a PITA where you don't control those endpoints and they have to go through some form of onboarding!

Comes here often

Hey @OCTOMG, quick question on the above workaround. Can CG be re-enabled once you manually enable NTLMv2? Or did you guys just keep CG off until you get EAP-TLS going? 

Keep CG off until you get EAP-TLS going using a root CA and the server certificate on the NPS server. If PKI is not setup, you will have to ensure its functioning first issuing both client and server certs. We ended up spinning up a new hidden SSID and a new NPS server for the EAP-TLS configuration. SSID is being pushed via GPO too all Win 11 workstations via WMI filter. Works well after re-enabling credential guard.

My statement earlier about running both policies on the same server was not accurate. Order of precedence with EAP 1st was not working correctly for us with NTLM on the same NPS server, we had to roll back a day after testing in production. Mixed results with Win10 workstations using the cert, some were trying to use NTLM and not connecting successfully. Both Win10 test machines connected when testing prior to rolling to production from different remote sites over S2S tunnel.

Kind of a big deal

Thanks for bringing this issue to our attention.

Nolan Herring |
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.