Microsoft Defender for Endpoint: neue Zero-Trust-Features

Warum dein Endpunkt jetzt beweisen muss, dass er sauber ist – und warum das dein NIS2-Aktenordner dankbar zur Kenntnis nimmt

Executive Summary

Kurzfassung für alle, die gleich in den nächsten Termin müssen: Defender for Endpoint ist vom klassischen Virenscanner endgültig zum Beweismittelproduzenten geworden. Die spannende Neuerung liegt nicht in einer einzelnen Funktion, sondern in der Kette. Der Endpunkt liefert ein Risikosignal, Intune übersetzt es in einen Compliance-Status, Entra ID verweigert daraufhin den Zugriff. Genau diese Kette ist das, was Zero Trust in der Praxis bedeutet: nicht ein Produkt, sondern eine Entscheidung, die an fünf Stellen richtig konfiguriert sein muss.

Der regulatorische Druck kommt praktischerweise gleich mit. Das NIS2-Umsetzungsgesetz ist seit dem 6. Dezember 2025 in Kraft, und zwar ohne Übergangsfrist. Rund 29.500 Unternehmen in Deutschland stehen damit in der Pflicht, die zehn Maßnahmenbereiche aus § 30 Absatz 2 BSIG umzusetzen. Betreiber kritischer Anlagen müssen dem BSI die Umsetzung alle drei Jahre nachweisen. Wer bisher darauf gewartet hat, dass irgendjemand die Frist noch einmal verschiebt: Das Warten ist vorbei, du bist schon mittendrin.

Die gute Nachricht: Du musst nichts kaufen, was du nicht ohnehin schon hast. Wenn Defender for Endpoint Plan 2 und Intune im Haus sind, liegt der größte Teil der Bausteine bereits herum. Die schlechte Nachricht: Herumliegen ist nicht dasselbe wie wirken. Ich habe in den letzten Monaten mehr Mandanten gesehen, in denen die Kette an genau einer Stelle unterbrochen war, als solche, in denen sie durchgängig funktioniert hat.

Worum geht es im Detail?

Zero Trust ruht auf drei Prinzipien: explizit verifizieren, minimale Rechte vergeben, vom Ernstfall ausgehen. Defender for Endpoint bedient vor allem das dritte Prinzip, also Assume Breach. Die Annahme lautet: Irgendwo in deinem Netz sitzt bereits jemand, den du nicht eingeladen hast. Die Frage ist nur, wie schnell du es merkst und wie wenig er anrichten kann, bevor du reagierst.

Technisch besteht das Ganze aus drei Schichten. Erstens den Verhaltenssensoren, die direkt in Windows 10 und 11 eingebaut sind und Signale aus dem Betriebssystem an deine isolierte Cloud-Instanz schicken. Zweitens der Cloud-Analytik, die aus diesen Signalen Erkennungen und Handlungsempfehlungen macht. Drittens der Threat Intelligence, die Angreiferwerkzeuge und -techniken erkennt. Darauf setzen die Bausteine auf, die du im Portal siehst: Vulnerability Management, Angriffsflächenreduzierung, Next-Generation Protection, EDR mit Advanced Hunting, automatisierte Untersuchung und der Secure Score for Devices.

Abbildung 1: Die Signalkette vom Endpunkt bis zur Zugriffsentscheidung – inklusive der Stufe, auf der die meisten Projekte scheitern.

Der eigentliche Zero-Trust-Trick passiert an der Nahtstelle zu Intune und Entra ID. Du schaltest im Defender-Portal unter System, Einstellungen, Endpoints die Intune-Verbindung ein. Im Intune Admin Center aktivierst du unter Endpoint Security die Compliance-Policy-Auswertung. Dann baust du eine Windows-10/11-Compliance-Policy, in der du die Einstellung „Require the device to be at or under the Device Threat Level“ setzt. Und schließlich legst du in Entra ID eine Conditional-Access-Richtlinie an, die „Require device to be marked as compliant“ verlangt. Vier Handgriffe in drei Portalen, und dein Endpunkt hat plötzlich ein Mitspracherecht darüber, ob sein Benutzer an die Daten kommt.

Die vier Stufen des Device Threat Level sind dabei die entscheidende Stellschraube. „Clear“ heißt: keinerlei Fund, sonst ist das Gerät nicht konform. „Low“ erlaubt niedrigstufige Funde, „Medium“ auch mittlere. Und „High“ erlaubt schlicht alles – das Gerät gilt selbst dann als konform, wenn Defender gerade Alarm schlägt. Ich habe mehr als einen Mandanten gesehen, der stolz auf 100 Prozent Compliance war, weil jemand vor zwei Jahren „High“ eingestellt hatte, um die Ticketflut zu stoppen. Das ist Compliance-Theater mit sehr guter Beleuchtung.

