Why PEAP-MSCHAPv2 fails on Windows 11 and how to fix it

10月中旬のパッチ適用後に Windows 11 コンピュータが社内Wi-Fiに接続できなくなったり、これまで表示されたことのない資格情報の入力を求めるプロンプトが突然ユーザーに表示されるようになったりしても、それはあなただけではありません。2026年10月13日の Windows セキュリティ更新プログラム以降、Windows へのログオンに PEAP-MSCHAPv2 を使用している多くのドメイン参加済みデバイスで、Wi-Fi、有線 802.1X、または VPN に自動的にサインインできなくなっています。

これはMicrosoftによる計画的なセキュリティ強化です。Microsoftは2025年8月、NTLMを廃止する取り組みの一環としてこの変更を発表し、10月の更新では、どちらの設定も行われていなかったデバイスでこれがデフォルトで有効になりました。

このガイドでは、何が変更されたのか、どのデバイスが影響を受けるのか、更新が原因であることを確認する方法、そしてユーザーを今日中に再接続する方法について説明します。また、長期的に有効な対策である、EAP-TLS を使用してネットワーク認証をパスワードから証明書に移行する方法についても説明します。

2026年10月のWindowsアップデートで何が変わったのか

Microsoft は、Windows 11 バージョン 24H2 および Windows Server 2025 から NTLMv1 プロトコルを削除しました。一部のシナリオでは NTLMv1 の暗号化が依然として残っており、特に顕著なのは、ドメイン参加済み環境で実行される場合の、PEAP-MSCHAPv2 および EAP-MSCHAPv2 の背後にある内部方式である MS-CHAPv2 です。

BlockNtlmv1SSO というレジストリ値は、Windows がそれらの NTLMv1 由来の資格情報をシングルサインオンに使用できるようにするかどうかを制御します。値が 0（監査モード）の場合、リクエストは許可され、警告がログに記録されます。値が 1（強制モード）の場合、それはブロックされ、エラーがログに記録されます。

2026年10月13日のセキュリティ更新プログラム以降、Windows は BlockNtlmv1SSO の値が存在しない場合、それを Enforce モードとして扱います。この更新プログラムでは、レジストリ値の作成や変更は行われません。変更されるのは、その値が存在しない場合の Windows の動作です。そのため、Group Policy や Intune に何の変更もなかったにもかかわらず、非常に多くの環境で不意を突かれることになりました。

ブロックされているのはシングルサインオンの経路のみです。プロンプトでユーザー名とパスワードを入力するユーザーは、引き続き接続できます。

展開は段階的に行われました。監査イベントは2025年8月下旬にWindows 11 24H2以降で表示され始め、展開は2025年11月にWindows Server 2025に到達し、Enforceは2026年10月に既定になりました。Microsoftは、更新プログラムのリリースから2日後の10月15日にKB5127648のリリースノートへこの変更に関する注記を追加したため、リリース当日にノートを確認した管理者はそこでは見つけられませんでした。

Windows Server 2025 でも同じ変更が、同日にリリースされた KB5126646 で導入されました。

影響を受ける人（受けない人）

次の4つの条件がすべて当てはまる場合、そのデバイスは影響を受けます。

• October 2026 update がインストールされた Windows 11 version 24H2 以降、または Windows Server 2025 で実行されていること。

• Credential Guard は実行されていません。

• レジストリ値 BlockNtlmv1SSO が設定されていません。

• 通常、PEAP-MSCHAPv2 や EAP-MSCHAPv2 のプロファイルと同様に、その Wi-Fi、有線、または VPN プロファイルでは、Windows ログオンのシングルサインオンで MS-CHAPv2 が使用されます。

Credential Guard が実行されているデバイスは、October より前からすでにこの状態でした。Credential Guard はそれ自体で MS-CHAPv2 のシングルサインオンをブロックし、Enterprise および Education ライセンスの対象デバイスと一部の Pro ライセンスでは、Windows 11 version 22H2 以降、既定で有効になっています。そのレジストリ値は、それらのデバイスには何の効果もありません。いずれにしても、管理対象の Windows デバイスにおける PEAP シングルサインオンは終了に向かっています。

