『企業無線LANでパスワード認証（EAP-PEAP）が使えなくなる』と噂される背景を解説

はじめに

最近、企業ネットワークを管理する方々から、次のようなご質問をいただくことが増えてきました。

• 「将来的にWindowsではEAP-PEAPがサポートされなくなるのでしょうか？」
• 「Windows 11にアップグレードすると、EAP-PEAPが使用できなくなるのですか？」

こうした質問の背景には、Windows 11のセキュリティ機能強化、とくにCredential Guardの既定有効化（要件を満たす端末で自動的に有効になるケース）と、それに伴うネットワーク認証の挙動変化が関係していることが多いと考えられます。

ただし、この話題は「EAP-PEAPが廃止される」「PEAPが使えなくなる」といった形で誤解されやすい点があるため、まずはMicrosoftが公開している一次情報に基づいて、何が制限され、何が推奨されているのかを整理します。

問題の概要

本件を正確に理解するうえで重要なのは、「EAP-PEAP」という言葉が一括りに扱われがちである一方、実際の影響範囲はPEAPの中で使う内部認証方式に強く依存する点です。

Microsoftの公式ドキュメントでは、Credential Guardを有効にした場合の既知の制約と、Wi-Fi／VPN接続に関する注意点が整理されています。ここで焦点になっているのは、MS-CHAPv2をベースにした接続（例：PEAP-MSCHAPv2、EAP-MSCHAPv2）です。

Credential Guard を使用するときの考慮事項と既知の問題 より（Microsoft Learn）
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/credential-guard/considerations-known-issues

Wi-fi and VPN considerations
Wi-FiおよびVPNに関する考慮事項

If you're using WiFi and VPN endpoints that are based on MS-CHAPv2, they're subject to similar attacks as for NTLMv1.
MS-CHAPv2をベースにしたWi-FiおよびVPNエンドポイントを使用している場合、それらはNTLMv1と同様の攻撃にさらされます。

For WiFi and VPN connections, it's recommended to move from MSCHAPv2-based connections (such as PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (such as PEAP-TLS or EAP-TLS).
Wi-FiおよびVPN接続については、MSCHAPv2ベースの接続（例：PEAP-MSCHAPv2、EAP-MSCHAPv2）から証明書ベースの認証（例：PEAP-TLS、EAP-TLS）への移行が推奨されます。

また同ページでは、MS-CHAP（MS-CHAPv2を含む系統）について「SSOのみがブロックされる」点にも注意が必要だと説明されています。つまり、環境によっては「まったく使えなくなる」のではなく、保存済み資格情報やシングルサインオンに依存する形の接続が成立しなくなり、都度入力が必要になるなど、挙動変化として現れる場合があります。

Credential Guard

Credential Guardは、Windowsにおける資格情報（認証に関わる秘密情報）を保護するためのセキュリティ機能です。仮想化ベースのセキュリティ（VBS）を用いて資格情報を分離し、攻撃者がOS上で不正に情報を取得することを難しくします。Windows 11 22H2以降では、端末が要件を満たす場合に既定で有効化されることがあるため、ネットワーク認証の設計・運用では前提条件として扱う必要があります。

EAP-PEAP

EAP-PEAP（Protected EAP）は、EAP（Extensible Authentication Protocol）の方式の一つで、TLSトンネルを確立したうえで、その内側でさらに内部認証（inner method）を実行します。企業の無線LAN（WPA2-Enterprise／WPA3-Enterpriseなど）やVPNの認証で使われることがあり、内部認証としてMSCHAPv2（例：PEAP-MSCHAPv2）を選ぶ構成が広く普及してきました。

本件で問題になっているのは「PEAPそのもの」ではなく、MSCHAPv2ベースの内部認証を用いる構成が、Credential Guardの設計思想（資格情報保護）と整合しづらい点です。したがって、「EAP-PEAPが廃止される」と短絡せず、どの内部認証方式を使っているかを切り分けて判断する必要があります。

問題への対応

Microsoftは、Credential Guard環境におけるWi-Fi／VPN認証について、MSCHAPv2ベースの接続（PEAP-MSCHAPv2、EAP-MSCHAPv2など）から、証明書ベース認証（PEAP-TLS、EAP-TLSなど）へ移行することを推奨しています。

これは「一時的な不具合対応」というより、MSCHAPv2ベース方式が構造的に抱えるリスク（NTLMv1と同様の攻撃にさらされる、など）を踏まえた設計上の推奨です。結果として、Windows側の防御（Credential Guard）と認証方式の整合が取りやすくなります。

Credential Guard を使用するときの考慮事項と既知の問題 より（Microsoft Learn）
https://learn.microsoft.com/ja-jp/windows/security/identity-protection/credential-guard/considerations-known-issues

We recommend moving away from MSCHAPv2-based connections, such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication, like PEAP-TLS or EAP-TLS. Credential Guard doesn't block certificate-based authentication.
PEAP-MSCHAPv2やEAP-MSCHAPv2などのMSCHAPv2ベースの接続から、PEAP-TLSやEAP-TLSのような証明書ベースの認証に移行することをお勧めします。Credential Guardは証明書ベースの認証をブロックしません。

For a more immediate, but less secure fix, disable Credential Guard... If you disable Credential Guard, you leave stored domain credentials vulnerable to theft.
より迅速だが安全性の低い修正として、Credential Guardを無効にすることもできます。…Credential Guardを無効にすると、保存されたドメイン資格情報は盗難に対して脆弱になります。

このため、結論としては、運用都合で一時回避が必要な場合を除き、電子証明書による認証（EAP-TLS、またはPEAP-TLS）への移行を前提に設計を見直すことが推奨されます。

証明書ベースの認証について

