Microsoft Defender for Endpoint ausschalten & Offboarding
Abschluss der MDE-Serie: MDE sauber ausschalten und Geräte offboarden – Offboarding-Skript aus dem Portal, 30-Tage-Gültigkeit, Wirkung auf Telemetrie und Datenaufbewahrung, der Unterschied zwischen Offboarding und dem Deaktivieren des Antivirus sowie Besonderheiten bei Servern.
Irgendwann muss ein Gerät wieder aus Microsoft Defender for Endpoint (MDE) heraus – etwa beim Ausmustern von Hardware, bei einem Wechsel des EDR-Anbieters oder wenn ein Testgerät nicht länger überwacht werden soll. Dafür gibt es einen klar definierten Weg: das Offboarding. Dabei ist wichtig zu verstehen, dass Offboarding etwas anderes ist als das bloße Deaktivieren des Virenschutzes. Dieser abschließende Teil der Serie zeigt den sauberen Weg, das Zusammenspiel mit dem Tamper Protection und was mit den Daten nach dem Offboarding passiert.
Sicherheitshinweis: Offboarding beendet die gesamte Telemetrie und den EDR-Schutz eines Geräts. Ab diesem Zeitpunkt werden keine neuen Erkennungen, Schwachstellen- oder Sicherheitsdaten mehr an das Portal gesendet. Das Gerät ist im Sinne des Security-Monitorings „blind". Offboarding sollte deshalb bewusst und nur für Geräte erfolgen, die tatsächlich nicht mehr überwacht werden müssen.
Offboarding vs. Antivirus deaktivieren
Diese beiden Vorgänge werden häufig verwechselt, haben aber völlig unterschiedliche Auswirkungen:
- Antivirus deaktivieren schaltet lediglich Teilfunktionen von Microsoft Defender Antivirus (MDAV) ab, zum Beispiel den Echtzeitschutz. Das Gerät bleibt dabei in MDE onboarded, der EDR-Sensor läuft weiter und sendet weiterhin Telemetrie an das Portal. Das ist kein Ausmustern, sondern höchstens ein temporärer Eingriff – etwa im Rahmen von Troubleshooting.
- Offboarding entfernt das Gerät vollständig aus MDE. Der Sensor stellt die Datenübermittlung ein, EDR und Defender Vulnerability Management liefern keine neuen Daten mehr.
Für reines Troubleshooting ist keiner dieser Wege der erste Griff. Microsoft stellt dafür den Troubleshooting Mode bereit, der bestimmte Schutzfunktionen temporär und kontrolliert (inklusive automatischer Rückkehr in den geschützten Zustand) aufhebt, ohne das Gerät zu offboarden oder die Tamper Protection dauerhaft zu schwächen.

Der Troubleshooting Mode lässt sich direkt über das Security Center für ein Gerät aktivieren.
Echtzeitschutz manuell abschalten
Zum reinen Deaktivieren des Echtzeitschutzes von MDAV – ohne Offboarding – dient auf einem einzelnen Gerät:
Set-MpPreference -DisableRealtimeMonitoring $true
Den Status prüft man anschließend mit:
Get-MpPreference | Select-Object DisableRealtimeMonitoring
Ist die Tamper Protection aktiv – und das sollte sie in produktiven Umgebungen sein –, wird ein solcher Eingriff blockiert bzw. wieder zurückgesetzt. Das ist gewolltes Verhalten: Genau davor schützt Tamper Protection. Ein dauerhaftes, sauberes Entfernen läuft daher über das Offboarding, nicht über das Aushebeln von Schutzmechanismen.

