Microsoft will retire the legacy Microsoft Graph security alerts API on 15 October 2026. The affected endpoint is /security/alerts, which applications have used to retrieve, monitor, or update security alerts. Microsoft tells customers to move to the new alerts and incidents API in Microsoft 365 Defender through /security/alerts_v2 and, depending on the workflow, /security/incidents. This is not just a developer detail. If a SIEM connector, reporting script, or automation still calls the legacy API, it will stop receiving data after the deadline.
What Microsoft is retiring
The Microsoft Learn page is explicit about the deadline: after 15 October 2026, the legacy /security/alerts endpoint will stop returning data. The replacement is not only a different path, but a different model. Microsoft 365 Defender presents alerts more strongly in the context of incidents. Instead of processing alert objects in isolation, integrations can also retrieve incidents and group related signals from identity, endpoint, email, cloud, and other sources. Microsoft also describes richer evidence types, MITRE ATT&CK context, and a clearer separation between classification and determination. Any workflow that currently treats alerts as a flat list therefore needs a functional review.
Why this matters for SMBs
Companies with 10 to 250 users rarely build their own security APIs, but they often rely on service providers, SIEM integrations, PowerShell scripts, or lightweight dashboards. That is exactly where the old endpoint can remain unnoticed. The change is especially relevant for environments using Microsoft Defender, because alerts and incidents are consolidated in the Defender portal. Microsoft also states that Microsoft Purview can contribute additional signals, including Data Loss Prevention and Insider Risk Management.
- Security reports can become empty even though alerts still exist in the portal.
- Automated tickets or email notifications can fail after the retirement date.
- Dashboards can show a false security picture if they only query the old API.
- External SOC or MSP integrations should explicitly confirm which endpoint they use.
Deadline and review scope
The deadline is 15 October 2026. Microsoft says organizations should identify all integrations, scripts, connectors, and downstream processes that call /security/alerts. This inventory should not wait until the cutoff date, because permissions and data models also need to change. If you use Microsoft Sentinel, you must also check whether the Sentinel workspace is connected to the Microsoft Defender portal. Microsoft states that Sentinel-generated alerts appear through the new API only after that onboarding; otherwise, the Sentinel REST API is needed during the transition. The documented limitations also matter: standalone alerts outside the Microsoft 365 Defender incident model, tuned alerts, some Exchange Online events, and Intune-originated alerts may require other data sources.
What changes technically
The migration is more than a search-and-replace exercise. List, get, and update operations move from /security/alerts to /security/alerts_v2. Incidents become available through /security/incidents. Microsoft Graph permissions also change: read scenarios move from SecurityEvents.Read.All to SecurityAlert.Read.All, while incidents use dedicated permissions such as SecurityIncident.Read.All. After the new permissions are added, an administrator must grant consent. Field names, evidence objects, and filter logic also change for users, devices, files, URLs, and IP addresses. Microsoft gives examples for new OData filters, including evidence/any(), so validation should use real alerts, not just a successful HTTP response.
Concrete next steps
A clean migration starts with finding where the legacy API is used today. The next step is a pilot with real alerts from your own tenant. As part of a Microsoft Security Assessment, this review can be combined with Defender, Sentinel, and Purview dependencies without turning it into licensing advice.
- Search app registrations, scripts, SIEM connectors, and Power Automate flows for
/security/alerts. - For each integration, decide whether it needs alerts, incidents, or both object types.
- Add the new Graph permissions, obtain admin consent, and document the change.
- Test queries, filters, and field mappings against
/security/alerts_v2and/security/incidents. - Before 15 October, confirm that expected alerts and downstream workflows arrive completely.
Official Microsoft sources
- Microsoft Learn: Migrate from legacy alerts to the alerts and incidents API
- Microsoft Graph: alert resource type
If you are not sure whether your security processes still use the legacy Graph API, we can review the affected integrations and prioritize the migration as part of your Microsoft 365 security planning – get in touch.
What does this mean for your environment?
Assess the topic in the context of your Microsoft 365 environment and define a practical next step.
You speak directly with Sebastian Kerssen – working in the Microsoft ecosystem since 2014, with personal consulting and a dedicated point of contact.
