KB5127648 und NTLMv1: Warum PEAP-MSCHAPv2 bei Wi-Fi, LAN und VPN nicht mehr verbindet und wie das dauerhaft behoben wird

Die kurze Antwort

Seit KB5127648, dem kumulativen Update vom Oktober 2026 für Windows 11 24H2, 25H2 und 26H2, blockiert Windows NTLMv1-abgeleitete Anmeldeinformationen für Single Sign-On standardmäßig. Windows Server 2025 erhält dieselbe Änderung mit seinem Oktober-2026-Update. Auf Geräten ohne Credential Guard verbinden sich Wi-Fi-, Ethernet- (kabelgebunden 802.1X) und VPN-Verbindungen, die PEAP-MSCHAPv2 oder EAP-MSCHAPv2 mit Windows-Anmeldedaten verwenden, nicht mehr automatisch.

Den Registrierungswert BlockNtlmv1SSO auf 0 zu setzen stellt das alte Verhalten vorübergehend wieder her. Die dauerhafte Lösung, die Microsoft empfiehlt, ist zertifikatbasierte Authentifizierung mit EAP-TLS.

TL;DR

• Was sich geändert hat: Windows erzwingt nun BlockNtlmv1SSO auf jedem Gerät, auf dem ein Administrator es nicht explizit konfiguriert hat. Microsoft hat dies im Message-Center-Beitrag MC1508562 angekündigt und in KB5066470 dokumentiert.
• Wer betroffen ist: Geräte ohne Credential Guard, die MS-CHAPv2-basiertes Single Sign-On verwenden, typischerweise domänengebundene Windows-Clients.
• Schneller Workaround: BlockNtlmv1SSO auf 0 setzen. Microsoft selbst weist darauf hin, dass diese Einstellung nicht dauerhaft verwendet werden sollte.
• Dauerhafte Lösung: Umstieg auf EAP-TLS. Mit SCEPman ist das ohne eine On-Premises-PKI möglich.

Was KB5127648 geändert hat

Microsoft schafft NTLM schrittweise ab. Der aktuelle Schritt trifft ein Protokoll, auf das viele Netzwerke noch täglich angewiesen sind: MS-CHAPv2. Es basiert auf NTLMv1-abgeleiteten Anmeldeinformationen, und Windows gibt diese für Single Sign-On nicht mehr heraus.

Microsoft hat die Durchsetzung im Message-Center-Beitrag MC1508562 angekündigt: „Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard". Den technischen Hintergrund liefert KB5066470.

Microsoft bezeichnet dies als geplante Sicherheitshärtungsmaßnahme, nicht als bekanntes Problem mit dem Update. Diese Änderung bleibt also bestehen.

Bin ich betroffen?

Du bist wahrscheinlich betroffen, wenn alle folgenden Punkte zutreffen:

• Deine Geräte laufen unter Windows 11 24H2 oder höher oder Windows Server 2025 mit installiertem Oktober-2026-Update (KB5127648 auf Windows 11).
• Credential Guard ist auf diesen Geräten deaktiviert.
• Dein Wi-Fi, Ethernet (kabelgebunden 802.1X) oder VPN verwendet PEAP-MSCHAPv2 oder EAP-MSCHAPv2 mit Single Sign-On. Das ist typischerweise ein domänengebundenes Gerät mit aktivierter Option „Meinen Windows-Anmeldenamen und mein Kennwort automatisch verwenden".
• Der Registrierungswert BlockNtlmv1SSO wurde noch nie gesetzt.

Von dieser Änderung nicht betroffen bist du, wenn deine Geräte bereits zertifikatbasierte Authentifizierung (EAP-TLS) verwenden. Geräte mit aktiviertem Credential Guard haben dieses Verhalten bereits blockiert, passwortbasiertes SSO war dort also bereits nicht möglich. Da die Änderung in Windows liegt, sind macOS-, iOS-, Android- und Linux-Clients nicht betroffen.

So zeigt sich das Problem