Beim Thema Baselines wird es unangenehm konkret. Es gibt zwei davon, und beide willst du haben. Die Windows-Intune-Security-Baseline härtet das Betriebssystem inklusive Browser- und PowerShell-Einstellungen. Die Defender-for-Endpoint-Baseline legt sich darüber und optimiert die Sicherheitskontrollen des Defender-Stacks selbst, inklusive der EDR-Einstellungen. Microsoft empfiehlt ausdrücklich, beide zu deployen und immer die aktuellste Version zu nutzen, weil sich sonst Konflikte zwischen den Baseline-Generationen aufbauen. Der Status pro Gerät ist dann einer von vier: passt zur Baseline, passt nicht, fehlkonfiguriert oder nicht anwendbar.

Der Punkt „fehlkonfiguriert“ ist der, den in der Praxis alle übersehen. Er bedeutet, dass eine Einstellung im Konflikt, im Fehler oder im Pending-Status hängt. Ein Gerät in diesem Zustand ist weder sauber noch offensichtlich kaputt – es sitzt im Wartezimmer. Und weil das Dashboard vier Zustände zeigt, aber die meisten Verantwortlichen nur zwei lesen, wandern diese Geräte gerne monatelang mit.

Neu und durchaus bemerkenswert ist die automatische Angriffsunterbrechung. Defender kann ein Gerät, das er für kompromittiert hält, selbstständig isolieren. Microsoft hat das im Mai 2026 veröffentlicht, es ist als Prerelease-Funktionalität zu behandeln und kann sich noch ändern. Das isolierte Gerät wird vom normalen Netz getrennt, kann aber weiterhin mit Defender for Endpoint kommunizieren. Ergänzend gibt es die Benutzer-Eindämmung: Defender verteilt eine Containment-Richtlinie auf alle onboarded Geräte und blockiert damit die Kommunikation des kompromittierten Kontos – Authentifizierung, Dateisystemzugriff und Netzwerkpfade. Gesteuert wird das über das Automatisierungslevel pro Gerätegruppe.

Und dann ist da noch das Zero Trust Assessment. Am 4. August 2026 hat Microsoft es um Bewertungskriterien für KI, Security Operations und Infrastruktur erweitert und dem zugehörigen Zero Trust Workshop einen kompletten DevSecOps-Bereich spendiert: 15 Kontrollgruppen und 91 Aufgaben, vom Quellcode bis zum Cloud-Deployment. Das Assessment wertet automatisiert deine Mandantenkonfiguration und Aktivitätssignale aus und zeigt dir unter anderem Intune-Compliance-Richtlinien, Defender-for-Endpoint-Abdeckung und dein Inventar unverwalteter Geräte. Genau die Zahl also, die du für den NIS2-Nachweis ohnehin brauchst.

Abbildung 2: Welcher Baustein welchen Maßnahmenbereich aus § 30 Absatz 2 BSIG mit Nachweisen füttert. Vier weiße Punkte in einer Zeile sind keine Lücke im Produkt, sondern eine Hausaufgabe für dich.

Was sind Chancen? Was sind Risiken?

Die größte Chance ist banal und wird trotzdem systematisch unterschätzt: Du bekommst deine Nachweise auf Knopfdruck. § 30 Absatz 2 Nummer 6 BSIG verlangt Konzepte zur Bewertung der Wirksamkeit deiner Risikomanagementmaßnahmen. Bisher hieß das für die meisten: einmal im Jahr ein Word-Dokument aufhübschen, in dem steht, dass man Virenschutz einsetzt. Mit Baseline-Compliance, Secure Score for Devices und dem Zero Trust Assessment hast du dagegen eine messbare, wiederholbare Größe. Das ist der Unterschied zwischen einer Behauptung und einem Beleg – und Prüfer mögen Belege deutlich lieber.

Die zweite Chance liegt in der Geschwindigkeit. Automatisierte Untersuchung und Behebung reduzieren das Alarmvolumen in Minuten statt in Schichten. Für Häuser ohne 24/7-SOC ist das kein Komfortgewinn, sondern der Unterschied zwischen einem isolierten Vorfall und einem Meldeereignis. Und wenn du meldepflichtig wirst, läuft die Uhr gnadenlos: 24 Stunden Frühwarnung, 72 Stunden Bericht, ein Monat Abschluss. Wer sich in den ersten 24 Stunden noch fragt, welche Geräte überhaupt betroffen sind, hat den Termin schon verloren.

