Windows 11 blockiert NTLMv1-Single-Sign-On ab Oktober 2026
Mit dem Sicherheitsupdate vom 13. Oktober 2026 zieht Microsoft bei NTLMv1 die nächste Schraube an. Windows 11 und Windows Server 2025 behandeln bestimmte Anmeldungen mit NTLMv1-abgeleiteten Zugangsdaten künftig deutlich strenger.
Bislang wurden entsprechende Anmeldeversuche unter bestimmten Voraussetzungen lediglich protokolliert. Nach dem Oktober-Update werden sie standardmäßig blockiert.
Für normale Heim-PCs dürfte das meistens keine Rolle spielen. In Unternehmensnetzen kann die Änderung allerdings durchaus auffallen – insbesondere bei älteren WLAN-, Ethernet- oder VPN-Konfigurationen mit MS-CHAPv2.
NTLMv1 ist eigentlich schon entfernt
Zunächst klingt die Meldung etwas widersprüchlich.
Microsoft hat das eigentliche NTLMv1-Protokoll bereits aus Windows 11 24H2 und Windows Server 2025 entfernt.
Trotzdem existieren noch Anwendungsfälle, in denen kryptografische Bestandteile aus der NTLMv1-Welt verwendet werden.
Das betrifft unter anderem bestimmte Authentifizierungsverfahren auf Basis von:
- MS-CHAPv2
- PEAP-MSCHAPv2
- EAP-MSCHAPv2
Solche Konfigurationen findet man beispielsweise bei Unternehmens-WLANs, kabelgebundener 802.1X-Authentifizierung oder VPN-Verbindungen.
Microsoft möchte nun auch diese verbliebenen Abhängigkeiten schrittweise beseitigen.
Seit 2025 wurde zunächst nur protokolliert
Microsoft hat diesen Schritt bewusst vorbereitet.
Bereits mit Windows-Updates ab August beziehungsweise September 2025 wurde ein Audit-Modus eingeführt.
Wenn Windows dabei eine Anforderung für NTLMv1-abgeleitete SSO-Zugangsdaten erkannte, wurde diese protokolliert.
Die Anmeldung funktionierte aber weiterhin.
Administratoren sollten dadurch Zeit bekommen, alte Authentifizierungswege in ihrer Umgebung zu entdecken, bevor Microsoft sie tatsächlich blockiert.
Und genau diese Übergangsphase endet nun.
Oktober-Update schaltet standardmäßig auf Enforce
Mit dem Sicherheitsupdate vom 13. Oktober 2026 ändert Microsoft das interne Standardverhalten.
Ist der Registry-Wert:
BlockNtlmv1SSOnicht vorhanden, verwendete Windows bisher intern:
Audit Mode = 0Jetzt gilt stattdessen:
Enforce Mode = 1Der entscheidende Unterschied:
Im Audit-Modus wird die Verwendung zwar protokolliert, aber erlaubt.
Im Enforce-Modus wird die Anforderung blockiert.
Der Registry-Wert wird dabei nicht automatisch angelegt
Ein wichtiges Detail: Das Update erstellt den Registry-Wert nicht.
Auch nach Installation des Oktober-Updates kann BlockNtlmv1SSO also weiterhin komplett fehlen.
Windows interpretiert einen fehlenden Eintrag nun lediglich anders.
Vorher bedeutete „nicht vorhanden“ intern Audit.
Jetzt bedeutet „nicht vorhanden“ Enforce.
Das kann bei der Fehlersuche durchaus verwirrend sein, weil man in der Registry möglicherweise gar keine Änderung sieht.
Wo befindet sich die Einstellung?
Der relevante Registry-Pfad lautet:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0Dort kann ein DWORD-Wert angelegt werden:
BlockNtlmv1SSOMögliche Werte sind:
0 = Audit
1 = EnforceBei 0 werden entsprechende SSO-Anforderungen weiterhin zugelassen und protokolliert.
Bei 1 werden sie blockiert.
Ein Neustart des Geräts ist nach einer Änderung laut Microsoft nicht erforderlich.
Credential Guard ändert die Situation
Die Änderung betrifft allerdings nicht jeden Windows-PC.
Sie greift nur auf Geräten, auf denen Credential Guard deaktiviert ist.
Ist Credential Guard aktiv, gelten dessen umfangreicheren Schutzmechanismen.
Microsoft empfiehlt deshalb weiterhin ausdrücklich, Credential Guard auf unterstützten Systemen zu verwenden.
Die neue NTLMv1-Regel ist also kein Ersatz für Credential Guard.
Sie schließt lediglich einen weiteren verbliebenen Bereich rund um NTLMv1-basierte Kryptografie.
WLAN, Ethernet und VPN können betroffen sein
Besonders genau hinschauen sollten Administratoren bei älteren Netzwerkumgebungen.
Probleme können auftreten, wenn Single Sign-On für:
- WLAN
- Ethernet
- VPN
auf MS-CHAPv2-basierten Verfahren beruht.
Dazu gehören beispielsweise PEAP-MSCHAPv2 und EAP-MSCHAPv2.
Nach dem Update kann eine bisher automatisch funktionierende Anmeldung plötzlich fehlschlagen.
Das wirkt für den Nutzer dann möglicherweise wie ein normales Netzwerkproblem:
Das WLAN verbindet sich nicht mehr automatisch.
Der VPN-Zugang funktioniert plötzlich nicht.
Oder die kabelgebundene Anmeldung schlägt fehl.
Tatsächlich kann dahinter die neue NTLMv1-Blockade stecken.
Manuelle Eingabe kann weiterhin funktionieren
Interessant ist eine wichtige Einschränkung.
Microsoft spricht ausdrücklich von Single Sign-On mit NTLMv1-abgeleiteten Zugangsdaten.
Die manuelle Eingabe von Benutzername und Kennwort soll im Enforce-Modus weiterhin funktionieren.
Das kann bei der Diagnose ein ziemlich guter Hinweis sein.
Wenn eine Verbindung nicht mehr automatisch funktioniert, sich aber nach manueller Eingabe der Zugangsdaten herstellen lässt, sollte man die Authentifizierungskonfiguration genauer untersuchen.
Event-ID 4024 zeigt Audit-Nutzung
Für die Analyse hat Microsoft entsprechende Ereignisse vorgesehen.
Im Audit-Modus erscheint im Ereignisprotokoll:
Microsoft-Windows-NTLM/Operational
die Event-ID 4024.
Dabei handelt es sich um eine Warnung.
Sie signalisiert, dass eine Anwendung versucht hat, NTLMv1-abgeleitete Zugangsdaten für Single Sign-On zu verwenden.
Die Verbindung wird dabei noch zugelassen.
Administratoren sollten solche Ereignisse also nicht einfach ignorieren.
Sie zeigen ziemlich genau die Systeme und Anwendungen, die vor der Umstellung überprüft werden sollten.
Event-ID 4025 bedeutet: blockiert
Im Enforce-Modus sieht es anders aus.
Hier verwendet Windows die Event-ID 4025.
Das Ereignis wird als Fehler protokolliert und zeigt an, dass die Verwendung entsprechender Zugangsdaten durch die Richtlinie blockiert wurde.
In den Ereignissen finden sich unter anderem Informationen über:
- Zielserver
- Benutzer
- Domäne
- Prozess-ID
- Prozessname
- Benutzerkontext des Prozesses
Damit sollte sich relativ gut nachvollziehen lassen, welche Anwendung oder Netzwerkverbindung die alte Authentifizierung noch verwendet.
Was Administratoren jetzt prüfen sollten
Wer Unternehmens-WLAN, VPN oder 802.1X-Ethernet betreibt, sollte meiner Meinung nach nicht erst warten, bis sich die ersten Benutzer melden.
Zunächst würde ich auf betroffenen Systemen das NTLM-Operational-Protokoll prüfen.
Tauchen dort 4024-Ereignisse auf, besteht weiterhin eine Abhängigkeit.
Danach sollte geklärt werden, welche Authentifizierungsmethode verwendet wird und ob sich die Umgebung auf ein moderneres Verfahren umstellen lässt.
Gerade größere Umgebungen sollten die Änderung zunächst kontrolliert testen, bevor das Oktober-Update überall ausgerollt wird.
Audit-Modus kann vorübergehend zurückgebracht werden
Microsoft lässt Unternehmen einen Ausweg, falls eine kritische Abhängigkeit entdeckt wird.
Der Wert:
BlockNtlmv1SSOkann ausdrücklich auf:
0gesetzt werden.
Damit arbeitet Windows wieder im Audit-Modus.
Die problematische Authentifizierung funktioniert dann zunächst weiter und wird lediglich protokolliert.
Microsoft versteht das aber ausdrücklich als vorübergehende Ausnahme.
Es sollte also nicht die Dauerlösung sein, den alten Zustand einfach wieder einzuschalten und anschließend zu vergessen.
Das wäre zwar bequem, würde aber den eigentlichen Sinn der Sicherheitsänderung ziemlich elegant umgehen.
Warum Microsoft NTLM loswerden möchte
NTLM gehört zu den ältesten Authentifizierungsmechanismen in Windows-Umgebungen.
Microsoft arbeitet deshalb bereits seit längerer Zeit daran, NTLM zurückzudrängen und modernere Authentifizierungsverfahren zu fördern.
Besonders NTLMv1 gilt dabei schon lange als technisch überholt.
Windows 11 und Windows Server bewegen sich deshalb Stück für Stück von diesen Altlasten weg.
Dass Microsoft zunächst einen Audit-Modus eingeführt hat, ist aus meiner Sicht sinnvoll.
Unternehmen bekommen damit zumindest die Chance herauszufinden, wo solche Abhängigkeiten noch versteckt sind.
Und davon gibt es in gewachsenen Netzwerken erfahrungsgemäß oft mehr, als man denkt.
Mein Eindruck
Die Änderung ist sicherheitstechnisch nachvollziehbar.
Gleichzeitig ist sie ein schönes Beispiel dafür, warum Windows-Sicherheitsupdates in Unternehmensumgebungen manchmal mehr sind als nur „installieren und fertig“.
Ein alter WLAN-RADIUS-Aufbau oder eine seit Jahren unveränderte VPN-Konfiguration funktioniert möglicherweise tadellos – bis Microsoft einen jahrzehntealten Authentifizierungsweg abschaltet.
Dann wird aus einer Sicherheitsverbesserung plötzlich ein Helpdesk-Ticket.
Deshalb würde ich vor allem die Event-IDs 4024 und 4025 im Hinterkopf behalten.
Sie dürften bei der Fehlersuche deutlich hilfreicher sein als zehnmal den WLAN-Treiber neu zu installieren.
Fazit
Mit dem Oktober-2026-Sicherheitsupdate ändert Microsoft das Verhalten bei NTLMv1-abgeleiteten Single-Sign-On-Zugangsdaten.
Auf Windows 11 24H2, 25H2 und 26H2 sowie Windows Server 2025 wird bei deaktiviertem Credential Guard standardmäßig der Enforce-Modus verwendet, sofern BlockNtlmv1SSO nicht ausdrücklich gesetzt wurde.
Damit werden entsprechende SSO-Anforderungen nicht mehr nur protokolliert, sondern blockiert.
Betroffen sein können vor allem ältere WLAN-, Ethernet- und VPN-Konfigurationen auf Basis von MS-CHAPv2.
Unternehmen sollten deshalb ihre Ereignisprotokolle prüfen und vorhandene Abhängigkeiten möglichst beseitigen.
Der Audit-Modus lässt sich bei Bedarf vorübergehend wieder aktivieren – als Übergangslösung, nicht als Dauerzustand.
Quelle
Microsoft Support – KB5066470:
Manage changes to NTLMv1 and prevent network issues in Windows 11 and Windows Server 2025
https://support.microsoft.com/en-us/servicing/os/windows/docs/2025/08/upcoming-changes-to-ntlmv1-in-windows-11-version-24h2-and-windows-server-2025