Bei aktiver Tamper Protection müssen für eine Deaktivierung gezielt zwei Werte in der Registry gesetzt werden.
Das Offboarding-Skript aus dem Portal
Das Offboarding startet immer mit einem gerätespezifischen Offboarding-Paket, das direkt aus dem Microsoft Defender-Portal heruntergeladen wird. Dieses Paket enthält ein signiertes Skript bzw. eine Konfigurationsdatei, die den Sensor auf dem Gerät abmeldet.
Vorgehen im Portal (security.microsoft.com):
- In der Navigation Settings → Endpoints → Device management → Offboarding öffnen.
- Das passende Betriebssystem auswählen (Windows Client, Windows Server, macOS, Linux).
- Unter Deployment method die Verteilmethode wählen – z. B. Local Script, Group Policy, Mobile Device Management / Intune oder Configuration Manager.
- Mit Download package die
.zip-Datei speichern und den Inhalt an einem geschützten Ort entpacken.
Der Dateiname enthält bereits das Ablaufdatum, z. B. WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd.
Ausführung per lokalem Skript
Auf einem einzelnen Windows-Gerät wird das entpackte Skript in einer Eingabeaufforderung mit Administratorrechten ausgeführt:
%userprofile%\Desktop\WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd
Für größere Umgebungen verteilt man das Paket stattdessen per Group Policy, Intune oder Configuration Manager.
Wichtig: Onboarding- und Offboarding-Richtlinien dürfen niemals gleichzeitig auf dasselbe Gerät angewendet werden. Sonst kommt es zu unvorhersehbaren Kollisionen, weil sich das Gerät gleichzeitig an- und abmelden soll.
Gültigkeit des Offboarding-Pakets: 30 Tage
Aus Sicherheitsgründen ist das Offboarding-Paket zeitlich begrenzt gültig. Ein per Local Script, Intune / MDM oder Configuration Manager heruntergeladenes Paket läuft 30 Tage nach dem Download ab. Danach werden abgelaufene Pakete vom Gerät abgelehnt – man muss dann ein frisches Paket aus dem Portal ziehen.
Achtung, häufige Stolperfalle: Bei der Verteilung per Group Policy und in einigen Configuration-Manager-Szenarien beträgt die Gültigkeit nur 7 Tage statt 30. Das Ablaufdatum steht immer im Dateinamen (
_valid_until_YYYY-MM-DD) – vor der Verteilung also unbedingt prüfen, ob das Paket noch gültig ist.
Wirkung des Offboardings
Nach erfolgreichem Offboarding ändert sich der Gerätestatus schrittweise:
- Sofort: Das Gerät stellt die Übermittlung von Sensordaten an das Portal ein. Es werden keine neuen Erkennungen, Schwachstellen- oder Sicherheitsdaten mehr erfasst.
- Nach 7 Tagen: Der Status des Geräts wechselt im Portal auf Inactive.
- Nach 30 Tagen: Das Gerät fließt nicht mehr in den Exposure Score der Organisation ein; die letzte Schwachstellen-Momentaufnahme in Defender Vulnerability Management wird nicht mehr angezeigt.
Wichtig ist der Unterschied zwischen „Daten fließen nicht mehr" und „Daten sind weg": Vorhandene Alerts, Schwachstellen und die Device-Timeline bleiben im Portal bis zum Ende der konfigurierten Aufbewahrungsfrist sichtbar. Das Geräteprofil (ohne neue Daten) erscheint noch bis zu 180 Tage im Device Inventory. Defender for Endpoint hält Daten inaktiver Geräte darüber hinaus für Compliance- und Forensikzwecke vor.
Praxis-Tipp: Um im Portal nur aktive Geräte zu sehen, kann man nach Sensor Health State, Device Tags oder Device Groups filtern, statt offboardete Einträge manuell zu suchen.
Besonderheiten bei Servern
Für Server gelten dieselben Grundprinzipien, aber ein paar Details weichen ab:
- Windows Server (ab Windows Server 2012 R2) sowie Azure Stack HCI OS 23H2 und neuer werden über den gleichen Offboarding-Prozess wie Clients aus dem Portal offboarded – man wählt lediglich das entsprechende Server-Betriebssystem aus.
- Ältere Server, die noch den Microsoft Monitoring Agent (MMA) nutzen, benötigen je nach Anbindung ein passendes Offboarding-Paket; über die Server-Auswahl im Portal wird der MMA bei Bedarf mit abgemeldet.
- Linux-Server haben einen eigenen Weg: Hier läuft das Offboarding über ein Python-Skript oder eine
mdatp_offboard.json-Datei, die nach/etc/opt/microsoft/mdatp/kopiert wird. Das eigentliche Deinstallieren desmdatp-Pakets ist ein separater Schritt.
Für Server, die über Microsoft Defender for Servers (Defender for Cloud) angebunden sind, sollte das Offboarding im Einklang mit der Defender-for-Cloud-Konfiguration erfolgen – sonst kann eine automatische Bereitstellung den Sensor erneut ausrollen.
Zusammenfassung
- Offboarding ist der offizielle, saubere Weg, ein Gerät aus MDE zu entfernen – nicht das Deaktivieren des Antivirus.
- Das Offboarding-Paket kommt aus dem Portal, ist gerätespezifisch und 30 Tage gültig (bei GPO teils nur 7 Tage).
- Nach dem Offboarding endet die Telemetrie sofort; der Status wird nach 7 Tagen inaktiv, nach 30 Tagen fällt das Gerät aus dem Exposure Score.
- Bestehende Daten bleiben bis zum Ablauf der Aufbewahrungsfrist sichtbar, das Geräteprofil bis zu 180 Tage.
- Onboarding und Offboarding nie gleichzeitig auf dasselbe Gerät anwenden.
Damit ist die MDE-Serie abgeschlossen.
Quellen
Dieser Artikel dokumentiert den Stand zum Veröffentlichungsdatum. Microsoft-Produkte ändern sich schnell – prüfe vor der Umsetzung die verlinkten Original-Quellen. Umsetzung auf eigene Verantwortung; im Zweifel in einer Testumgebung validieren.