Nun zu den Risiken, und da wird es interessant. Das häufigste Problem ist der vergessene Report-only-Modus. Microsofts eigene Anleitung empfiehlt zu Recht, jede Conditional-Access-Richtlinie erst im Report-only zu starten und die Wirkung zu prüfen, bevor du sie scharf schaltest. Nur passiert danach oft nichts mehr. Ich hatte einen Mandanten aus dem Maschinenbau, bei dem die Richtlinie exakt siebzehn Monate im Report-only stand. Im Audit sah alles hervorragend aus. Blockiert wurde nie ein einziger Zugriff. Das ist der elegante Weg, sich selbst zu betrügen, ohne dabei zu lügen.

Risiko Nummer zwei ist die automatische Geräteisolation in Umgebungen, in denen ein isoliertes Gerät physische Konsequenzen hat. Ein Stadtwerk, mit dem ich gearbeitet habe, war kurz davor, das Automatisierungslevel für alle Gerätegruppen gleichzeitig hochzudrehen – inklusive der Leitwarten-Arbeitsplätze. Die Frage „Was passiert eigentlich, wenn Defender sich um drei Uhr nachts irrt und der Schichtführer den Netzleitrechner nicht mehr erreicht?“ hat die Diskussion dann sehr schnell in eine produktive Richtung gedreht. Gerätegruppen existieren genau für diesen Zweck. Nutze sie.

Das dritte Risiko ist organisatorisch und deshalb das zäheste. Die Kette geht durch drei Portale und typischerweise durch zwei bis drei Teams: Client-Management macht Intune, Identity macht Entra ID, Security macht Defender. Jeder ist für sein Stück verantwortlich, niemand für das Ganze. Bei einer Klinik habe ich erlebt, dass die Compliance-Policy sauber stand, die Conditional-Access-Regel sauber stand – nur hatte vor Monaten jemand im Defender-Portal den Intune-Connector abgeschaltet, weil er bei einer Fehlersuche störte. Zwischen den beiden sauberen Enden lag ein Kabel, das niemandem gehörte.

Was müssen wir jetzt schon vorbereiten?

Fangen wir mit dem an, was du diese Woche tun kannst, ohne jemanden um Budget zu bitten. Lass das Zero Trust Assessment laufen und schau dir vor allem eine Zahl an: das Inventar der unverwalteten Geräte. Diese Zahl ist erfahrungsgemäß der ehrlichste Indikator für den Zustand einer Umgebung, weil sie nichts beschönigt. Alles, was dort auftaucht, ist ein Gerät, über das deine Zero-Trust-Kette keine Aussage treffen kann – und über das du folglich auch dem BSI nichts erzählen kannst.

Abbildung 3: Die regulatorischen Fixpunkte. Beachte insbesondere den fehlenden Übergangszeitraum – das ist keine Panikmache, das ist einfach das Datum.

Danach arbeitest du die Kette von hinten nach vorne ab:

Verbindungen prüfen: Ist die Intune-Verbindung im Defender-Portal wirklich noch auf „On“? Und ist im Intune Admin Center die Compliance-Policy-Auswertung für Windows-Geräte aktiviert? Beides sind Schalter, die jemand aus guten Gründen umgelegt und aus schlechten Gründen nicht zurückgestellt hat.

Device Threat Level ehrlich setzen: Prüfe, auf welcher Stufe deine Compliance-Policies stehen. Steht irgendwo „High“, dann hast du dort keine Kontrolle, sondern eine Dekoration. Der pragmatische Weg führt über „Low“ für Standard-Clients und einen begründeten Ausnahmering für Spezialgeräte.

Report-only beenden: Geh jede Conditional-Access-Richtlinie durch und notiere, seit wann sie im Report-only steht. Alles, was älter als ein Quartal ist, braucht entweder ein Datum für die Scharfschaltung oder eine Begründung, die ein Prüfer akzeptiert.

Break-Glass sauber ausnehmen: Notfallkonten und Verzeichnissynchronisierungskonten explizit ausschließen. Danach den Notfallzugang einmal testen, und zwar mit einer Person, die nicht die Richtlinie gebaut hat.