• Geräte verbinden sich nicht mehr automatisch, und Benutzer werden zur Eingabe von Anmeldedaten aufgefordert.
• Die manuelle Eingabe des Kennworts funktioniert noch, aber Windows kann es nicht für den nächsten Versuch speichern.
• Abläufe, die bisher ohne Benutzerinteraktion verbunden haben, funktionieren nicht mehr, zum Beispiel Freigabe- oder Kiosk-Geräte und VPN-Profile mit automatischer Verbindung.
• Der Client protokolliert Event ID 4025 („blockiert") in Microsoft-Windows-NTLM/Operational. Im Überwachungsmodus wird stattdessen Event ID 4024 protokolliert.

Der Fehler tritt auf dem Client auf, daher zeigen RADIUS- oder NPS-Protokolle möglicherweise wenig oder nichts. Beginne die Fehlersuche am Endpunkt.

So prüfst du ein Gerät

# Ist BlockNtlmv1SSO konfiguriert? (kein Wert = Windows verwendet den neuen Enforce-Standard)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# Hat Windows NTLMv1-abgeleitete Anmeldeinformationen überwacht (4024) oder blockiert (4025)?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

Der schnelle Workaround: BlockNtlmv1SSO auf 0 setzen

Du kannst betroffene Geräte wieder in den Überwachungsmodus versetzen. Windows erlaubt dann NTLMv1-abgeleitete Anmeldeinformationen wieder und protokolliert jede Verwendung mit Event ID 4024.

Befehlszeile

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Intune-Bereinigung (im Systemkontext ausführen)

# Erkennungsskript: konform nur wenn BlockNtlmv1SSO explizit auf 0 gesetzt ist
$v = (Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -ErrorAction SilentlyContinue).BlockNtlmv1SSO
if ($v -eq 0) { exit 0 } else { exit 1 }

# Behebungsskript
New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0' -Name 'BlockNtlmv1SSO' -PropertyType DWord -Value 0 -Force | Out-Null

Für domänengebundene Geräte verwendest du ein Gruppenrichtlinieneinstellungen-Registrierungselement mit demselben Schlüssel, Wertnamen, Typ und Daten.

Warum das nur ein Workaround ist

• Er öffnet einen schwachen Pfad wieder. Microsoft erklärt, dass MS-CHAPv2-basierte Endpunkte „ähnlichen Risiken wie NTLMv1 ausgesetzt sind" und empfiehlt, dass diese Einstellung „sorgfältig bewertet und nicht dauerhaft verwendet werden sollte".
• Geräten mit Credential Guard hilft er nicht. Diese blockieren MS-CHAPv2-SSO unabhängig von dieser Einstellung.
• Offline-Geräte können keine Richtlinie empfangen. Geräte, die bereits keinen Netzwerkzugang mehr haben, benötigen möglicherweise ein kabelgebundenes oder Gastnetzwerk, um die Einstellung zu erhalten.
• Das Update zu deinstallieren ist keine Alternative. Damit werden die Sicherheits-Fixes des Monats von den Geräten entfernt.

Verwende den Workaround, um Zeit zu gewinnen, versehe ihn mit einem dokumentierten Enddatum und nutze diese Zeit für die Migration.

Die dauerhafte Lösung: EAP-TLS statt Passwörter

Microsoft empfiehlt, die Abhängigkeit von MS-CHAPv2 aufzulösen und Wi-Fi- sowie VPN-Verbindungen auf zertifikatbasierte Authentifizierung mit EAP-TLS umzustellen. Das Gerät oder der Benutzer weist seine Identität dann mit einem Zertifikat und einem privaten Schlüssel nach statt mit einem Kennwort, wobei der private Schlüssel durch das TPM geschützt werden kann.

Neben der Behebung des Ausfalls erhältst du eine bessere Benutzererfahrung und eine stärkere Sicherheitsstellung.

Warum so viele Netzwerke noch auf Kennwörter setzen

Das Protokoll ist nicht das Problem. Die PKI ist es. Der klassische Aufbau umfasst AD CS, NDES, den Intune Certificate Connector, einen Anwendungsproxy, CRL-Veröffentlichung, Hochverfügbarkeit und Patching. Das sind viele bewegliche Teile, nur um ein Zertifikat auf einem Laptop zu platzieren, und genau das ist der Grund, warum viele Teams den Umstieg jahrelang aufgeschoben haben. Mehr dazu in Microsoft ADCS Alternatives in 2026.

Wie SCEPman die PKI aus der Gleichung nimmt

SCEPman ist eine Azure-native Zertifizierungsstelle, die vollständig im eigenen Azure-Tenant läuft und Schlüssel in Azure Key Vault speichert.

• Schneller Einstieg: Bereitstellung über Azure Marketplace, ARM-Template oder Terraform. Die meisten Teams stellen ihr erstes Zertifikat in unter einer Stunde aus.
• Verwaltete Geräte: Microsoft Intune, Jamf Pro und andere MDMs stellen Geräte- und Benutzerzertifikate automatisch per SCEP aus und erneuern sie.
• Echtzeit-Validierung: Zertifikate sind an das Benutzer- oder Geräteobjekt gebunden und werden per OCSP geprüft. Ändert sich eine Identität, wird der Zugang automatisch widerrufen.
• Kompatibel mit deinem Netzwerk: SCEPman unterstützt Cisco und Meraki, HPE Aruba, Fortinet, Juniper und andere und funktioniert mit deinem vorhandenen RADIUS-Server.
• Keine RADIUS-Server erforderlich: In Kombination mit RADIUSaaS erhältst du eine vollständig cloudnative Lösung für zertifikatbasiertes Wi-Fi, LAN und VPN.

Migrationsplan in sechs Schritten

1. Bestandsaufnahme machen. Herausfinden, welche SSIDs, kabelgebundenen 802.1X-Richtlinien und VPN-Profile noch MS-CHAPv2 verwenden. Event IDs 4024 und 4025 zeigen, welche Geräte davon abhängen.
2. Zeit kaufen, wo nötig. BlockNtlmv1SSO auf kritischen Geräten auf 0 setzen, dabei aber dokumentieren und ein Enddatum festlegen.
3. SCEPman bereitstellen und das Stammzertifikat der CA verteilen, entweder über ein vertrauenswürdiges Intune-Zertifikatprofil oder über Gruppenrichtlinien.
4. Zertifikate ausrollen. Gerätezertifikate (und wo nötig Benutzerzertifikate) über Intune, Jamf Pro oder andere MDM-SCEP-Profile ausstellen.
5. Schrittweise umstellen. EAP-TLS auf dem RADIUS-Server (NPS, dem vorhandenen RADIUS oder RADIUSaaS) parallel zu PEAP aktivieren. Dann Wi-Fi-, 802.1X- und VPN-Profile gruppenweise auf EAP-TLS umstellen.
6. Aufräumen. Die MS-CHAPv2-Richtlinien entfernen und dann BlockNtlmv1SSO wieder auf 1 setzen oder den Wert löschen, damit Windows wieder den sicheren Standard verwendet:

reg delete "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /f

Fazit

Microsoft hat die Entscheidung getroffen: Kennwortbasiertes Netzwerk-SSO via MS-CHAPv2 hat auf Windows keine Zukunft mehr. Du kannst KB5127648 ein paar Wochen lang umschiffen oder diesen Moment nutzen, um dauerhaft auf zertifikatbasiertes Netzwerken umzusteigen.

Solide PKI. Zuverlässige Zertifikate.

SCEPman kostenlos testen

FAQ