NTLM deaktivieren: Was Microsofts Plan für Ihre Mobilgeräte bedeutet

Lukas Schönbächler · Juni 2026 · 8 Min. Lesezeit

Hier erfahren Sie, warum Microsoft dies tut, was die beiden Nachfolger tatsächlich leisten, warum Mobilgeräte aussen vor bleiben und wie sich die Lücke schliessen lässt.

Warum Microsoft NTLM endlich abschafft

Im März 2025 schloss Microsoft die Sicherheitslücke CVE-2025-24054, eine Schwachstelle, die zur Offenlegung von NTLM-Hashes führte. Um Anmeldedaten zu extrahieren, genügte es, wenn ein Benutzer mit der rechten Maustaste auf eine bösartige «.library-ms»-Datei klickte, und Check Point dokumentierte bereits innerhalb weniger Tage aktive Angriffe auf Regierungsziele in Polen und Rumänien. Bis April 2026 hatte Cymulate einen Umgehungsweg (CVE-2025-50154) gefunden; bis Juni 2026 einen zweiten (CVE-2025-59214). Zweimal gepatcht, dennoch ausnutzbar, ohne jegliche Benutzerinteraktion.

Diese Kette ist der Grund, warum Microsoft aufgehört hat, NTLM-Lücken einzeln zu stopfen. Im Januar 2026 veröffentlichte das Unternehmen seinen Plan, NTLM unter Windows standardmässig zu deaktivieren; langfristig verschwindet das Protokoll ganz aus dem Betriebssystem.

So läuft die Abschaltung ab

Der Übergang erfolgt in drei Phasen.

• Phase 1, jetzt: Erweitertes NTLM-Auditing auf Windows Server 2025 und Windows 11 24H2. Neue Event-IDs (4020 auf Clients, 4022 auf Servern, 4032 auf Domain Controllern) zeigen endlich, warum NTLM gewählt und welche Version ausgehandelt wurde. Das ist die Voraussetzung für alles Weitere: Was man nicht sieht, kann man nicht migrieren.
• Phase 2, zweite Jahreshälfte 2026: IAKerb und LocalKDC erreichen die allgemeine Verfügbarkeit. Unabhängig davon kippt im Oktober 2026 der Standardwert von BlockNTLMv1SSO von Audit auf Enforce (KB5066470) und blockiert damit NTLMv1-Single-Sign-On. NTLMv1, die ältere DES-basierte Variante, ist trivial zu knacken und stirbt zuerst; NTLMv2 folgt über den breiteren Phase-3-Pfad. Oktober 2026 ist die nächste harte Frist.
• Phase 3, nächstes Windows Server LTSC (voraussichtlich 2027): Netzwerk-NTLM ist standardmässig deaktiviert. Per Gruppenrichtlinie lässt es sich weiterhin einschalten, aber der automatische Fallback ist weg.

Abbildung 1: Microsofts dreiphasige NTLM-Abschaltung. Oktober 2026 ist der erste Termin, der in den meisten Umgebungen Handeln erfordert.

Was IAKerb und LocalKDC wirklich leisten

Kerberos hatte schon immer eine strukturelle Anforderung: Der Client braucht eine Verbindung zu einem Key Distribution Center (KDC) auf Port 88. Erreichte er keines, ob Remote-Rechner, segmentiertes Netzwerk oder Workgroup-Maschine, fiel Windows stillschweigend auf NTLM zurück. IAKerb und LocalKDC beseitigen die zwei grössten Gründe, aus denen dieser Fallback existierte.

IAKerb lässt den Kerberos-Austausch selbst proxyen. Erreicht ein Windows-11-24H2-Client keinen Domain Controller direkt, tunnelt er seinen AS-REQ über einen IAKerb-fähigen Server, der das kann. So schliesst der Client eine normale Kerberos-Authentifizierung ab, statt auf NTLM zu fallen. Implementiert ist das im Negotiate- und Kerberos-Security-Support-Provider in LSASS; on-premises braucht es einen Windows Server 2025 mit KDC-Proxy-Rolle auf dem Pfad (Entra-joined Geräte können den Azure-KDC-Proxy nutzen). Für die Anwendung ist es Kerberos von Ende zu Ende.

LocalKDC setzt eine kleine Kerberos-Instanz direkt auf das Windows-Gerät, sodass sich auch lokale Konten ohne Domäne per Kerberos gegen die lokale SAM authentifizieren. Damit fällt die alte Annahme, lokale Authentifizierung müsse NTLM bedeuten.

Beides sind echte Verbesserungen. Beides ist auch reines Windows.

Warum davon nichts auf Mobilgeräten ankommt

IAKerb und LocalKDC sind Funktionen des Windows-Authentifizierungsstacks. Sie ändern, wie Windows innerhalb von LSASS und dem SSP-Modell Authentifizierung aushandelt. Android und iOS haben beides nicht. Sie waren an dieser Aushandlung nie beteiligt.

Auf Mobilgeräten authentifiziert sich ein Browser oder eine App auf Anwendungsebene, direkt gegen den Endpunkt, mit dem Schema, das der Server anbietet. Für lokale, Active-Directory-gestützte Ressourcen war dieses Schema sehr oft NTLM, gerade weil mobile Plattformen keine eingebaute Kerberos-Maschinerie mitbringen wie ein domänengebundener Windows-PC. In der Praxis war NTLM der Integrationspfad, über den Mobilgeräte gegen On-Prem überhaupt funktionierten.

