Consulting Briefing

09.05.2026 | boddenberg.de

Defender April-Update: Predictive Shielding und neue Secure-Score-Empfehlungen

Executive Summary

Microsoft hat im April-Update von Defender XDR zwei Dinge ausgeliefert, die du in deiner Roadmap nicht ignorieren darfst. Erstens: Predictive Shielding ist in der Public Preview angekommen und ergänzt die Auto-Attack-Disruption um proaktive Schutzaktionen, die Angriffspfade kappen, bevor der Angreifer überhaupt den nächsten Hop nimmt. Du siehst pro Incident jetzt direkt im Portal, welche Aktionen Defender autonom gefahren hat und in welchem Status sie stecken.

Zweitens: Im Microsoft Secure Score gibt es seit Ende April eine neue Empfehlung, die deine Flotte auf die Umstellung der Secure-Boot-2023-Zertifikate vorbereitet. Die alten 2011er-Zertifikate laufen ab Juni 2026 ab. Wer das verschläft, fliegt im Sommer mit Boot-Manager-Problemen und ohne Schutz vor neuen Boot-Level-Threats in die Sommerferien. Beides sind keine Spielereien für Security-Nerds, sondern Tickets, die du jetzt einplanen musst, sonst schreibt sie dir später der Auditor in den Bericht.

Worum geht es im Detail?

Fangen wir mit Predictive Shielding an, weil es das spannendere Stück ist. Defender hat seit Jahren die Auto-Attack-Disruption, die kompromittierte Geräte und User isoliert, sobald ein hoher Confidence-Score erreicht ist. Das funktioniert gut, ist aber per Definition reaktiv: erst wenn der Angreifer eine Aktion ausführt, die als böse erkannt wird, schlägt Defender zu. Predictive Shielding dreht diese Logik um. Statt zu warten, bis der Angreifer auf dem nächsten Asset landet, berechnet Defender den wahrscheinlichsten nächsten Hop und zieht dort die Türen zu.

Technisch sitzt das Ganze auf einem Graph. Defender legt die Live-Aktivität des laufenden Incidents auf den Exposure-Graph der Organisation, also auf die Topologie aus Geräten, Identitäten, Berechtigungen, Schwachstellen und Abhängigkeiten. Aus dieser Kombination berechnet ein Reasoning-Modell den sogenannten Blast Radius, also alle Assets, die der Angreifer als nächstes ansteuern dürfte. Dazu kommen Threat Intelligence und gelernte Muster aus früheren Incidents. Wenn das Modell zum Beispiel sieht, dass der Angreifer bereits Mimikatz auf einem Domain Member abgesetzt hat und ein hochprivilegierter Service-Account auf demselben Gerät vor zwei Stunden interaktiv eingeloggt war, dann ist der Pfad zum Tier-0-Asset eine Frage von Minuten. Genau dann greift Predictive Shielding und beschränkt den Account, bevor das Token gestohlen oder wiederverwendet wird.

Die konkreten Aktionen sind nicht neu, aber neu kombiniert. Es gibt drei Bausteine: Erstens Proactive User Containment, also die Beschränkung verdächtiger Accounts auf Netzwerkebene, allerdings selektiver als bei der klassischen Disruption. Es werden nur neue Sessions geblockt, aktive Sessions bleiben erhalten, damit Endanwender nicht aus dem Postfach fliegen, während sie gerade ein Angebot tippen. Zweitens Safeboot-Hardening, das verhindert, dass ein kompromittiertes Gerät in den abgesicherten Modus bootet, was Angreifer regelmäßig nutzen, um EDR-Agents stillzulegen. Drittens GPO-Hardening, das Änderungen an Group Policy Objects unterbindet, sobald der Angreifer Richtung Domain Controller schielt. Voraussetzung für alle drei ist mindestens eine Defender-for-Endpoint-Lizenz auf den betroffenen Geräten.

Abbildung 1: Architekturdiagramm Predictive Shielding (Signale → Prediction → Enforcement)

