KB5127648 och NTLMv1: Varför PEAP-MSCHAPv2 Wi-Fi, LAN och VPN slutade ansluta och hur du löser det permanent

Kortsvaret

Sedan KB5127648, den kumulativa uppdateringen för oktober 2026 för Windows 11 24H2, 25H2 och 26H2, blockerar Windows NTLMv1-härledda autentiseringsuppgifter för enkel inloggning (SSO) som standard. Windows Server 2025 får samma förändring med sin uppdatering för oktober 2026. På enheter utan Credential Guard ansluter Wi-Fi, Ethernet (kabelburet 802.1X) och VPN-anslutningar som använder PEAP-MSCHAPv2 eller EAP-MSCHAPv2 med Windows-autentiseringsuppgifter inte längre automatiskt.

Att sätta registervärdet BlockNtlmv1SSO till 0 återställer det gamla beteendet tills vidare. Den permanenta fix som Microsoft rekommenderar är certifikatbaserad autentisering med EAP-TLS.

Sammanfattning

• Vad som ändrades: Windows tillämpar nu BlockNtlmv1SSO på alla enheter där en administratör inte har konfigurerat det. Microsoft aviserade detta i Message Center-inlägget MC1508562 och dokumenterar det i KB5066470.
• Vem som drabbas: Enheter utan Credential Guard som använder MS-CHAPv2-baserad enkel inloggning, typiskt domänanslutna Windows-klienter.
• Snabb lösning: Sätt BlockNtlmv1SSO till 0. Microsoft säger själva att inställningen inte bör användas långsiktigt.
• Permanent fix: Migrera till EAP-TLS. Med SCEPman kan du göra det utan att bygga en lokal PKI.

Vad ändrades med KB5127648

Microsoft har successivt fasat ut NTLM. Det senaste steget drabbar ett protokoll som många nätverk fortfarande förlitar sig på dagligen: MS-CHAPv2. Det är byggt på NTLMv1-härledda autentiseringsuppgifter, och Windows delar inte längre ut dem för enkel inloggning.

Microsoft aviserade tillämpningen i Message Center-inlägget MC1508562, "Take action: NTLMv1 hardening changes might affect network connections on devices without Credential Guard". Den tekniska bakgrunden finns i KB5066470.

Microsoft kallar detta en planerad säkerhetshärdning, inte ett känt fel i uppdateringen. Den är med andra ord här för att stanna.

Är du påverkad?

Du är troligtvis påverkad om samtliga av följande stämmer:

• Dina enheter kör Windows 11 24H2 eller senare, eller Windows Server 2025, med uppdateringen för oktober 2026 (KB5127648 på Windows 11) installerad.
• Credential Guard är inaktiverat på dessa enheter.
• Ditt Wi-Fi, Ethernet (kabelburet 802.1X) eller VPN använder PEAP-MSCHAPv2 eller EAP-MSCHAPv2 med enkel inloggning. Det gäller typiskt domänanslutna enheter där "Använd automatiskt mitt Windows-inloggningsnamn och lösenord" är aktiverat.
• Registervärdet BlockNtlmv1SSO har aldrig konfigurerats.

Du påverkas inte av den här förändringen om dina enheter redan använder certifikatbaserad autentisering (EAP-TLS). Enheter med Credential Guard aktiverat blockerade redan det här beteendet, så lösenordsbaserad SSO fungerade inte där ändå. Förändringen gäller Windows, så macOS-, iOS-, Android- och Linux-klienter påverkas inte.

Så här yttrar det sig

• Enheter ansluter inte längre automatiskt och användarna får en inloggningsruta.
• Att skriva in lösenordet manuellt fungerar fortfarande, men Windows kan inte spara det till nästa gång.
• Arbetsflöden som tidigare anslöt utan användarinteraktion slutar fungera, till exempel delade enheter eller kioskenheter och VPN-profiler som ansluter automatiskt.
• Klienten loggar Event ID 4025 ("blockerad") i Microsoft-Windows-NTLM/Operational. I granskningsläge loggas Event ID 4024 istället.

Felet uppstår på klienten, så dina RADIUS- eller NPS-loggar kan visa lite eller ingenting. Börja felsöka på slutpunkten.

Hur du kontrollerar en enhet

# Är BlockNtlmv1SSO konfigurerat? (inget värde = Windows använder den nya Enforce-standarden)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO

# Har Windows granskat (4024) eller blockerat (4025) NTLMv1-härledda autentiseringsuppgifter?
Get-WinEvent -LogName 'Microsoft-Windows-NTLM/Operational' -FilterXPath '*[System[(EventID=4024 or EventID=4025)]]' -MaxEvents 50

Den snabba lösningen: sätt BlockNtlmv1SSO till 0

Du kan återföra påverkade enheter till granskningsläge. Windows tillåter då NTLMv1-härledda autentiseringsuppgifter igen och loggar varje användning med Event ID 4024.

