Dzięki aktualizacjom zabezpieczeń z października 2026 r. Microsoft wprowadził zmianę w uwierzytelnianiu Windows, która może powodować problemy z połączeniami Wi-Fi, Ethernet i VPN w niektórych środowiskach korporacyjnych. Od tego czasu system Windows domyślnie blokuje określone dane uwierzytelniające pochodne NTLMv1, używane do automatycznego logowania przez Single Sign-On (SSO).
Nie oznacza to jednak, że po październikowej aktualizacji nagle u wszystkich użytkowników systemu Windows 11 – Microsoft Windows Windows 11przestanie działać Wi-Fi. Dotyczy to tylko określonych konfiguracji uwierzytelniania, zwłaszcza tych, które używają MS-CHAPv2 w połączeniu z danymi uwierzytelniającymi pochodnymi NTLMv1.
Dlatego dla użytkowników domowych ze zwykłym domowym Wi-Fi zazwyczaj nie ma potrzeby podejmowania działań. Firmy i administratorzy IT powinni natomiast sprawdzić, czy ich dostęp do sieci nadal opiera się na dotkniętych procedurach. Microsoft udostępnia w tym celu możliwości monitorowania i tymczasową opcję zgodności.
Co zmienił Microsoft w październikowej aktualizacji 2026?
Dzięki aktualizacjom zabezpieczeń z 13 października 2026 r. Microsoft zmienił domyślne zachowanie ustawienia systemu Windows BlockNtlmv1SSO . Ustawienie to kontroluje, czy system Windows jedynie monitoruje, czy blokuje użycie określonych danych uwierzytelniających pochodnych NTLMv1 do Single Sign-On.
Przed zmianą system Windows domyślnie znajdował się w trybie monitorowania. Próby użycia odpowiednich danych uwierzytelniających były rejestrowane, ale mogły zakończyć się sukcesem. Po zainstalowaniu październikowej aktualizacji zabezpieczeń system Windows domyślnie przechodzi w tryb egzekwowania, chyba że odpowiednia wartość rejestru została wyraźnie skonfigurowana.
W trybie egzekwowania system Windows blokuje generowanie odpowiednich danych uwierzytelniających do Single Sign-On. Może to wpłynąć na określone połączenia Wi-Fi, Ethernet i VPN, jeśli używają one uwierzytelniania opartego na MS-CHAPv2.
Zmiana obowiązuje jednak tylko pod dwoma warunkami:
- Credential Guard jest wyłączony na urządzeniu.
- Wartość rejestru
BlockNtlmv1SSOnie została wyraźnie ustawiona.
Jeśli wartość została już skonfigurowana przed aktualizacją, to ustawienie pozostaje wiążące. Aktualizacja nie tworzy ani nie zmienia automatycznie wartości rejestru. Zmienia jedynie wewnętrzne domyślne zachowanie, jeśli wartość nie istnieje.
Dla Windows 11 – Microsoft Windows Windows 11 zmiana jest częścią aktualizacji zabezpieczeń KB5127648. Dotyczy wersji 24H2, 25H2 i 26H2. Dla systemu Windows Server 2025 odpowiednia aktualizacja to KB5126646. Szczegółowy opis techniczny i opcje konfiguracji Microsoft dokumentuje w KB5066470.
Czym jest NTLM i NTLMv1?
NTLM oznacza NT LAN Manager i odnosi się do starszej rodziny metod uwierzytelniania ze środowiska Windows. Jest używany do uwierzytelniania użytkowników w sieciowych usługach i innych systemach. W nowoczesnych sieciach Windows często stosuje się Kerberos. Jednak NTLM jest nadal używany w określonych sytuacjach ze względów kompatybilności wstecznej.
W ramach rodziny NTLM istnieją różne wersje. NTLMv1 jest starszym wariantem i jest uważany za niebezpieczny ze względu na swoje słabości kryptograficzne. NTLMv2 to rozwinięta wersja z ulepszonymi mechanizmami bezpieczeństwa. Dlatego obu metod nie należy traktować równorzędnie.
Microsoft usunął właściwy protokół NTLMv1 z Windows 11, wersja 24H2 i Windows Server 2025. Nie oznacza to jednak, że wszystkie metody NTLM zostały jednocześnie wyłączone. Nie oznacza to również, że wszystkie procesy uwierzytelniania ze starszymi komponentami kryptograficznymi automatycznie zniknęły.
Właśnie tutaj pojawia się obecna zmiana: Microsoft chce nie tylko zapobiec użyciu właściwego protokołu NTLMv1, ale także zablokować określone dane uwierzytelniające pochodne NTLMv1, które mogą być nadal używane w innych metodach uwierzytelniania.
Które wersje Windows są objęte zmianami?
Microsoft stopniowo wprowadzał monitorowanie i egzekwowanie danych uwierzytelniających pochodnych NTLMv1. Funkcja techniczna została początkowo udostępniona wraz z aktualizacjami od sierpnia 2025 r. W październiku 2026 r. Microsoft zmienił domyślne zachowanie w przeznaczonych do tego wersjach Windows.
| System operacyjny | Klasyfikacja |
|---|---|
| Windows 11 24H2 | Funkcja monitorowania od 2025 r. Domyślne zachowanie zostało zmienione na wymuszanie wraz z aktualizacją zabezpieczeń KB5127648 z października 2026 r. |
| Windows 11 25H2 | Zmiana domyślnego zachowania jest częścią KB5127648 z października 2026 r. |
| Windows 11 26H2 | Zmiana domyślnego zachowania jest częścią KB5127648 z października 2026 r. |
| Windows 11 26H1 | W KB5066470 wymieniono jako obsługiwana wersja. KB5127648 nie jest jednak odpowiednią aktualizacją dla tej wersji. Konkretne przypisanie aktualizacji należy sprawdzić oddzielnie na podstawie dokumentacji poszczególnych aktualizacji. |
| Serwer Windows 2025 | Monitorowanie zostało wprowadzone już w 2025 r. Zmienione domyślne zachowanie jest częścią aktualizacji zabezpieczeń KB5126646 z października 2026 r. |
| Windows Server 2019 i 2022 | Wraz z październikową aktualizacją dodano rozszerzone zdarzenia monitorowania NTLM. Nie należy tego mylić z blokowaniem po stronie klienta przez BlockNtlmv1SSO. |
Dla Windows 11 24H2, 25H2 i 26H2 Microsoft podaje następujące wersje kompilacji systemu operacyjnego dla aktualizacji KB5127648:
- Windows 11 24H2: Kompilacja 26100.9711
- Windows 11 25H2: Build 26200.9711
- Windows 11 26H2: Build 26300.9711
Dla systemu Windows Server 2025 firma Microsoft udostępnia aktualizację KB5126646 z kompilacją systemu operacyjnego 26100.33650.
Mapowanie aktualizacji jest ważne, ponieważ nie każda wersja systemu Windows otrzymuje tę samą zmianę pod tym samym numerem KB. Pomoc techniczna dla ustawienia w KB5066470 nie jest automatycznym dowodem na to, że określona aktualizacja zbiorcza dotyczy każdej wymienionej wersji.
Dlaczego połączenia Wi-Fi, LAN i VPN mogą być dotknięte?
Potencjalne problemy z połączeniem nie wynikają z sygnału Wi-Fi ani nagle uszkodzonego adaptera sieciowego. Krytycznym punktem jest uwierzytelnianie: system Windows w określonych konfiguracjach nie może już automatycznie udostępniać poświadczeń pochodnych NTLMv1 dla logowania jednokrotnego.
Dotyczy to w szczególności środowisk, w których MS-CHAPv2 jest używany do logowania do sieci. Firma Microsoft wymienia połączenia Wi-Fi, Ethernet i VPN. Jednak nie każde połączenie tego typu jest dotknięte. Kluczowe jest to, czy odpowiedni przepływ uwierzytelniania zależy od zablokowanych poświadczeń SSO.
Wi-Fi i 802.1X
W sieciach korporacyjnych Wi-Fi często nie jest zabezpieczane tylko wspólnym hasłem. Zamiast tego użytkownicy lub urządzenia mogą uwierzytelniać się za pomocą 802.1X. W tym celu stosuje się różne metody EAP.
Możliwe konfiguracje obejmują PEAP-MSCHAPv2 i EAP-MSCHAPv2. W niektórych środowiskach przyłączonych do domeny metody te mogą wykorzystywać poświadczenia pochodne NTLMv1 do logowania jednokrotnego.
Jeśli automatyczne udostępnianie tych poświadczeń zostanie zablokowane, logowanie do sieci Wi-Fi może się nie powieść lub może być wymagane ręczne wprowadzenie danych uwierzytelniających. Sam sygnał radiowy i adapter Wi-Fi nie muszą być przyczyną problemu.
Połączenia LAN przez kabel
Połączenia sieciowe przez kabel mogą być również dotknięte, jeśli wykorzystują odpowiednie uwierzytelnianie oparte na 802.1X lub MS-CHAPv2. Dotyczy to przede wszystkim centralnie zarządzanych sieci korporacyjnych.
Zwykłe połączenie Ethernet z prywatnym routerem nie jest natomiast automatycznie dotknięte. Kluczowe jest tutaj również używane uwierzytelnianie, a nie tylko rodzaj połączenia sieciowego.
Połączenia VPN
W przypadku połączeń VPN MS-CHAPv2 może być również używany do uwierzytelniania. Jeśli logowanie opiera się na poświadczeniach SSO pochodnych NTLMv1, system Windows może zablokować automatyczne logowanie.
Awaria VPN po aktualizacji systemu Windows nie jest zatem automatycznie dowodem problemu z NTLMv1. Protokół VPN, serwer uwierzytelniania, certyfikaty, dostęp do sieci i inne konfiguracje również muszą być brane pod uwagę podczas rozwiązywania problemów.
Co to jest MS-CHAPv2 i jaką rolę odgrywa?
MS-CHAPv2 to skrót od Microsoft Challenge Handshake Authentication Protocol Version 2. Jest to metoda uwierzytelniania, w której system odpowiada na wyzwanie serwera obliczoną kryptograficznie odpowiedzią.
MS-CHAPv2 nie jest tym samym co NTLMv1. Są to różne mechanizmy uwierzytelniania. Istnieje jednak między nimi powiązanie istotne z punktu widzenia bezpieczeństwa.
Microsoft wyjaśnia, że MS-CHAPv2 podczas uwierzytelniania używa skrótu MD4 hasła użytkownika do odpowiedzi na wyzwanie. Powstała w ten sposób odpowiedź jest kryptograficznie równoważna NTLMv1. Może to stwarzać porównywalną powierzchnię ataku, mimo że sam protokół NTLMv1 został już usunięty z urządzenia.
Wyjaśnia to, dlaczego Microsoft dodatkowo blokuje użycie odpowiednich poświadczeń. Zmiana bezpieczeństwa nie dotyczy MS-CHAPv2 jako terminu ani każdego możliwego zastosowania procedury jako takiego, ale użycia poświadczeń pochodnych NTLMv1 w określonych przepływach SSO.
Wpis Microsoft „Bracing for BlockNtlmv1SSO” z 23 października 2026 r. wyjaśnia ten związek kryptograficzny i opisuje możliwe skutki dla środowisk VPN, WLAN, NPS i RADIUS.
Czy dotyczy mnie jako użytkownika prywatnego?
Kiedy Windows 11 – Microsoft Windows Windows 11 w domu za pomocą zwykłego routera WLAN i łączy się z siecią za pomocą hasła WLAN, zazwyczaj nie jest objęty tą konkretną zmianą. Opisane problemy wymagają specjalnej konfiguracji uwierzytelniania.
Inaczej może być w przypadku zarządzanych urządzeń, które są podłączone na przykład do sieci firmowej, centralnie zarządzanej sieci WLAN lub odpowiednio skonfigurowanego VPN.
Ważną rolę odgrywa również Credential Guard. Jest to funkcja zabezpieczeń Windows, która chroni określone poświadczenia za pomocą funkcji wirtualizacji. Microsoft wyraźnie wyjaśnia, że opisana tutaj zmiana dotyczy BlockNtlmv1SSO tylko urządzeń, na których Credential Guard jest wyłączony. Jeśli Credential Guard jest włączony, ta konkretna zmiana nie wchodzi w życie.
Nie oznacza to jednak, że Credential Guard i nowe środki ochrony NTLMv1 są identyczne. Microsoft wyraźnie zaznacza, że Credential Guard zapewnia szerszą ochronę i zaleca jego aktywację na obsługiwanych platformach, o ile spełnione są wymagania techniczne.
Dlaczego logowanie ręczne może nadal działać?
Zmiana dotyczy generowania określonych poświadczeń pochodnych NTLMv1 dla Single Sign-On. SSO umożliwia systemowi Windows automatyczne wykorzystywanie istniejących poświadczeń do dalszych usług lub połączeń sieciowych.
Jeśli ta automatyczna ścieżka logowania zostanie zablokowana, ręczne wprowadzenie danych uwierzytelniających może nadal działać. Nie jest to sprzeczność: podczas logowania ręcznego dane uwierzytelniające są pobierane bezpośrednio, podczas gdy objęty zmianą przepływ SSO opiera się na automatycznym udostępnianiu poświadczeń.
Microsoft wyraźnie potwierdza, że ręczne wprowadzanie poświadczeń jest nadal możliwe nawet w trybie wymuszania. To, czy konkretne połączenie zostanie pomyślnie nawiązane, zależy dodatkowo od odpowiedniej konfiguracji uwierzytelniania.
Jak administratorzy mogą stwierdzić, czy systemy są objęte zmianą?
Firmy powinny przede wszystkim zbadać istniejące konfiguracje uwierzytelniania. Szczególnie istotne są dostępy WLAN, Ethernet i VPN, które wykorzystują MS-CHAPv2 lub oparte na nim procedury.
Microsoft udostępnia w tym celu dzienniki monitorowania i zdarzeń. Na objętych zmianą klientach Windows zdarzenia są rejestrowane w dzienniku Microsoft-Windows-NTLM/Operational .
| Identyfikator zdarzenia | Oznaczający |
|---|---|
| 4024 | Tryb monitorowania: Zarejestrowano próbę użycia poświadczeń pochodnych NTLMv1 do logowania jednokrotnego. Żądanie może nadal być realizowane pomyślnie. |
| 4025 | Tryb wymuszania: Próba użycia poświadczeń pochodnych NTLMv1 do logowania jednokrotnego została zablokowana przez zasady. Żądanie nie może być realizowane. |
Podgląd zdarzeń można otworzyć z menu Start. Administratorzy znajdą odpowiedni dziennik w obszarze „Dzienniki aplikacji i usług” w sekcji Microsoft-Windows-NTLM/Operational.
Zdarzenia zawierają między innymi informacje o serwerze docelowym, użytkowniku, procesie i używanym mechanizmie uwierzytelniania. Pozwala to prześledzić, która aplikacja lub połączenie żąda problematycznych poświadczeń.
Dodatkowe monitorowanie na kontrolerach domeny
Firmy korzystające z Windows Server 2019 lub Windows Server 2022 mają dodatkową możliwość wykrywania potencjalnych zależności MS-CHAPv2. Wraz z aktualizacjami z października 2026 r. rozszerzone zdarzenia monitorowania NTLM zostały przeniesione wstecznie do tych wersji serwerów.
Szczególnie istotny jest identyfikator zdarzenia 4033, który może wystąpić na kontrolerze domeny, gdy serwer VPN przekazuje odpowiedź typu challenge-response w celu weryfikacji poświadczeń. Na podstawie danych zdarzenia można stwierdzić, czy jest to odpowiednia operacja MS-CHAPv2.
Monitorowanie na kontrolerze domeny należy odróżnić od blokowania po stronie klienta przez BlockNtlmv1SSO . Rozszerzone zdarzenia pomagają administratorom identyfikować istniejące zależności. Nie oznaczają one, że Windows Server 2019 lub 2022 automatycznie otrzymuje to samo blokowanie po stronie klienta.
Firma Microsoft zaleca centralne gromadzenie i analizowanie dzienników zdarzeń NTLM kontrolerów domeny. W większych środowiskach można do tego celu wykorzystać na przykład system SIEM.
Lista kontrolna dla administratorów IT
- Sprawdź, jakie wersje klientów i serwerów Windows są używane w środowisku.
- Ustal, czy zainstalowano odpowiednie aktualizacje zabezpieczeń z października.
- Sprawdź, czy Credential Guard jest aktywowany na problematycznych klientach.
- Wartość rejestru
BlockNtlmv1SSOi jego konfigurację. - Zbadać zdarzenia 4024 i 4025 w protokole NTLM klientów.
- Na kontrolerach domeny z systemem Windows Server 2019 lub 2022 dodatkowo sprawdzić rozszerzone zdarzenia audytu, w szczególności identyfikator zdarzenia 4033.
- Zbadać konfiguracje WLAN, Ethernet i VPN pod kątem zależności od MS-CHAPv2.
- Dokumentacja aplikacji, serwerów uwierzytelniania i dostępu sieciowego.
- Zaplanuj i przetestuj przejście na odpowiednią alternatywną metodę uwierzytelniania.
Identyfikatory zdarzeń, konfiguracja rejestru i informacje o wdrożeniu znajdują się w Microsoft-Dokumentation KB5066470 Dodatkowe monitorowanie na serwerach 2019 i 2022 jest wyjaśnione przez Microsoft we wpisie „Bracing for BlockNtlmv1SSO”.
Jakie tymczasowe rozwiązanie oferuje Microsoft?
Jeśli firma stwierdzi krytyczne uzależnienie od MS-CHAPv2 i nie może natychmiast zmienić uwierzytelniania, Microsoft oferuje tymczasową opcję kompatybilności. W tym celu można ustawić wartość rejestru BlockNtlmv1SSO NA 0 .
Wartość ta aktywuje tryb monitorowania. Windows nadal rejestruje użycie dotkniętych danych uwierzytelniających, ale ich nie blokuje. Pozwala to na tymczasowe ponowne pomyślne wykonanie odpowiednich wymagań SSO.
Odpowiednia ścieżka rejestru to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
. W ramach tego klucza rejestru tworzona jest wartość DWORD (32-bitowa) BlockNtlmv1SSO lub dostosowywana jest istniejąca wartość.
| Wartość | Zachowanie |
|---|---|
| 0 | Tryb monitorowania: Żądania są rejestrowane, ale dozwolone. |
| 2 | Tryb wymuszania: Dotknięte żądania są blokowane. |
Do tej zmiany wymagane są uprawnienia administratora. Według firmy Microsoft po zmianie wartości nie jest wymagane ponowne uruchomienie urządzenia. Ustawienie jest natychmiast skuteczne.
Ważny: Wartość 0 nie jest trwałym rozwiązaniem zabezpieczającym. Pozwala ona na ponowne użycie dotkniętych poświadczeń, tym samym zmniejszając ochronę trybu wymuszania. Firmy powinny używać tego ustawienia tylko w przypadku udokumentowanej krytycznej zależności, przez ograniczony czas i z udokumentowanym wyjątkiem.
Die Ereignisse im Überwachungsmodus helfen dabei, die verbleibenden Abhängigkeiten zu identifizieren. Sobald die betroffenen Authentifizierungsabläufe migriert wurden, sollte der Wert wieder auf 1 Microsoft
Dlaczego Microsoft zaleca uwierzytelnianie oparte na certyfikatach?
Długoterminowo firmy powinny wyeliminować swoją zależność od MS-CHAPv2 i przejść na odpowiednią alternatywną metodę uwierzytelniania. Microsoft wymienia EAP-TLS jako alternatywę w tym kontekście.
W EAP-TLS uwierzytelnianie odbywa się za pomocą certyfikatów cyfrowych. Eliminuje to zależność od opisanych procesów MS-CHAPv2 opartych na hasłach i powiązanych z nimi danych uwierzytelniających pochodzących z NTLMv1.
Taka zmiana wiąże się jednak z przygotowaniami w środowiskach korporacyjnych. Mogą one obejmować odpowiednią infrastrukturę certyfikatów, wdrażanie i zarządzanie certyfikatami klienckimi, a także dostosowania dostępu do sieci i serwerów uwierzytelniania.
Dlatego migracja powinna najpierw odbyć się w środowisku testowym. Następnie można stopniowo zmieniać dotknięte połączenia WLAN, Ethernet i VPN. Przed szerokim wdrożeniem administratorzy powinni sprawdzić, czy wszystkie używane urządzenia, konta użytkowników i komponenty sieciowe obsługują nową metodę.
Co powinni zrobić użytkownicy domowi i firmy?
Użytkownicy prywatni
- Instaluj aktualizacje systemu Windows jak zwykle.
- Nie zmieniaj żadnych wpisów w rejestrze zapobiegawczo.
- Nie wyłączaj samodzielnie funkcji Credential Guard ani innych funkcji zabezpieczeń.
- W przypadku problemów z połączeniem najpierw sprawdź, czy dotyczy to również innych urządzeń i czy połączenie internetowe działa ogólnie.
- W przypadku zarządzanego urządzenia służbowego skontaktuj się z działem IT, zamiast samodzielnie zmieniać ustawienia uwierzytelniania.
Małe firmy
- Sprawdź, czy WLAN lub VPN używają centralnego uwierzytelniania.
- Zapytaj dostawcę usług sieciowych lub opiekuna IT o możliwe zależności MS-CHAPv2.
- Dokumentuj problemy z połączeniem po październikowej aktualizacji.
- Rozważ tymczasowy powrót do trybu monitorowania tylko po technicznym sprawdzeniu i z wyraźnym ograniczeniem czasowym.
- Przygotuj się na wdrożenie odpowiedniej alternatywnej metody uwierzytelniania.
Duże środowiska IT
- Centralnie analizuj zdarzenia 4024 i 4025 na klientach.
- Uwzględnij rozszerzone zdarzenia audytu NTLM na kontrolerach domeny.
- Zidentyfikuj dotknięte przepływy uwierzytelniania i zależności.
- Przeprowadź wdrożenie aktualizacji zabezpieczeń w sposób kontrolowany, bez odkładania aktualizacji zabezpieczeń na później.
- Dokumentuj i monitoruj tymczasowe wyjątki.
- Zaplanuj przejście na EAP-TLS i przetestuj je w środowisku testowym.
- Przygotuj Helpdesk i użytkowników na ewentualne ręczne monity logowania.
Wniosek: Brak ogólnej awarii sieci WLAN, ale potrzeba działania dla firm
Ograniczenie NTLMv1 w Windows 11 to ukierunkowane działanie zabezpieczające. Wraz z październikowymi aktualizacjami zabezpieczeń 2026, Windows domyślnie blokuje określone dane uwierzytelniające pochodzące z NTLMv1 dla Single Sign-On. Może to prowadzić do problemów w środowiskach korporacyjnych z połączeniami WLAN, Ethernet i VPN, jeśli opierają się one na odpowiednich przepływach uwierzytelniania opartych na MS-CHAPv2.
Zwykłe prywatne połączenia WLAN zazwyczaj nie stanowią powodu do obaw. Firmy powinny natomiast sprawdzić swoje konfiguracje uwierzytelniania, analizować dzienniki zdarzeń i stopniowo eliminować istniejące zależności MS-CHAPv2.
Powrót do trybu monitorowania udokumentowany przez Microsoft może pomóc w krótkim okresie, ale powinien być stosowany tylko jako ograniczone rozwiązanie przejściowe. Długoterminowo zaleca się przejście na odpowiednią metodę opartą na certyfikatach, taką jak EAP-TLS.
Dalsza dokumentacja Microsoft
- Windows 11: Aktualizacja zabezpieczeń z 13 października 2026 – KB5127648
- Windows Server 2025: Aktualizacja zabezpieczeń z 13 października 2026 – KB5126646
- KB5066470: Zarządzanie zmianami NTLMv1 i zapobieganie problemom z uwierzytelnianiem sieciowym
- Microsoft TechCommunity: Bracing for BlockNtlmv1SSO
Stan: 6 listopada 2026