Der zweite Block des April-Updates ist administrativ unspektakulär, aber operativ richtig wichtig: Microsoft hat eine neue Empfehlung im Secure Score ausgerollt, die Defender-for-Endpoint-Telemetrie nutzt, um pro Gerät zu zeigen, ob es bereits die Secure-Boot-2023-Zertifikate und den neuen Boot Manager hat oder nicht. Der Hintergrund ist banal, aber unausweichlich. Die ganze Welt der UEFI-Signaturen hängt seit 2011 an drei Microsoft-Zertifikaten: der KEK CA 2011, der Windows Production PCA 2011 und der UEFI CA 2011. Diese Zertifikate haben eine 15-Jahres-Laufzeit. Du kannst dir ausrechnen, wann das Ablaufdatum tickt: KEK CA 2011 und UEFI CA 2011 laufen ab Juni 2026 aus, die Windows Production PCA 2011 folgt im Oktober 2026. Microsoft schiebt seit Anfang 2025 die Nachfolger nach, also KEK 2K CA 2023, Windows UEFI CA 2023 und Microsoft UEFI CA 2023, plus eine zusätzliche Option-ROM-CA für Firmware-Komponenten.

Was passiert, wenn du nichts tust? Die Geräte starten weiterhin, das ist die gute Nachricht. Die schlechte: Sie bekommen ab dem Ablaufdatum keine neuen Boot-Manager-Updates mehr signiert, keine neuen Einträge in die Secure-Boot-Datenbanken, keine Revocation-List-Updates und keine Mitigationen für neu entdeckte Boot-Level-Schwachstellen. Mit anderen Worten: Du fährst eine BootKit-anfällige Flotte ohne Patch-Pfad. BitLocker wird dazu in den nächsten Versionen zickig, wenn die Kette nicht stimmt, und Drittanbieter-Bootloader, etwa für Linux-Dual-Boot oder bestimmte Backup-Tools, werden instabil. Genau deshalb sortiert die neue Secure-Score-Empfehlung deine Flotte in eine handfeste Status-Liste.

Abbildung 2: Beispielhafte Verteilung der Secure-Boot-Statuswerte aus der neuen Empfehlung

Microsoft unterscheidet zwei Verteilungsmodelle. Im Microsoft-managed-Modus schiebt Windows Update die Updates automatisch in die Secure-Boot-Datenbanken, sobald die Geräte passen. Im Self-managed-Modus, der typische Enterprise-Fall mit eingefrorenen Updates, musst du selber ran: Registry-Keys, GPOs, WinCS-APIs oder die entsprechenden Intune-Konfigurationsprofile. Genau hier wird die neue Secure-Score-Empfehlung zum Lebensretter, weil du sonst nicht zentral siehst, welche Geräte schon durch sind und welche noch hinten anstehen.

Abbildung 3: Zeitleiste der Secure-Boot-Zertifikatsumstellung

Was sind Chancen? Was sind Risiken?

Die Chancen bei Predictive Shielding liegen auf der Hand und der Reihe nach: Erstens kaufst du dir Reaktionszeit, ohne SOC-FTE einzustellen. Defender übernimmt die schnellen, statistisch robusten Maßnahmen automatisch und liefert dem Analysten ein Incident-Bild, in dem die Schadensausbreitung schon eingedämmt ist. Zweitens reduzierst du die operative Reibung: statt eine ganze Geräteklasse pauschal zu isolieren, wird selektiv genau der Account oder das Gerät eingeschränkt, das wahrscheinlich als nächstes drankommt. Das ist ein riesiger Unterschied für den Helpdesk, der sonst am Tag nach dem Vorfall die Telefon-Hotline mit gesperrten Außendienstlern flutet. Drittens bekommst du ein neues Detail-Pane pro Incident, in dem du als Auditor genau nachvollziehen kannst, was Defender autonom getan hat und in welchem Status es steckt. Auch das war bisher schwer zu dokumentieren.

Die Risiken sind ähnlich klar. Predictive Shielding ist Public Preview. Microsoft schreibt das nicht ohne Grund mehrfach hin: das Modell trifft manchmal Confident-Calls auf Basis von Wahrscheinlichkeiten. False Positives sind nicht ausgeschlossen, gerade wenn IT-Admins legitimerweise mit Tools arbeiten, die in der Telemetrie wie Lateral-Movement aussehen. PsExec im Wartungsfenster, Remote-Imaging-Aktionen oder Penetrationstests werden häufig als verdächtig eingeordnet. Du musst also Tagging und Allowlisting für deine eigenen Admin-Accounts und Service-Accounts sauber pflegen, sonst containst du dir den Backup-Operator weg, während er gerade ein Restore fährt. Zweitens: Predictive-Shielding-Aktionen wie Safeboot-Hardening sind harte Eingriffe ins System, die du im Audit-Trail erklären können musst. Sprich früh mit dem Betriebsrat und der internen Audit-Funktion, sonst hast du eine politische Diskussion an dem Tag, an dem es zählt.

