Microsoft zet in oktober 2026 een volgende stap in de uitfasering van het oude inlogprotocol NTLM. In Windows 11 en Windows Server 2025 gaat het blokkeren van NTLMv1-afgeleide inloggegevens dan standaard aan. Voor beheerders is dit het moment om te controleren of hun netwerk nog op dit mechanisme leunt.
Wat is er aan de hand?
Microsoft werkt aan het uitfaseren van NTLM, het oude inlogprotocol uit Windows. In oktober 2026 volgt de eerstvolgende harde stap: in Windows 11 versie 24H2 en later en in Windows Server 2025 gaat de instelling voor NTLMv1-afgeleide inloggegevens standaard van meten naar blokkeren. De Windows IT Pro Blog publiceerde op 9 september 2026 bovendien een uitgebreide veelgestelde-vragenlijst over de uitfasering.
Wat verandert er in oktober?
Het gaat om de registerwaarde BlockNtlmv1SSO onder het pad HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0. Tot nu toe staat die op 0: aanvragen om NTLMv1-gegevens voor een ingelogde gebruiker worden dan gelogd, maar wel toegestaan. Met de wijziging wordt de standaardwaarde 1, waarbij zulke aanvragen worden geweigerd. Beheerders kunnen de waarde zelf aanpassen als een omgeving er nog niet klaar voor is.
Waar gaat het precies om?
Het NTLMv1-protocol zelf is al uit deze Windows-versies verwijderd. Wat overblijft zijn cryptografische restanten, bijvoorbeeld in MS-CHAPv2. Dat wordt nog gebruikt bij bepaalde Wi-Fi-, Ethernet- en VPN-verbindingen met single sign-on. De blokkade raakt vooral apparaten waarop Credential Guard niet is ingeschakeld.
Wat merken gebruikers ervan?
In de meeste gevallen niets. Waar een verbinding wel op NTLMv1-afgeleide gegevens leunt, kan het automatisch inloggen mislukken. Gebruikers moeten hun gebruikersnaam en wachtwoord dan handmatig invoeren. Microsoft geeft aan dat handmatig invoeren blijft werken.
Hoe controleer je of je getroffen wordt?
Windows legt het gebruik al vast in het logboek Microsoft-Windows-NTLM/Operational:
- Gebeurtenis-ID 4024: een waarschuwing dat NTLMv1-gegevens zijn gevraagd, terwijl de instelling nog op meten staat.
- Gebeurtenis-ID 4025: een fout die aangeeft dat een aanvraag is geblokkeerd, zodra de instelling op blokkeren staat.
Wie deze meldingen verzamelt, ziet welke apparaten, accounts en toepassingen nog afhankelijk zijn van het oude mechanisme.
Hoe past dit in de bredere NTLM-uitfasering?
Microsoft beschrijft een traject in drie stappen. Eerst komt uitgebreidere controle op NTLM-gebruik, die al beschikbaar is in Windows 11 24H2 en Windows Server 2025. Daarna volgen compatibiliteitsfuncties zoals IAKerb en Local KDC, waarmee Kerberos ook werkt zonder directe verbinding met een domeincontroller of voor lokale accounts. Uiteindelijk moet netwerk-NTLM in een toekomstige release standaard uitstaan. NTLM blijft dan wel in Windows aanwezig en kan via beleid weer worden ingeschakeld. Een exacte datum voor die laatste stap is niet bekend.
Wat raden wij aan?
Neem de volgende stappen om verrassingen te voorkomen:
- Controleer de logboeken op gebeurtenissen 4024 en 4025 en maak een overzicht van de afhankelijkheden.
- Test de waarde BlockNtlmv1SSO = 1 eerst op een kleine groep apparaten.
- Schakel Credential Guard in waar de hardware en het beleid dat toelaten.
- Vraag leveranciers van oudere software en apparatuur of zij Kerberos of modernere methoden ondersteunen.
Wat kun je hieruit meenemen?
In oktober 2026 wordt het blokkeren van NTLMv1-afgeleide inloggegevens de standaard in Windows 11 24H2 en later en in Windows Server 2025. De wijziging is vooral merkbaar bij single sign-on via MS-CHAPv2 op apparaten zonder Credential Guard, waar gebruikers soms handmatig moeten inloggen.
Beheerders kunnen de gevolgen vooraf in kaart brengen via de gebeurtenissen 4024 en 4025 en de instelling zo nodig tijdelijk aanpassen. Het is wel een eerste stap in een langer traject, waarin netwerk-NTLM op termijn standaard wordt uitgeschakeld.
Wie nu inventariseert, kan de overstap naar Kerberos in eigen tempo plannen. Wie wacht, merkt de gevolgen pas als gebruikers niet meer automatisch kunnen inloggen.
