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

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

Hier lesen Sie, warum Microsoft das tut, was die beiden Nachfolger tatsächlich leisten, warum Mobilgeräte aussen vor bleiben und wie Sie die Lücke schliessen.

Warum Microsoft NTLM jetzt endgültig abschaltet

Im März 2025 patchte Microsoft CVE-2025-24054, eine NTLM-Hash-Disclosure-Schwachstelle. Um Anmeldedaten abzugreifen, genügte ein Rechtsklick des Benutzers auf eine präparierte .library-ms-Datei, und Check Point dokumentierte innert weniger Tage aktive Angriffe auf Behörden in Polen und Rumänien. Bis April 2026 hatte Cymulate einen Bypass (CVE-2025-50154); bis Juni 2026 einen zweiten (CVE-2025-59214). Zweimal gepatcht, weiterhin ausnutzbar, ohne jede Benutzerinteraktion.

Genau diese Kette ist der Grund, warum Microsoft aufgehört hat, NTLM-Lücken einzeln zu stopfen. Im Januar 2026 veröffentlichte Microsoft den Plan, NTLM unter Windows standardmässig zu deaktivieren und das Protokoll schliesslich ganz aus dem Betriebssystem zu entfernen.

Wie die Abschaltung abläuft

Der Übergang erfolgt in drei Phasen.

• Phase 1, jetzt: Erweitertes NTLM-Auditing unter 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 Hälfte 2026: IAKerb und LocalKDC erreichen allgemeine Verfügbarkeit. Separat davon springt im Oktober 2026 der Standardwert von BlockNTLMv1SSO von Audit auf Enforce (KB5066470) und blockiert NTLMv1-Single-Sign-on. NTLMv1, die ältere DES-basierte Variante, ist trivial zu knacken und fällt zuerst weg; NTLMv2 folgt auf dem breiteren Phase-3-Pfad. Oktober 2026 ist die nächstgelegene harte Frist.
• Phase 3, nächstes Windows Server LTSC (voraussichtlich 2027): Netzwerk-NTLM standardmässig deaktiviert. Es bleibt per Gruppenrichtlinie reaktivierbar, aber der automatische Fallback ist weg.

Abbildung 1: Microsofts dreiphasiger Zeitplan zur NTLM-Abschaltung. Oktober 2026 ist das erste Datum, das in den meisten Umgebungen Handlung erfordert.

Was IAKerb und LocalKDC tatsächlich leisten

Kerberos hatte schon immer eine strukturelle Voraussetzung: Der Client braucht eine direkte Verbindung zu einem Key Distribution Center (KDC) auf Port 88. Wenn er keines erreichte, sei es eine entfernte Maschine, ein segmentiertes Netz oder ein Workgroup-Rechner, fiel Windows still auf NTLM zurück. IAKerb und LocalKDC beseitigen die zwei wichtigsten Gründe, warum es diesen Fallback überhaupt gab.

IAKerb erlaubt, den Kerberos-Austausch selbst zu proxien. Wenn ein Windows-11-24H2-Client keinen Domain Controller direkt erreicht, leitet er seinen AS-REQ über einen IAKerb-fähigen Server, der das kann, sodass der Client eine normale Kerberos-Authentifizierung abschliesst, statt auf NTLM zurückzufallen. Umgesetzt ist das im Negotiate- und Kerberos-Security-Support-Provider in LSASS; on-premises braucht es dafür einen Windows Server 2025 mit der KDC-Proxy-Rolle auf dem Pfad (Entra-joined Geräte können den Azure-KDC-Proxy nutzen). Für die Anwendung ist es durchgehend Kerberos.

LocalKDC legt eine kleine Kerberos-Instanz auf dem Windows-Gerät selbst ab, sodass selbst lokale, nicht domänengebundene Konten per Kerberos gegen die lokale SAM authentifizieren. Das beseitigt die langjährige Annahme, lokale Authentifizierung müsse zwangsläufig NTLM bedeuten.

Beides sind echte Verbesserungen. Beides ist auch ausschliesslich Windows.

Warum davon nichts die Mobilgeräte erreicht

IAKerb und LocalKDC sind Funktionen des Windows-Authentifizierungs-Stacks. Sie verändern, wie Windows die Authentifizierung innerhalb von LSASS und dem SSP-Modell aushandelt. Android und iOS haben weder das eine noch das andere. Sie waren an dieser Aushandlung von vornherein nie beteiligt.