Wird NTLM serverseitig blockiert, laufen die zwei Plattformen also komplett auseinander. Ein Windows-11-Client wechselt transparent auf IAKerb oder LocalKDC. Ein Android- oder iOS-Gerät hat nichts, worauf es wechseln könnte. Es scheitert schlicht: Interne Web-Apps liefern 401, SMB-Freigaben lassen sich nicht mehr einbinden, lokales SharePoint hängt in einer Anmeldeschleife, die nie endet.

Abbildung 2: IAKerb deckt Windows-Clients ab, die keinen DC direkt erreichen. Android und iOS haben im Betriebssystem kein Äquivalent. Ohne dedizierten Kerberos-Client auf dem Gerät scheitern sie beim NTLM-Block oder brauchen eine Lösung auf Anwendungsebene.

Die Lehre aus der Windows-Seite: Kerberos ist das Ziel. Für Mobilgeräte bringt Sie nichts in Microsofts Plan dorthin. Diese Kerberos-Fähigkeit müssen Sie selbst bereitstellen, und die Strategie sollte stehen, bevor die Fristen greifen.

Kerberos auf Android und iOS bringen

Unter Windows besorgt LSASS die Tickets transparent. Auf Mobilgeräten gibt es keinen Kerberos-Client im Betriebssystem, die Fähigkeit muss also aus einer App kommen, die den Kerberos-Client und PKINIT direkt auf dem Gerät implementiert.

PKINIT ist zertifikatsbasierte Kerberos-Vorauthentifizierung. Ein Benutzerzertifikat, verteilt über das SCEP- oder PKCS-Profil Ihres MDM, holt beim Domain Controller ein Kerberos-TGT; der Client auf dem Gerät stellt anschliessend Service-Tickets für Browser, verwaltete WebViews und Fachanwendungen aus. NTLM kommt in dieser Kette nirgends vor. Auf verwaltetem Android und iOS ist Hypergate Authenticator die Implementierung genau dieses Ablaufs; derselbe Ansatz steckt hinter unseren Anleitungen zum Kerberos-Proxy für Android Enterprise und zu SSO auf Android.

Die Konsequenz ist der wichtige Teil: Ein Gerät, das sich so authentifiziert, ist bereits auf Kerberos. NTLM serverseitig zu blockieren hat darauf keinen Effekt, weil kein Fallback mehr übrig ist, den man entfernen könnte.

Zertifikatsbasierte Anmeldung ist zugleich das Sicherheits-Upgrade

Mobilgeräte auf PKINIT umzustellen heisst nicht nur, den Betrieb am Laufen zu halten. Zertifikatsbasierte Authentifizierung ist ein Sicherheitsfortschritt. Das Zertifikat ist an Benutzer und Gerät gebunden, und es gibt kein geteiltes Geheimnis und keinen Hash, den man relayen oder wiederverwenden könnte. Genau diese Angriffsklasse nutzen die NTLM-CVEs am Anfang dieses Beitrags aus.

Neu ist das nicht. Banken und andere Hochsicherheitsumgebungen fahren seit Jahren zertifikatsbasierte Authentifizierung. Was sich ändert: Die NTLM-Abschaltung macht sie zusammen mit Microsofts Strong Certificate Mapping Enforcement weit über diese Branchen hinaus zum Standard.

Eine Voraussetzung muss stimmen: Das PKINIT-Zertifikat muss die SID des AD-Benutzers im Subject Alternative Name tragen (tag:microsoft.com,2022-09-14:sid:<SID>). Strong Certificate Mapping Enforcement, seit September 2025 im strikten Modus, weist Zertifikate ohne diese Zuordnung ab. Wer mobiles Kerberos jetzt aufsetzt, erledigt die Zuordnung in derselben MDM-Konfiguration. Das genaue SAN-Setup pro MDM haben wir in einem eigenen Beitrag beschrieben.

Finden Sie Ihre mobilen NTLM-Abhängigkeiten, bevor Sie blockieren

Mobilen NTLM-Verkehr sehen Sie von der Serverseite aus. Event 8003 (oder 4022 auf Windows Server 2025) protokolliert auf Ihren Applikationsservern eingehende NTLM-Authentifizierungen, samt Konto und Quell-Client:

Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" |
    Where-Object { $_.Id -eq 8003 } |
    Select-Object TimeCreated,
        @{N='User';E={$_.Properties[0].Value}},
        @{N='Client';E={$_.Properties[2].Value}},
        @{N='Process';E={$_.Properties[3].Value}} |
    Sort-Object TimeCreated -Descending

Gleichen Sie das Feld Client mit Ihrem MDM-Inventar ab. (VPN-Vorbehalt: Hinter einem VPN erscheint als Client unter Umständen der Konzentrator, korrelieren Sie dann über das Benutzerkonto.) Ist ein Gerät migriert, sehen Sie Event 4768 (Kerberos-TGT ausgestellt), wo vorher 4776 (NTLM-Validierung) stand. So bestätigen Sie, dass es von NTLM weg ist.

Wo Sie damit stehen

Microsofts Plan deckt Windows gut ab. Die mobile Seite liegt bei Ihnen, und die Arbeit ist überschaubar, sobald der Verkehr sichtbar ist: mit Event 8003 auditieren, ein Zertifikat mit eingebetteter SID samt PKINIT über das MDM ausrollen, mit Event 4768 bestätigen, dann NTLM einschränken. Nichts davon braucht neue Infrastruktur; die eigentliche Grenze ist, früh genug anzufangen, um vor der Frist im Oktober 2026 alles zu validieren.

---