EAP-PEAP（とくにPEAP-MSCHAPv2）から、電子証明書を用いるEAP-TLS（またはPEAP-TLS）へ移行することは、無線LAN環境のセキュリティと運用に、実務上の影響を与えます。ここでは、メリット・デメリットを整理します。

メリット

電子証明書による認証（EAP-TLS）は、パスワードベースの認証と比較して、資格情報の窃取・再利用に起因するリスクを下げやすい方式です。パスワード入力を前提にしないため、パスワード漏えいや使い回しに依存した攻撃シナリオから距離を取れます。

また、EAP-TLSは証明書を用いて認証するため、端末やユーザーの識別を設計しやすく、無線LAN（WPA2-Enterprise／WPA3-Enterprise）の認証方式としても広く採用されています。Microsoftも、Credential Guard環境ではMSCHAPv2ベースから証明書ベースへの移行を推奨しています。

デメリット

一方で、電子証明書を用いる方式では、証明書の発行・配布・更新・失効といったライフサイクル管理が必要になります。認証局（CA）の設計や、端末台数・更新頻度に応じた運用手順を整備しないと、更新漏れや失効漏れが業務影響に直結する可能性があります。

このため、移行の成否は暗号技術そのものよりも、証明書運用を含めた設計と管理体制に依存します。

デメリットの軽減

証明書ベース認証のデメリットは、突き詰めると「証明書運用の手間が増える」ことに集約されます。したがって、軽減の方向性は、証明書のライフサイクル（発行・配布・更新・失効）の管理を、運用設計として成立させることです。

たとえば、端末配布や入退社に合わせて証明書を確実に配布・失効できる仕組み、期限切れ前に更新できる手順、例外（更新不能端末、交換端末など）をどう扱うか、といった運用要件を最初に定義しておく必要があります。

EAP-TLSへの移行は初期の計画と投資が必要ですが、Credential Guardを前提としたWindows環境での整合性を取りやすく、長期的にはパスワード依存を減らす方向の設計としても合理的です。結論として、現実的な落としどころは、電子証明書による認証（EAP-TLS）を前提に、証明書運用を回る形で設計し直すことになります。

 既存システムの機器について

EAP-PEAP（PEAP-MSCHAPv2）からEAP-TLS（またはPEAP-TLS）に変更する場合、必ずしもネットワーク機器や認証サーバーを買い替える必要はありません。重要なのは、現在の構成が「証明書ベース認証（TLS）を扱える前提」になっているかを確認し、必要な設定・運用を追加することです。

クライアントPC

クライアントデバイス（PCなど）側では、EAP-TLSを使うために、各端末へ電子証明書（および秘密鍵）を配布し、無線LANプロファイルをEAP-TLS（またはPEAP-TLS）で利用する設定に更新します。通常は、端末のハードウェア交換ではなく、証明書配布と設定更新が中心作業になります。

ネットワーク機器

無線アクセスポイントやスイッチなどのネットワーク機器は、802.1X（RADIUS）連携を前提とした設計であれば、EAP方式の変更は「RADIUS側の設定と連携」の範囲で完結することがあります。まずは、対象機器がEAP-TLS（またはPEAP-TLS）を扱う構成になっているか、ベンダーの仕様と設定項目を確認します。

認証サーバー

認証サーバー（RADIUSサーバー）がEAP-TLS（またはPEAP-TLS）に対応しているかを確認します。対応している場合、サーバー証明書の準備、クライアント証明書の検証方法（失効確認、信頼するCAなど）の設定が必要になりますが、ハードウェア交換は必須ではありません。

もしネットワーク機器や認証サーバーが証明書ベース認証に対応していない場合に限り、アップグレードや更改が検討対象になります。いずれにしても、最初のステップは「現状の機器・サーバーがEAP-TLS運用に必要な要件を満たすか」を棚卸しすることです。

証明書の運用に強みをもつ認証ソリューションのご紹介

Soliton OneGate

Soliton OneGate（ソリトン ワンゲート）は、クラウド／オンプレミスを含む業務システムの認証基盤を統合管理するためのIDaaSです。Wi-FiやVPN認証において電子証明書を用いる構成を取り、シングルサインオン（SSO）や多要素認証（MFA）、SAML連携などの機能を提供します。証明書運用を含めた設計・管理の考え方は、採用する構成・プランによって異なるため、要件に合わせて確認します。

NetAttest EPS

NetAttest EPS（ネットアテスト イーピーエス）は、企業の無線LANやVPNへの接続時にRADIUS認証を行うためのサーバー製品です。認証（RADIUS）に加え、構成により認証局（CA）機能やDHCPサービスなどを組み合わせて利用でき、無線LAN認証の運用を支える基盤として構成されます。EAP-TLSへの移行時は、サーバー証明書／クライアント証明書の取り扱い、失効確認、信頼するCAの設計など、証明書運用を含めた要件整理がポイントになります。

まとめ

「Windows 11でEAP-PEAPが使えなくなる」と言われる背景には、Credential Guardの有効化によって、MSCHAPv2ベースの接続（PEAP-MSCHAPv2、EAP-MSCHAPv2など）が非推奨・制限の対象として扱われやすくなる点があります。一方で、一次情報の範囲では「EAP-PEAPそのものが廃止される」とは示されておらず、影響の中心はPEAPの内側で用いる内部認証方式にあります。

実務的には、まず自社の無線LAN／VPNがPEAP-MSCHAPv2を前提にしているかを棚卸しし、該当する場合は、Microsoftが推奨する通り電子証明書による認証（EAP-TLS、またはPEAP-TLS）への移行を前提に設計と運用を見直すのが現実的です。Credential Guardを無効化する回避策は取り得ますが、セキュリティを下げる選択になるため、恒久対策としては位置づけないほうが安全でしょう。