Microsoft schaltet die alte Microsoft-Graph-Sicherheitswarnungs-API am 15. Oktober 2026 ab. Betroffen ist der Endpunkt /security/alerts, über den Anwendungen bisher Sicherheitswarnungen abrufen, überwachen oder bearbeiten konnten. Microsoft empfiehlt den Wechsel auf die neue Alerts-and-Incidents-API in Microsoft 365 Defender über /security/alerts_v2 und, je nach Ablauf, auf /security/incidents. Für Unternehmen ist das kein abstraktes Entwicklerthema: Wenn ein SIEM-Connector, ein Reporting-Skript oder eine Automatisierung noch die alte API nutzt, liefert sie nach der Frist keine Daten mehr.
Was Microsoft konkret abschaltet
Die Microsoft-Learn-Seite nennt die Frist eindeutig: Nach dem 15. Oktober 2026 gibt der alte Endpunkt /security/alerts keine Daten mehr zurück. Der neue Weg ist nicht nur ein anderer Pfad, sondern ein anderes Modell. Microsoft 365 Defender stellt Warnungen stärker im Zusammenhang von Vorfällen dar. Statt einzelne Alert-Objekte isoliert zu verarbeiten, können Integrationen auch Incidents abrufen und so zusammengehörige Signale aus Identität, Endpunkt, E-Mail, Cloud und weiteren Quellen besser gruppieren. Microsoft beschreibt außerdem mehr Evidenztypen, MITRE-ATT&CK-Kontext und eine stärkere Trennung von Klassifizierung und Bestimmung. Wer bisher nur eine flache Alert-Liste verarbeitet, muss daher prüfen, ob die eigene Logik weiterhin dieselbe fachliche Aussage liefert.
Warum das für KMU zählt
Unternehmen mit 10 bis 250 Arbeitsplätzen betreiben selten eigene API-Entwicklung, nutzen aber oft Dienstleister, SIEM-Anbindungen, PowerShell-Skripte oder einfache Dashboards. Genau dort kann der alte Endpunkt unbemerkt stecken, besonders wenn die ursprüngliche Einrichtung bereits mehrere Jahre zurückliegt. Besonders relevant ist das für Umgebungen mit Microsoft Defender, weil Warnungen und Vorfälle im Defender-Portal zusammenlaufen. Auch Microsoft Purview kann laut Microsoft zusätzliche Signale liefern, etwa aus Data Loss Prevention und Insider Risk Management.
- Security-Reports können leer bleiben, obwohl im Portal weiterhin Warnungen vorhanden sind.
- Automatisierte Tickets oder E-Mail-Benachrichtigungen können nach der Frist ausfallen.
- Dashboards können eine falsche Sicherheitslage anzeigen, wenn nur die alte API abgefragt wird.
- Externe SOC- oder MSP-Anbindungen sollten ihren API-Pfad ausdrücklich bestätigen.
Frist und Prüfumfang
Die Frist ist der 15. Oktober 2026. Microsoft fordert, alle Integrationen, Skripte, Connectoren und nachgelagerten Prozesse zu identifizieren, die /security/alerts aufrufen. Diese Bestandsaufnahme sollte nicht erst am Stichtag beginnen, weil auch Berechtigungen und Datenmodelle geändert werden müssen. Wer Microsoft Sentinel nutzt, muss zusätzlich prüfen, ob der Sentinel-Arbeitsbereich mit dem Microsoft-Defender-Portal verbunden ist. Microsoft schreibt, dass Sentinel-generierte Warnungen erst dann über die neue API erscheinen; sonst braucht es vorübergehend die Sentinel-REST-API. Ebenso wichtig sind die dokumentierten Grenzen: Standalone-Warnungen außerhalb des Microsoft-365-Defender-Incident-Modells, durch Alert Tuning unterdrückte Warnungen, bestimmte Exchange-Online-Ereignisse und Intune-Warnungen können andere Datenquellen erfordern.
Was sich technisch ändert
Der Wechsel ist mehr als ein Suchen-und-Ersetzen. Für Listen-, Einzelabruf- und Aktualisierungsoperationen wandert der Pfad von /security/alerts zu /security/alerts_v2. Incidents sind neu über /security/incidents erreichbar. Auch die Microsoft-Graph-Berechtigungen ändern sich: Aus SecurityEvents.Read.All wird für Leseszenarien SecurityAlert.Read.All; für Incidents kommen eigene Berechtigungen wie SecurityIncident.Read.All hinzu. Nach dem Eintragen der neuen Rechte muss ein Administrator die Zustimmung erteilen. Zusätzlich ändern sich Feldnamen, Evidenzobjekte und Filterlogik, etwa bei Benutzern, Geräten, Dateien, URLs und IP-Adressen. Microsoft nennt Beispiele für neue OData-Filter, etwa über evidence/any(). Solche Filter sollten mit realen Warnungen getestet werden, nicht nur mit einem erfolgreichen HTTP-Status.
Konkrete nächste Schritte
Für eine saubere Migration sollte zuerst geprüft werden, wo die alte API überhaupt verwendet wird. Danach folgt ein Pilot mit echten Warnungen aus dem eigenen Tenant. Im Rahmen eines Microsoft Security Assessments lässt sich diese Prüfung mit Defender-, Sentinel- und Purview-Abhängigkeiten verbinden, ohne daraus eine Lizenzberatung zu machen.
- App-Registrierungen, Skripte, SIEM-Connectoren und Power-Automate-Flows nach
/security/alertsdurchsuchen. - Für jede Integration entscheiden, ob sie Alerts, Incidents oder beide Objekte braucht.
- Neue Graph-Berechtigungen eintragen, Admin-Zustimmung einholen und die Änderung dokumentieren.
- Abfragen, Filter und Feldzuordnungen gegen
/security/alerts_v2und/security/incidentstesten. - Vor dem 15. Oktober prüfen, ob erwartete Warnungen und nachgelagerte Workflows vollständig ankommen.
Offizielle Microsoft-Quellen
- Microsoft Learn: Migrate from legacy alerts to the alerts and incidents API
- Microsoft Graph: alert resource type
Wenn unklar ist, ob Ihre Sicherheitsprozesse noch die alte Graph-API nutzen, prüfen wir die betroffenen Integrationen und priorisieren die Umstellung gemeinsam mit Ihrer Microsoft-365-Sicherheitsplanung – sprechen Sie uns an.
Was bedeutet das für Ihre Umgebung?
Ordnen Sie das Thema im Kontext Ihrer Microsoft-365-Umgebung ein und legen Sie einen sinnvollen nächsten Schritt fest.
Sie sprechen direkt mit Sebastian Kerssen – seit 2014 im Microsoft-Umfeld, mit persönlicher Beratung und direktem Ansprechpartner.
