如果 Windows 11 電腦在 10 月中旬套用修補程式後無法再加入企業 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 加密技術，最明顯的是：MS-CHAPv2，也就是 PEAP-MSCHAPv2 和 EAP-MSCHAPv2 背後的內部方法，在網域加入的環境中執行時。
名為 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 於 10 月 15 日，也就是更新發布兩天後，才在 KB5127648 版本資訊中加入這項變更的說明，因此在發布當天查看版本資訊的管理員當時並未看到該內容。
Windows 版本 | 2026 年 10 月 13 日更新 | OS 組建版本 |
Windows 11，版本 26H2 | KB5127648 | 26300.9711 |
Windows 11，版本 25H2 | KB5127648 | 26200.9711 |
Windows 11，版本 24H2 | KB5127648 | 26100.9711 |
Windows 11，版本 26H1 | KB5127646 | 28000.3231 |
Windows Server 2025 在同一天發布的 KB5126646 中也收到了相同的變更。
哪些人會受影響（哪些人不會）
當以下四個條件全部符合時，裝置就會受到影響：
其執行的是 Windows 11 版本 24H2 或更新版本，或 Windows Server 2025，並已安裝 2026 年 10 月更新。
Credential Guard 未執行。
尚未設定 BlockNtlmv1SSO 登錄值。
其 Wi-Fi、有線或 VPN 設定檔會使用搭配 Windows 登入單一登入的 MS-CHAPv2，正如 PEAP-MSCHAPv2 和 EAP-MSCHAPv2 設定檔通常所做的一樣。
已執行 Credential Guard 的裝置在 10 月之前就已經處於這種狀態。Credential Guard 本身就會封鎖 MS-CHAPv2 單一登入，而且自 Windows 11 版本 22H2 起，對於符合資格且使用 Enterprise 與 Education 授權，以及部分 Pro 授權的裝置，這項功能已預設啟用。登錄值對那些裝置沒有任何作用。無論如何，受管理 Windows 裝置上的 PEAP 單一登入都將走向終止。
連接類型 | 受到 10 月更新影響嗎？ |
PEAP-MSCHAPv2 或 EAP-MSCHAPv2 搭配 Windows 登入單一登入 | 是，已封鎖 |
PEAP-MSCHAPv2 搭配在提示字元中輸入的認證資料 | 不，仍然會連接 |
EAP-TLS（憑證式） | 没有 |
WPA2-Personal 或 WPA3-Personal（共用密碼片語） | 没有 |
macOS、iOS、Android、Linux 和 ChromeOS 裝置 | 不，這項變更僅在 Windows 中進行 |
封鎖會發生在 Windows 裝置端，而且是在驗證回應抵達 RADIUS 伺服器之前。這就是為什麼 RADIUS 記錄在這類失敗情況下通常顯示不出任何有用資訊，也說明了為什麼任何伺服器端設定都無法讓單一登入恢復。
如何確認更新是原因
變更任何設定之前，請先確認是否為 10 月更新阻止了連接。在受影響的裝置上完成這些檢查需要幾分鐘：
檢查更新是否已安裝。前往 Settings > Windows Update > Update history，查看是否有 KB5127648，或執行 winver，並將組建編號與上表進行比較。
開啟 Event Viewer，然後前往 Applications and Services Logs > Microsoft > Windows > NTLM > Operational。
請在連接失敗時的時間點查找事件 ID 4025（錯誤）。其文字內容為："嘗試使用 NTLMv1 衍生的認證進行 Single Sign-On，但因原則而遭到封鎖。"
檢查網路設定檔。如果使用的是 PEAP-MSCHAPv2，且已選取 "Automatically use my Windows logon name and password"，那就找到原因了。
也值得檢查一下事件 ID 4024。這是同一份記錄中的 Audit mode 警告，而在尚未安裝 10 月更新的裝置上，它會標示出那些一旦安裝更新就會發生故障的機器。在整個裝置群中收集 4024 和 4025 事件，可盤點出所有仍依賴 PEAP 單一登入的裝置與設定檔，這些資訊將是本指南稍後進行移轉時所需要的。
短期因應方案，以及為什麼它只是暫時性的
在規劃長久解決方案的同時，有幾種方法可以讓使用者重新連接。每一種方式都能爭取一些時間，但底層相依性依然存在。
將 BlockNtlmv1SSO 設為 0
明確將 BlockNtlmv1SSO 設為 0，會讓裝置回到稽核模式，這會還原 PEAP-MSCHAPv2 單一登入，同時保留 10 月安全性更新。不需要重新啟動。
設定 | 值 |
登錄路徑 | HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 |
值名稱 | BlockNtlmv1SSO |
類型 | REG_DWORD |
資料 | 0 = 稽核（允許並記錄），1 = 強制執行（封鎖） |
如需大規模部署，可透過 Group Policy Preferences 登錄機碼項目或 Intune 修復指令碼來部署此值。請規劃可觸及已離開網路的裝置之方式，例如有線連接埠、訪客網路，或輸入認證的登入方式，因為這些裝置在重新連接之前無法接收原則。此設定對於正在執行 Credential Guard 的裝置沒有作用。
Microsoft 將稽核模式描述為「只應視為有限範圍、暫時性的安全性例外」，因為它會降低 Enforce mode 所提供的保護。請將其限定於需要的裝置、設定結束日期，並像追蹤任何其他未結風險一樣追蹤它。
讓使用者輸入其認證
使用者可以忘記已儲存的網路，並在提示時輸入使用者名稱和密碼重新連接。這種方式無須任何設定變更即可運作，但會增加每位使用者的操作阻力，無法協助需要在登入畫面取得網路存取的裝置，而且會讓密碼持續留在網路登入路徑中。
為什麼解除安裝更新不是理想的做法
解除安裝 KB5127648 可恢復舊的預設值，但也會移除當月的安全性修補。後續的累積更新也包含相同的變更，因此裝置下次更新時，這個問題還是會再次出現。Microsoft 將該登錄值記載為受支援的例外處理方式。
為什麼 MS-CHAPv2 正在被淘汰：從 Windows 到更廣泛的環境
這個登錄檔因應措施可讓 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 交換資料如何可被簡化為破解單一 56 位元 DES 金鑰，而且無論密碼強度如何，成功率皆為 100%。
其防護效果取決於每個用戶端都已正確設定。PEAP 會將 MS-CHAPv2 封裝在 TLS 通道中，但只有會驗證 RADIUS 伺服器憑證的用戶端才能獲得這層保護。略過驗證的用戶端可能會被誘騙，向會擷取該交換內容的惡意雙胞胎存取點進行驗證。
它仍然是密碼。密碼可能遭到網路釣魚、被分享及重複使用，而每次重設或到期，都可能讓裝置中斷網路連接，直到使用者再次登入。
接下來是通訊協定本身
Microsoft 正在用戶端限制 MS-CHAPv2。負責維護 RADIUS 的標準組織正著手處理協定層面的問題。
IETF RADEXT 工作小組目前的草案 "Deprecating Insecure Practices in RADIUS," 包含一個正式棄用 MS-CHAP 的章節。同一份草案也棄用了在安全網路之外透過 UDP 和 TCP 傳輸的 RADIUS，並呼籲採用安全傳輸方式，例如 RadSec（RADIUS over TLS）。這仍在制定中，但已顯示出 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 一直以來存在的問題：
沒有密碼可供網路釣魚竊取、離線破解，或透過惡意雙胞胎存取點擷取。
裝置憑證可讓筆記型電腦在登入畫面時、也就是任何人登入之前就先行連接。
密碼重設和到期不會再導致裝置與 Wi‑Fi 中斷連接。
相同的憑證式方法也適用於 Wi-Fi、有線 802.1X 和 VPN。
如何在不停機的情況下完成遷移
PEAP 和 EAP-TLS 可在移轉期間並行運作，因此裝置可以分批移轉，而不必一次全部進行。這些步驟適用於任何身分提供者和任何 MDM 平台：
建立詳細目錄。使用 4024 和 4025 事件，列出受影響的裝置及其使用的網路設定檔。將公司管理的裝置與個人裝置及未受管理的裝置分開，因為它們接收憑證的方式會不同。
決定憑證的簽發方式。內部部署的憑證授權單位（例如 Active Directory Certificate Services）是一種選項。雲端託管的憑證授權單位可免除自行執行該基礎架構的需求。
將憑證傳送到受管理的裝置。使用 MDM 的 SCEP 憑證設定檔，無論是 Microsoft Intune、Jamf、Workspace ONE、Kandji，還是適用於 Chromebooks 的 Google Admin。
為未受管理與 BYOD 裝置提供自助服務途徑。可安裝憑證和網路設定檔的註冊流程，讓使用者無需提交 IT 服務單，即可讓自己的裝置完成上線。
在轉換期間，將 RADIUS 伺服器設定為接受 EAP-TLS，並同時支援 PEAP。
推送 EAP-TLS 網路設定檔。將其設定為依據受信任的根憑證和伺服器名稱來驗證 RADIUS 伺服器憑證。
先以一個團隊或據點試行。確認裝置可在登入畫面連接，並且在變更密碼後仍維持連接。
依部門、地點或裝置群組分階段部署。
淘汰 PEAP。從裝置中移除舊設定檔、刪除任何 BlockNtlmv1SSO 例外，並在 RADIUS 伺服器上停用 MS-CHAPv2。
Mac、手機和 Chromebook 不受 10 月更新影響，但如果目標是讓網路全面汰除 PEAP，它們也需要憑證。我們的受管理 Chromebook 憑證式 Wi-Fi 指南涵蓋了 ChromeOS 端的設定。
Foxpass 如何協助停用 PEAP-MSCHAPv2
Foxpass 來自 Splashtop，提供雲端託管的 RADIUS 驗證，適用於 Wi-Fi、VPN 和有線網路，並提供雲端 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 端點接收憑證。使用 Splashtop AEM 管理 Windows 端點的團隊，也可以透過 Splashtop AEM 傳送憑證。
存取權限與您現有的身分識別提供者綁定：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，可透過 TLS 保護存取點與 RADIUS 伺服器之間的驗證流量。
深入了解使用 Foxpass 的無密碼 Wi-Fi 與 VPN 存取。
以憑證式 Wi‑Fi 徹底淘汰 PEAP
BlockNtlmv1SSO 設定今天可以讓 Windows 11 使用者重新上線，但它也會讓網路登入繼續綁定在 Microsoft 建議逐步淘汰的協定上，而 IETF 也正推動在協定層級將其棄用。憑證式驗證可移除這項相依性，讓未來 Windows 的安全強化不會再演變成另一波 Wi-Fi 支援工單。
Foxpass Cloud RADIUS 和 Foxpass Cloud PKI 可讓您搭配現有的 identity provider 和 MDM 完成這項轉移。立即開始免費試用或預約產品示範，看看 Foxpass 如何融入您的環境。