ブロックは認証応答が RADIUS サーバーに届く前に、Windows デバイス上で発生します。そのため、こうした障害が発生している間は RADIUS のログに有用な情報がまったく表示されないことが多く、サーバー側の設定ではシングルサインオンを復旧できません。

更新が原因であることを確認する方法

設定を変更する前に、接続を妨げているのが10月の更新であることを確認してください。影響を受けているデバイスでは、これらの確認に数分かかります。

1. 更新がインストールされているかどうかを確認してください。設定 > Windows Update > 更新履歴 に移動して KB5127648 を探すか、winver を実行してビルド番号を上の表と比較してください。

2. Event Viewer を開き、Applications and Services Logs > Microsoft > Windows > NTLM > Operational に移動します。

3. 接続に失敗した時刻の event ID 4025（エラー）を探してください。そのテキストには次のように記載されています："シングルサインオンにNTLMv1由来の資格情報を使用しようとする試みは、ポリシーによりブロックされました。"

4. ネットワークプロファイルを確認してください。PEAP-MSCHAPv2 を使用し、"Automatically use my Windows logon name and password" が選択されている場合は、原因が見つかりました。

イベント ID 4024 も確認する価値があります。これは同じログ内の監査モード警告であり、まだ10月のアップデートをインストールしていないデバイスでは、適用時に問題が発生するマシンを示します。環境全体で4024および4025イベントを収集すると、引き続きPEAPシングルサインオンに依存しているすべてのデバイスとプロファイルのインベントリを取得できます。これは、このガイドの後半で行う移行に必要になります。

短期的な回避策と、それが一時的なものにすぎない理由

恒久的な修正を計画している間に、ユーザーを再接続する方法はいくつかあります。どの方法も時間を稼ぐだけで、根本的な依存関係は残ったままです。

BlockNtlmv1SSO を 0 に設定する

BlockNtlmv1SSO を 0 に設定すると、デバイスは明示的に Audit mode に戻り、10 月のセキュリティ更新プログラムをインストールしたまま、PEAP-MSCHAPv2 のシングルサインオンが復元されます。再起動は不要です。

大規模な環境では、Group Policy Preferences のレジストリアイテムまたは Intune の修復スクリプトを使って、この値を設定します。すでにネットワークから切断されているデバイスは再接続するまでポリシーを受信できないため、有線ポート、ゲストネットワーク、または資格情報を手入力するサインインなど、それらのデバイスに到達する方法を計画しておきましょう。この設定は、Credential Guard が実行されているデバイスでは効果がありません。

Microsoft は、監査モードについて、Enforce モードが提供する保護を弱めるため、「限定的かつ一時的なセキュリティ例外としてのみ検討すべき」と説明しています。必要なデバイスに対象を絞り、終了日を設定し、他の未解決リスクと同様に追跡してください。

ユーザーに資格情報を入力してもらいます

ユーザーは保存されたネットワークを削除し、表示されるプロンプトでユーザー名とパスワードを入力して再接続できます。構成を変更しなくても機能しますが、すべてのユーザーにひと手間増え、ログイン画面でネットワークアクセスを必要とするデバイスには役立たず、さらにパスワードがネットワークのサインイン経路に残ることになります。

更新プログラムのアンインストールが望ましくない選択肢である理由

KB5127648 をアンインストールすると古い既定の設定に戻りますが、その月のセキュリティ修正も削除されます。後の累積更新プログラムにも同じ変更が含まれているため、デバイスが次回更新されると問題は再発します。Microsoft では、このレジストリ値をサポートされている例外パスとして文書化しています。

Windows をはじめとする環境で MS-CHAPv2 が廃止される理由

このレジストリの回避策により PEAP-MSCHAPv2 は動作し続けますが、維持されるそのプロトコルには広く知られた弱点があり、廃止を求める圧力は複数の方面から高まっています。

変更の背景にある弱点

Microsoft 自身のガイダンスでも、MS-CHAPv2 ベースの Wi-Fi と VPN のエンドポイントは、NTLMv1 に対する攻撃と同様の攻撃を受けやすいとされています。主な問題点は、すでに明確になっています。

• これはレガシーなパスワードハッシュ化に依存しています。MS-CHAPv2 の応答は、ユーザーのパスワードの MD4 ハッシュから構築され、NTLMv1 と同じ DES ベースのチャレンジレスポンス設計を使用しているため、Windows では NTLMv1 由来の資格情報として扱われます。