Beim Secure-Boot-Block sind die Chancen einfacher: Du bekommst einen automatisierten, telemetriegestützten Reportingweg, mit dem du den Status pro Gerät siehst. Das war bisher nur mit Intune-Berichten oder Eigenbau-PowerShell-Skripten möglich, und beides ist im Mittelstand häufig unvollständig. Risiken liegen vor allem an drei Stellen: Geräte, die zu alt für das Update sind, Geräte mit eingefrorenen OEM-Firmwares und Geräte, die in Boot-Manager-Customizations stecken, etwa wegen WindowsToGo, Drittanbieter-Bootloader oder spezieller BitLocker-Verfahren. Bei allen drei Gruppen musst du jetzt einen Plan machen, sonst hast du im Sommer eine kleine, aber sehr laute Hardware-Welle.

Was müssen wir jetzt schon vorbereiten?

Konkret und in Reihenfolge. Erstens, Predictive Shielding nicht stillschweigend abnicken, sondern aktiv einplanen. Schau im Defender-Portal nach, ob die Funktion für deinen Tenant bereits sichtbar ist, und definiere ein Pilot-Set aus zwei oder drei Abteilungen, auf das du anfangs ausrollst. Identity-Tiering muss vorher stehen: Admin-Konten in eigenen Tiers, Service-Accounts mit klarer Kategorisierung, sensible Maintenance-Tools wie PsExec über Just-in-Time-Workflows. Wer das nicht hat, baut es jetzt, weil Predictive Shielding ohne sauberes Tier-Modell mehr Frust als Schutz produziert.

Zweitens, ein Runbook für die Auto-Aktionen schreiben. Was genau passiert, wenn Predictive Shielding einen Account containment? Wer darf das in welchem Verfahren wieder freigeben? Welche Eskalation, wenn der CFO-Account betroffen ist? Diese Fragen entscheidet niemand gerne im Live-Incident. Nutze die ruhige Phase im Mai, schreib eine Seite, lass sie vom CISO und der internen Audit-Funktion abnicken und sorg dafür, dass das SOC sie in der Schicht kennt. Drittens, die neue Detail-Pane in den Incident-Reports der nächsten Tabletop-Übung mitziehen. Ein Auditor wird in zwölf Monaten danach fragen, und du willst dann nicht erst im Portal suchen müssen.

Beim Secure-Boot-Block fällt der Fahrplan in zwei Wellen. Erste Welle, Inventarisierung: aktiviere die neue Secure-Score-Empfehlung, exportiere die Liste pro Asset, gleiche sie mit deiner CMDB ab und kennzeichne die Eligible-Geräte, die kein Update bekommen, weil OEM-Firmware oder Hardware-Generation nicht mitspielen. Zweite Welle, Rollout: Self-managed-Tenants brauchen den Update-Plan über Intune-Konfigurationsprofile oder GPOs. Microsoft-managed-Tenants schauen, ob Windows Update den Pfad sauber durchschiebt, und kontrollieren via Secure-Score-Empfehlung den Fortschritt. Plane den Rollout so, dass alle eligible-Geräte bis Anfang Juni durch sind, ein, zwei Wochen Puffer vor dem Stichtag, weil Reboot-Wellen erfahrungsgemäß nicht in einem Schwung durchlaufen.

Eine Sonderbehandlung verdienen Server. Die Empfehlung kommt zuerst auf Defender-for-Endpoint-Geräten, das schließt Server mit ein, aber kritische Hosts mit eingefrorenen Wartungsfenstern brauchen einen eigenen Plan. Hyper-V-Hosts, die auf Secure-Boot-aktivierten Hardwaregenerationen laufen, sind besonders sensibel, ebenso Cluster, die du ohnehin nur in Patch-Tuesday-Wellen anfasst. Plane hier explizit ein Wartungsfenster in KW 21 oder KW 22, damit du nicht in der letzten Maiwoche aus der Komfortzone in eine Spätschicht rutschst.

Wenn du beide Themen sauber durchziehst, hast du im Juli zwei Punkte weniger im Risikoregister: einen, weil Predictive Shielding deinen SOC entlastet und Lateral-Movement aktiv eindämmt, und einen, weil deine Flotte im Sommer nicht in eine Boot-Pannenwelle rauscht. Beides kostet vor allem Planung, weniger Geld. Genau deshalb gehört es jetzt auf den Tisch, bevor das eigentliche operative Geschäft im Juni wieder voll dazwischenfunkt.