Defender Advanced Hunting API Retirement: Migrate KQL Automations to Microsoft Graph Before February 2027

What Microsoft announced, and when​

This isn't new. The archived notice shows it was first published on January 22, 2026 and was updated on October 26, 2026 as a reminder. The key dates in the notice:

Microsoft says the move "aligns our security integrations with a unified interface and schema across Microsoft Defender products". It also says the Microsoft Graph Security API offers broader data coverage, better consistency and better scalability. Those are Microsoft's own claims. The notice doesn't include any benchmarks to back them up.

The operational warning is simple. After February 1, 2027, existing scripts, automations and workflows that call these APIs will fail unless they've been updated, and the notice states that no automatic migration will happen.

One detail is easy to miss. Microsoft says it sent the notice because its reporting shows your organization may be using these APIs. Getting the message proves nothing either way. Not getting it doesn't clear you, and getting it doesn't mean you have a live integration. Only an inventory will tell you.

Section summary: Two Advanced Hunting APIs stop working after February 1, 2027. Microsoft wants migrations finished by January 31, 2027, and it won't do them for you.

What's retiring, and what isn't​

This is not a shutdown of Defender XDR APIs in general, and Advanced Hunting itself isn't ending. Only the two legacy routes for running hunting queries are going away. Microsoft's Graph documentation says the advanced hunting APIs in Microsoft Graph replace the older version of the API that was available through the and endpoints. It adds that the older APIs are now retired and will stop returning data on February 1, 2027.

Microsoft's migration table also lists the MDE host, api.securitycenter.microsoft.com/api/advancedqueries/run, as a legacy endpoint. Search for all three hostnames and paths:

• api.securitycenter.microsoft.com/api/advancedqueries/run (MDE)
• api.security.microsoft.com/api/advancedhunting/run (Defender XDR)
• api.security.microsoft.com/api/advancedqueries/run

It's more than a URL swap​

It's tempting to treat this as a find-and-replace job. It isn't. Microsoft's migration guidance lists changes to four parts of an integration:

The response change is where working code tends to break quietly. A parser that expects Results with a capital R, or reads the Stats block, won't find what it's looking for. Graph also accepts an optional timespan parameter. Per Microsoft's reference, the default is 30 days, and if the query and the timespan both set a time filter, the shorter one wins.

Permissions and roles​

The Graph API reference lists ThreatHunting.Read.All as the least-privileged permission for both delegated (work or school) and application access. Delegated access with a personal Microsoft account isn't supported.

For delegated calls, the signed-in user also needs one of these:

• a Defender XDR unified RBAC role that grants advanced hunting access, or
• the Microsoft Entra role Security Reader, Global Reader, Security Operator or Security Administrator.

The API is available in the global service and in US Government L4 and L5 (DoD). It isn't available in the China cloud operated by 21Vianet.

Beta or v1.0?​

Microsoft's migration table points to the beta endpoint, graph.microsoft.com/beta/security/runHuntingQuery. Microsoft's own beta documentation says beta APIs can change and aren't supported in production applications. That's an odd target for a production cutover.

There is a v1.0 version, though. Microsoft Learn has a v1.0 reference page for runHuntingQuery, which describes it as a method that queries a specified set of event, activity, or entity data supported by Microsoft 365 Defender to proactively look for specific threats in your environment. Its examples call POST. The PowerShell example uses Start-MgSecurityHuntingQuery from the Microsoft Graph PowerShell SDK.

Community guidance makes the same call. The Adversary Lab newsletter tells admins to swap the endpoint to graph.microsoft.com/v1.0/security/runHuntingQuery.

My recommendation, based on Microsoft's general rules for beta versus v1.0 rather than any statement in the notice: build production integrations on v1.0, and only use beta if you need something v1.0 doesn't have. Whichever you pick, test against the documentation for that version. Request and response details can differ between the two. For example, the v1.0 examples write the body properties as Query and Timespan.

Section summary: Expect to change the token audience, the permissions, the endpoint and the response parsing. Your KQL itself should mostly carry over. A v1.0 Graph endpoint exists, so you don't have to put production on beta.

Power Platform and Power BI need extra work​

Two common integrations won't move over with a simple config change:

• Power Automate, Power Apps and Logic Apps. Microsoft says Graph has no built-in Advanced Hunting action like the one in the Power Platform connector for Microsoft Defender ATP. To keep using Advanced Hunting in those flows, you'll need a custom connector that uses the Graph parameters.
• Power BI. Custom reports built on the old API need their queries rewritten to use the Graph parameters.

Low-code flows often belong to someone outside the security team, which makes them easy to miss. A compliance analyst's dashboard that refreshes every morning could simply stop on February 2.

Step-by-step migration checklist​

1. Inventory. Search code repositories, runbooks, scheduled tasks, SIEM/SOAR playbooks, Power Platform environments and Power BI datasets for the legacy hostnames and paths. Also check Entra app registrations that hold AdvancedQuery.* or AdvancedHunting.* permissions.
2. Assign owners. Microsoft's notice says to tell security operations, engineering and development teams. Every integration you find needs a named owner.
3. Re-permission. Grant ThreatHunting.Read.All to each app registration, get admin consent, and confirm that delegated users have a qualifying Defender RBAC or Entra role.
4. Update requests. Request tokens for Microsoft Graph instead of the Defender resource, change the endpoint, and check the request body against the API version you've chosen.
5. Fix parsing. Rewrite any code that reads Stats, Schema or Results so it handles the Graph schema/results shape.
6. Rebuild low-code pieces. Build custom connectors for Power Platform flows and update the Power BI queries.
7. Validate. Run representative KQL queries through both paths and compare the results. Microsoft specifically tells organizations with custom solutions to confirm that new queries and response schemas behave as expected before the retirement date.
8. Clean up. Once the new path is verified, remove the legacy permissions and update internal documentation.

Graph enforces quotas, so test with realistic workloads. Microsoft documents a 30-day query window, a 100,000-row result cap, a 200-second limit per request, and HTTP 429 responses when you exceed call or execution-time quotas. If a nightly job pulls large datasets, test it at full size, not with a five-row sample.

Section summary: Inventory, re-permission, re-plumb, re-parse and validate, and plan to finish well before January 31.

Analysis​

Microsoft has been consolidating its security integrations onto Graph for years, and this retirement is part of that. Microsoft's Graph documentation also warns that the legacy alerts API is deprecated, with a retirement date of October 15, 2026. A single API surface with one permission model and one schema really is easier to govern than a collection of product-specific endpoints.

There are fair complaints too. The official migration table sends people to a beta endpoint that Microsoft itself says not to use in production. The Power Platform route goes from a built-in action to a custom connector you have to build. And retirement "began" in February 2026 without anything obviously breaking, which makes it easy to keep putting the work off.

None of that changes the date. Integration retirements like this tend to cause trouble in the forgotten pieces: the script someone wrote three years ago, or the service principal nobody remembers creating. You have about three months, including the holidays. Start the inventory this week.