• これは 2012 年に公に破られました。DEF CON 20 で、研究者の Moxie Marlinspike 氏と David Hulton 氏は、取得された MS-CHAPv2 のやり取りが、パスワード強度に関係なく成功率 100% で単一の 56 ビット DES キーの解読に帰着できることを示しました。

• その保護は、すべてのクライアントが正しく設定されていることに依存します。PEAP は MS-CHAPv2 を TLS トンネルで包みますが、その保護を受けられるのは、RADIUS サーバー証明書を検証するクライアントだけです。検証を省略するクライアントは、やり取りを盗み取るなりすましアクセスポイントへの認証にだまされる可能性があります。

• それでもパスワードです。パスワードはフィッシングされることも、共有されることも、使い回されることもあり、リセットや有効期限切れが発生するたびに、ユーザーが再度サインインするまでデバイスがネットワークから切断される可能性があります。

次はプロトコル自体です

Microsoft はクライアント側で MS-CHAPv2 を制限しています。RADIUS を管理している標準化団体は、プロトコル側で対応を進めています。

IETF RADEXTワーキンググループの現在のドラフト「"Deprecating Insecure Practices in RADIUS,"」には、MS-CHAPを正式に非推奨とするセクションが含まれています。同じドラフトでは、セキュアでないネットワークにおけるUDPおよびTCP上のRADIUSも非推奨とされており、RadSec（TLS上のRADIUS）のようなセキュアなトランスポートの使用が求められています。まだ策定途中ではあるものの、RADIUSのセキュリティ標準が今後どこに向かっているかを示しています。トランスポート面の背景については、RADIUSとRadSecの比較をご覧ください。

BlockNtlmv1SSO を 0 に設定しても、どちらの傾向にも対処できません。MS-CHAPv2 から移行することで、その両方に対処できます。

恒久的な対策: Windows デバイスを EAP-TLS に移行する

Microsoft は、Wi-Fi と VPN の接続を MS-CHAPv2 から、EAP-TLS や PEAP-TLS などの証明書ベースの認証へ移行することを推奨しています。ほとんどの組織にとって、EAP-TLS が最も直接的な移行手段です。

EAP-TLS が影響を受けない理由

EAP-TLS は、証明書と秘密鍵を使用してデバイスまたはユーザーを認証します。パスワードは使用されず、Windows でも保存されたログオン資格情報は不要なため、BlockNtlmv1SSO の変更は一切適用されません。Credential Guard も証明書ベースの認証をブロックしません。

この移行により、PEAP-MSCHAPv2が以前から抱えていた問題も解決されます。

• フィッシングされたり、オフラインで解析されたり、不正なアクセスポイントで盗まれたりするパスワード自体がありません。

• デバイス証明書を使用すると、ノートPCは誰かがサインインする前のログイン画面で接続できます。

• パスワードのリセットや有効期限切れによって、デバイスが Wi‑Fi から切断されることはなくなります。

• 同じ証明書ベースのアプローチは、Wi-Fi、有線 802.1X、および VPN でも機能します。

ダウンタイムなしで移行する方法

移行期間中は PEAP と EAP-TLS を並行して実行できるため、デバイスを一斉ではなくグループごとに移行できます。以下の手順は、あらゆる ID プロバイダーとあらゆる MDM プラットフォームで使用できます。

1. インベントリを作成します。4024 と 4025 のイベントを使用して、影響を受けるデバイスとそれらが使用するネットワークプロファイルを一覧化します。会社管理デバイスは証明書の受け取り方が異なるため、個人所有や未管理のデバイスと分けてください。

2. 証明書の発行方法を決めます。Active Directory Certificate Services などのオンプレミスの認証局も選択肢の1つです。クラウドでホストされる認証局なら、そのインフラを自社で運用する必要がありません。

3. 管理対象デバイスに証明書を配布します。Microsoft Intune、Jamf、Workspace ONE、Kandji、Google Admin for Chromebooks など、使用しているMDMのSCEP証明書プロファイルを使用します。

4. 未管理デバイスやBYODデバイスに、セルフサービスで利用開始できる手段を提供します。証明書とネットワークプロファイルをインストールする登録フローにより、ユーザーはITチケットを作成せずに自分のデバイスを登録できます。