Auf Mobilgeräten authentifiziert ein Browser oder eine App auf der Anwendungsebene, direkt gegen den Endpunkt, mit dem Verfahren, das der Server anbietet. Für On-Premises-Ressourcen mit Active-Directory-Anbindung war dieses Verfahren sehr oft NTLM, gerade weil Mobilplattformen keine eingebaute Kerberos-Maschinerie haben, wie sie ein domänengebundener Windows-PC mitbringt. In der Praxis war NTLM der Integrationsweg, der Mobilgeräte überhaupt gegen On-Prem funktionieren liess.

Wird NTLM also serverseitig blockiert, laufen die beiden Plattformen vollständig auseinander. Ein Windows-11-Client wechselt transparent zu IAKerb oder LocalKDC. Ein Android- oder iOS-Gerät hat nichts, wohin es wechseln könnte. Es scheitert schlicht: Interne Web-Apps liefern 401, SMB-Freigaben lassen sich nicht mehr einbinden, On-Premises-SharePoint landet in einer Authentifizierungsschleife, die nie abschliesst.

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

Die Erkenntnis von der Windows-Seite lautet: Kerberos ist das Ziel. Für Mobilgeräte bringt Microsofts Plan Sie nicht dorthin. Diese Kerberos-Fähigkeit müssen Sie selbst bereitstellen, und Sie sollten die Strategie dafür bereithaben, bevor die Fristen greifen.

Kerberos auf Android und iOS bringen

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

PKINIT ist zertifikatbasierte Kerberos-Vorauthentifizierung. Ein Benutzerzertifikat, über das SCEP- oder PKCS-Profil Ihres MDM ausgerollt, dient dazu, vom Domain Controller ein Kerberos-TGT zu beziehen; der Client auf dem Gerät stellt dann Service-Tickets für Browser, verwaltete WebViews und Branchenanwendungen aus. NTLM kommt in dieser Kette nirgends vor. Auf verwalteten Android- und iOS-Geräten ist Hypergate Authenticator die Umsetzung genau dieses Ablaufs, und derselbe Ansatz liegt unseren Anleitungen zu einem Kerberos-Proxy für Android Enterprise und SSO unter Android zugrunde.

Das Entscheidende ist die Folge daraus: Ein Gerät, das sich so authentifiziert, nutzt bereits Kerberos. NTLM serverseitig zu blockieren hat keine Wirkung darauf, weil kein Fallback mehr übrig ist, den man entfernen könnte.

Zertifikatbasierte Authentifizierung ist zugleich das Sicherheits-Upgrade

Mobilgeräte auf PKINIT umzustellen geht nicht nur darum, den Betrieb am Laufen zu halten. Zertifikatbasierte Authentifizierung ist ein Sicherheitsfortschritt. Das Zertifikat ist an Benutzer und Gerät gebunden, und es gibt kein gemeinsames Geheimnis und keinen Hash, den man weiterleiten oder wiederholen könnte, also genau die Angriffsklasse, die die NTLM-CVEs am Anfang dieses Beitrags ausnutzen.

Das ist kein Neuland. Banken und andere Hochsicherheitsumgebungen setzen zertifikatbasierte Authentifizierung seit Jahren ein. Neu ist, dass NTLMs Wegfall in Kombination mit Microsofts Strong Certificate Mapping Enforcement sie zum Standard weit über diese Branchen hinaus macht.

Eine Voraussetzung muss stimmen: Das PKINIT-Zertifikat muss die AD-Benutzer-SID 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 ab, die das nicht tun. Wenn Sie mobiles Kerberos jetzt aufsetzen, fällt diese Mapping-Arbeit auf dieselbe MDM-Konfiguration. Die genaue SAN-Einrichtung pro MDM haben wir in einem separaten Beitrag behandelt.

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

Mobilen NTLM-Verkehr sehen Sie auf der Serverseite. Event 8003 (oder 4022 unter Windows Server 2025) auf Ihren Applikationsservern protokolliert eingehende NTLM-Authentifizierungen, inklusive 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-Hinweis: Hinter einem VPN erscheint der Client möglicherweise als VPN-Konzentrator, korrelieren Sie daher über das Benutzerkonto.) Sobald ein Gerät migriert ist, sehen Sie Event 4768 (Kerberos-TGT ausgestellt), wo zuvor 4776 (NTLM-Validierung) stand. So bestätigen Sie, dass es kein NTLM mehr nutzt.

Wo Sie damit stehen

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

---