Microsoft treibt die NTLM-Ablösung voran und priorisiert Kerberos mit einem Drei-Phasen-Plan

Microsoft setzt die seit Jahren erwartete Ablösung von NTLM nun in eine konkrete Roadmap um. Nach aktuellen Berichten soll der Übergang kontrolliert erfolgen, damit Unternehmen Abhängigkeiten erkennen und Workloads ohne Brüche auf Kerberos umstellen können. Den Rahmen dafür beschreibt ein Drei-Phasen-Plan, wie The Hacker News unter Verweis auf Microsofts Tech-Community-Kommunikation zusammenfasst.

Bemerkenswert ist vor allem der strategische Ansatz. Microsoft koppelt die sicherheitliche Zielsetzung an eine Migrationslogik, die operative Realität anerkennt. NTLM ist in vielen Umgebungen nicht „aktiv entschieden“, sondern historisch als Fallback mitgelaufen. Genau diese implizite Verfügbarkeit macht es schwierig, Risiken sauber zu begrenzen, weil sich NTLM-Nutzung häufig in Randfällen versteckt, etwa bei älteren Applikationen, Geräten oder Integrationen, die Kerberos nicht zuverlässig verhandeln. Der Drei-Phasen-Plan adressiert das, indem er erst Sichtbarkeit und Ersatzwege priorisiert und erst danach die Standardkonfiguration verschärft.

Was der Drei-Phasen-Plan vorsieht

Das Zielbild ist eine Kerberos-First-Welt, in der NTLM nicht mehr automatisch als Fallback herangezogen wird. In der ersten Phase steht vor allem Sichtbarkeit im Vordergrund, damit Security- und Infrastruktur-Teams belastbar erkennen, wo NTLM tatsächlich noch im Einsatz ist und welche Systeme davon abhängen. Ergänzend soll Kerberos konsequenter priorisiert werden, damit unnötige NTLM-Nutzung aus dem Default-Pfad verschwindet. Praktisch heißt das, dass Unternehmen ihre Authentifizierungsflüsse messbar machen müssen, statt sie nur aus Erfahrung zu vermuten. Erst wenn klar ist, welche Clients, Dienste, Konten und Gegenstellen NTLM auslösen, lässt sich die Ablösung risikogesteuert planen.

Die zweite Phase ist für die zweite Jahreshälfte 2026 eingeordnet und benennt Mechanismen wie IAKerb und Local KDC als Bausteine, um typische Fallback-Szenarien zu entschärfen. Der Fokus liegt darauf, Kerberos in Situationen stabiler zu machen, in denen heute aus Kompatibilitätsgründen oft NTLM greift. Das ist für den Betrieb relevant, weil viele Störungen nicht durch „Kerberos an sich“ entstehen, sondern durch Umweltbedingungen wie Namensauflösung, Zeitabweichungen, fehlende oder falsche Service Principal Names und Sonderwege bei Identitäten. Details zur Einordnung dieser Schritte greifen unter anderem Petri auf, insbesondere mit Blick darauf, wie Microsoft Migration und Kompatibilität zusammendenkt.

In der dritten Phase soll NTLM in einer zukünftigen Windows-Server-Hauptversion und den zugehörigen Windows-Clients standardmäßig blockiert sein. Wichtig ist dabei die Unterscheidung zwischen Blockade im Default und kompletter Entfernung. Microsoft stellt laut aktueller Berichterstattung klar, dass ein Re-Enable über Richtlinien möglich bleiben soll, auch wenn das als Ausnahmeweg gedacht ist. Darauf weist heise security hin und betont zugleich, dass weiterhin kein endgültiges Datum für die finale Umstellung genannt wird. Für Unternehmen wird damit Governance zentral, weil jede Ausnahme künftig bewusster begründet und kontrolliert werden muss.

Warum Microsoft NTLM Ablösung vorantreibt

NTLM steht seit Langem im Fokus, weil es in modernen Angriffsketten wiederholt als Hebel für Credential-Abuse und laterale Bewegung missbraucht wird. Genannt werden in der aktuellen Sekundärberichterstattung insbesondere Relay-, Replay- und Pass-the-Hash-Szenarien. Kerberos gilt in Domänenumgebungen als robusterer Standard, doch NTLM bleibt vielerorts als Fallback aktiv. Genau diese Restnutzung will Microsoft systematisch reduzieren, bevor eine Default-Blockade realistisch und betrieblich vertretbar ist. Die sicherheitliche Wirkung entsteht dabei weniger durch den reinen „Kerberos-Einsatz“, sondern durch das Abschneiden des automatischen Rückfallpfads, der Angreifern in heterogenen Netzen zusätzliche Optionen geben kann.

Wo es in der Praxis eng werden kann

Besonders betroffen sind Umgebungen, in denen NTLM nicht aus Bequemlichkeit, sondern aus technischen Gründen weiterlebt. Dazu zählen Legacy-Anwendungen mit fest verdrahteter Protokollwahl, Integrationen mit unvollständiger Kerberos-Unterstützung oder Szenarien, in denen lokale Konten und Sonderwege die Domänenauthentifizierung umgehen. Hinzu kommen oft technische Vorbedingungen, die Kerberos empfindlicher machen als NTLM, etwa inkonsistente DNS-Konfigurationen, Probleme mit SPNs oder Zeit-Synchronität. Die Roadmap adressiert solche Kantenfälle explizit über eine Übergangsphase, die Migration erleichtern soll, bevor der Default-Block greift.

Einordnung und nächste Schritte für Security und Betrieb

Der Schritt ist sicherheitstechnisch konsequent, weil er eine historisch angreifbare Oberfläche aus dem Standardpfad nimmt. Operativ entscheidet jedoch die Vorbereitung über den Erfolg. Wer jetzt NTLM-Nutzung sauber inventarisiert, Kerberos-First technisch durchsetzt und Ausnahmen bewusst dokumentiert, reduziert später den Migrationsdruck deutlich. Dass Microsoft die Umstellung als langfristige Hygiene-Aufgabe sieht, spiegelt auch die Einordnung in aktuellen Tech-Medien, etwa bei Windows Central, die den Schritt als Abkehr von einem Sicherheitsrelikt beschreibt.

Für die praktische Umsetzung lässt sich der Weg in wenige, robuste Arbeitspakete übersetzen, die Security und Betrieb gemeinsam tragen müssen.

• NTLM-Verwendung messbar machen und Verursacher eindeutig zuordnen, damit Abhängigkeiten nicht erst im Incident sichtbar werden.
• Kerberos-Stabilität erhöhen, insbesondere bei DNS, SPNs und Zeit-Synchronität, damit „Fallback aus Bequemlichkeit“ nicht durch „Fallback aus Not“ ersetzt wird.
• Legacy-Fälle priorisieren und mit Applikationsverantwortlichen Ablösepfade definieren, statt Ausnahmen dauerhaft zu akzeptieren.
• Ausnahmen über Policies streng steuern und zeitlich begrenzen, damit ein Re-Enable nicht zur neuen Standardpraxis wird.