Kommandorad

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

Intune-reparation (körs i systemkontext)

# Identifieringsskript: kompatibelt endast om BlockNtlmv1SSO uttryckligen är satt till 0
$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 }

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

För domänanslutna enheter använder du ett Group Policy Preferences-registerobjekt med samma nyckel, värdenamn, typ och data.

Varför det bara är en tillfällig lösning

• Det öppnar en svag väg igen. Microsoft uppger att MS-CHAPv2-baserade slutpunkter "är utsatta för risker liknande de som påverkar NTLMv1" och råder till att inställningen "bör utvärderas noga och inte användas långsiktigt."
• Det hjälper inte enheter med Credential Guard. De blockerar MS-CHAPv2 SSO oavsett den här inställningen.
• Offline-enheter kan inte ta emot policy. Enheter som redan har förlorat nätverksåtkomst kan behöva ett kabelanslutet eller gästnätverk för att hämta inställningen.
• Att avinstallera uppdateringen är inget alternativ. Det lämnar enheterna utan månadens säkerhetsfixar.

Använd lösningen för att köpa tid, sätt ett dokumenterat slutdatum på den och använd den tiden till att migrera.

Den permanenta fixen: EAP-TLS istället för lösenord

Microsoft rekommenderar att ta bort beroendet av MS-CHAPv2 och flytta Wi-Fi- och VPN-anslutningar till certifikatbaserad autentisering med EAP-TLS. Enheten eller användaren styrker då sin identitet med ett certifikat och en privat nyckel istället för ett lösenord, och den privata nyckeln kan skyddas av TPM.

Utöver att lösa avbrottet får du en bättre användarupplevelse och ett starkare säkerhetsläge.

Varför så många nätverk fortfarande körs på lösenord

Protokollet är inte den svåra delen. Det är PKI:n. Den klassiska uppsättningen inkluderar AD CS, NDES, Intune Certificate Connector, en applikationsproxy, CRL-publicering, hög tillgänglighet och patchning. Det är många rörliga delar bara för att lägga ett certifikat på en bärbar dator, och det är anledningen till att många team har skjutit upp flytten i flera år. Mer om detta i Microsoft ADCS Alternatives in 2026.

Hur SCEPman tar bort PKI-komplexiteten

SCEPman är en Azure-native certifikatutfärdare som körs helt i din egen Azure-klient, med nycklar i Azure Key Vault.

• Snabb start: Distribuera via Azure Marketplace, ARM-mall eller Terraform. De flesta team utfärdar sitt första certifikat på under en timme.
• Hanterade enheter: Microsoft Intune, Jamf Pro och andra MDM:er utfärdar och förnyar enhets- och användarcertifikat automatiskt via SCEP.
• Realtidsvalidering: Certifikat är kopplade till användar- eller enhetsobjektet och kontrolleras via OCSP. När en identitet ändras återkallas åtkomsten automatiskt.
• Fungerar med ditt nätverk: SCEPman stöder Cisco och Meraki, HPE Aruba, Fortinet, Juniper med flera, och fungerar med din befintliga RADIUS-server.
• Inga RADIUS-servrar behövs: Kombinerat med RADIUSaaS får du en komplett molnbaserad lösning för certifikatbaserad Wi-Fi-, LAN- och VPN-åtkomst.

Din migrationsväg i sex steg

1. Ta inventering. Ta reda på vilka SSID:er, kabelburna 802.1X-policyer och VPN-profiler som fortfarande använder MS-CHAPv2. Event ID 4024 och 4025 visar vilka enheter som är beroende av det.
2. Köp tid där det behövs. Sätt BlockNtlmv1SSO till 0 på kritiska enheter, men dokumentera det och sätt ett slutdatum.
3. Distribuera SCEPman och sprid dess rot-CA-certifikat, antingen via en betrodd certifikatprofil i Intune eller via grupprincip.
4. Rulla ut certifikat. Utfärda enhetscertifikat (och användarcertifikat där det behövs) via Intune, Jamf Pro eller andra MDM SCEP-profiler.
5. Byt över gradvis. Aktivera EAP-TLS på din RADIUS-server (NPS, din befintliga RADIUS eller RADIUSaaS) parallellt med PEAP. Flytta sedan dina Wi-Fi-, 802.1X- och VPN-profiler till EAP-TLS en grupp i taget.
6. Städa upp. Ta bort MS-CHAPv2-policyerna och sätt sedan BlockNtlmv1SSO tillbaka till 1, eller ta bort värdet så att Windows återgår till den säkra standarden:

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

Slutsats

Microsoft har fattat beslutet: lösenordsbaserad nätverks-SSO via MS-CHAPv2 har ingen framtid i Windows. Du kan lappa runt KB5127648 i några veckor, eller så använder du det här tillfället till att flytta till certifikatbaserad åtkomst för gott.

Enkel PKI. Tillförlitliga certifikat.

Prova SCEPman gratis

FAQ