Baselines in Ringen ausrollen: Erst die Windows-Baseline, dann die Defender-Baseline darüber. Ring 1 mit der IT, Ring 2 mit einer gutmütigen Fachabteilung, Ring 3 mit dem Rest. VDI und virtuelle Maschinen bekommen eine eigene Behandlung.

Automatisierungslevel differenzieren: Gerätegruppen bilden und das Automatisierungslevel gestaffelt setzen. Büro-Clients dürfen aggressiv sein, Produktions- und Leitstandsysteme brauchen den menschlichen Zwischenschritt.

Nachweise archivieren: Monatlicher Export von Baseline-Compliance, Secure Score for Devices und Assessment-Ergebnis in einen unveränderlichen Ablageort. Ein Screenshot vom Tag der Prüfung beweist nichts über die zwei Jahre davor.

Ein Wort zur Zuständigkeit, weil es der Punkt ist, an dem die meiste Zeit verbrannt wird: Benenne eine Person, der die Kette als Ganzes gehört. Nicht ein Gremium, nicht ein Prozess, eine Person mit Namen. Diese Person muss nicht alle drei Portale bedienen können, aber sie muss einmal im Monat durchklicken und feststellen, ob das Signal vom Endpunkt tatsächlich bis zur Zugriffsentscheidung durchkommt. Ein Testgerät, ein bewusst provozierter Fund, ein blockierter Zugriff. Fünfzehn Minuten. Und du weißt, ob dein Kontrollsystem lebt oder nur gut aussieht.

Zum Schluss die Erwartungshaltung geraderücken: Zero Trust ist kein Projekt mit Abschlussbericht. Es ist ein Betriebszustand, in dem jede Zugriffsentscheidung auf aktuellen Signalen beruht. Defender for Endpoint liefert dir dafür die Endpunktsignale in einer Qualität, die vor fünf Jahren undenkbar war. Ob daraus eine Kontrolle wird oder nur ein weiteres Dashboard, entscheidet sich nicht im Produkt. Es entscheidet sich in den vier Handgriffen, die du entweder gemacht hast oder eben nicht.

Häufig gestellte Fragen

Brauche ich zwingend Intune, damit Defender for Endpoint Zugriffe blockieren kann?

Für das Zusammenspiel aus Geräterisiko und Conditional Access ja. Der Risikowert aus Defender for Endpoint wird über eine Intune-Compliance-Richtlinie ausgewertet, und Entra ID entscheidet anschließend anhand des Compliance-Status. Rein Entra-registrierte Geräte ohne Intune-Einschreibung werden in diesem Szenario nicht unterstützt.

Was bedeutet der Status „fehlkonfiguriert“ bei der Security Baseline?

Er bedeutet, dass mindestens eine Baseline-Einstellung auf dem Gerät nicht korrekt greift, weil sie im Konflikt mit einer anderen Richtlinie steht, einen Fehler geworfen hat oder noch aussteht. Solche Geräte sind weder konform noch eindeutig defekt und werden deshalb gerne übersehen – sie gehören zuerst auf die Abarbeitungsliste.

Reicht ein aktivierter Defender aus, um die NIS2-Anforderungen zu erfüllen?

Nein. § 30 Absatz 2 BSIG nennt zehn Maßnahmenbereiche, von der Risikoanalyse über Lieferkettensicherheit und Kryptografie bis zur Multi-Faktor-Authentifizierung. Defender for Endpoint deckt einen relevanten Teil davon ab und liefert vor allem Nachweise, ersetzt aber weder das Risikomanagement noch die organisatorischen Konzepte.

Ist die automatische Isolation kompromittierter Geräte gefährlich für den Betrieb?

Sie kann es sein, wenn du sie undifferenziert auf alle Systeme anwendest. Das Automatisierungslevel lässt sich pro Gerätegruppe steuern, deshalb solltest du produktionsnahe oder sicherheitskritische Systeme in eigene Gruppen legen und dort einen manuellen Freigabeschritt behalten. Die Funktion ist zudem als Prerelease eingestuft und kann sich noch ändern.

Wie oft muss ich die Umsetzung gegenüber dem BSI nachweisen?

Betreiber kritischer Anlagen weisen die Umsetzung ihrer Maßnahmen alle drei Jahre durch entsprechende Prüfungen nach. Unabhängig davon gelten die Meldefristen bei erheblichen Sicherheitsvorfällen: 24 Stunden Frühwarnung, 72 Stunden Meldung und ein Monat bis zum Abschlussbericht.