5. 移行期間中は、RADIUS サーバーが PEAP と併せて EAP-TLS を受け入れるよう設定します。

6. EAP-TLS ネットワークプロファイルをプッシュします。信頼されたルート証明書とサーバー名によって RADIUS サーバー証明書を検証するように設定します。

7. 1 つのチームまたは拠点で試験導入します。デバイスがログイン画面で接続でき、パスワード変更後も接続を維持できることを確認します。

8. 部門、拠点、またはデバイスグループごとに段階的に展開できます。

9. PEAP を廃止する。デバイスから古いプロファイルを削除し、BlockNtlmv1SSO の例外をすべて削除して、RADIUS サーバーで MS-CHAPv2 を無効にします。

10月のアップデートの影響を受けるのは Mac でもスマートフォンでも Chromebooks でもありませんが、ネットワーク上で PEAP を完全に廃止することが目的であれば、これらにも証明書が必要になります。管理対象 Chromebooks 向けの証明書ベース Wi-Fiに関するガイドでは、ChromeOS 側について説明しています。

Foxpass が PEAP-MSCHAPv2 からの移行にどう役立つか

SplashtopのFoxpassは、Wi-Fi、VPN、有線ネットワーク向けのクラウドホスト型RADIUS認証に加え、デバイス証明書とユーザー証明書を発行するためのクラウドPKIを提供します。Foxpass Cloud RADIUSとFoxpass Cloud PKIを組み合わせることで、オンプレミスサーバーを構築・保守することなく、上記の移行の各段階をカバーできます。

• オンプレミスのインフラなしで証明書を発行: Foxpass Cloud PKI が認証局として機能し、Foxpass Cloud RADIUS が接続試行のたびに証明書を検証します。

• すでに利用している MDM による証明書配布: 管理対象デバイスは、Microsoft Intune、Jamf、Kandji、Addigy、Workspace ONE、Mosyle、NinjaOne、Google Admin for Chromebooks から、Foxpass SCEP endpoint を通じて証明書を受け取ります。Splashtop AEM で Windows エンドポイントを管理しているチームは、Splashtop AEM 経由でも証明書を配布できます。

• すでに利用しているIDプロバイダーにひも付いたアクセス: FoxpassはMicrosoft Entra ID、Google Workspace、Okta、OneLoginからユーザーとグループを同期するため、ネットワークアクセスは他のすべてと同じディレクトリに従います。OktaとGoogle Workspaceについては、OktaとGoogle Workspace向けの証明書ベース認証でさらに詳しく紹介しています。

• BYODと未管理デバイス向けのセルフサービス手段：Foxpass BYOD Certificate Installerを使うと、ユーザー自身でMac、Windows、iOS、Android、Chromebookデバイスを登録できます。

• 誰かが離れると終了するアクセス: 証明書にはユーザーのメールアドレスまたはデバイス ID を含められるため、Foxpass は接続時に、そのユーザーまたはデバイスがディレクトリ内で引き続き有効かどうかを確認できます。

• 段階的な切り替え: Foxpass Cloud RADIUS は EAP-TLS と EAP-TTLS を並行してサポートしているため、デバイスを段階的に証明書ベースへ移行できます。

• 暗号化されたRADIUSトラフィック: FoxpassはRadSecをサポートしており、アクセスポイントとRADIUSサーバー間の認証トラフィックをTLSで保護します。

FoxpassでパスワードレスのWi-FiおよびVPNアクセスを実現する方法の詳細はこちら。

証明書ベースのWi-FiでPEAPを完全に廃止

BlockNtlmv1SSO 設定を使えば、Windows 11 ユーザーを今すぐ再びオンラインにできますが、ネットワークサインインは引き続き、Microsoft が移行を推奨しているプロトコルに依存したままになります。また、IETF もプロトコルレベルでこれを非推奨にしようとしています。証明書ベースの認証ならその依存関係をなくせるため、今後 Windows のセキュリティ強化が行われても、Wi-Fi チケットの再発にはつながりません。

Foxpass Cloud RADIUS と Foxpass Cloud PKI を使えば、すでに運用している ID プロバイダーや MDM をそのまま活用して、その移行を進められます。無料トライアルを始めるか、デモを予約して、Foxpass が自社環境にどう適合するかをご確認ください。