Microsoft Sentinel Blog articles

What’s new in Microsoft Sentinel: August 2026

spalani — Mon, 31 Aug 2026 16:00:00 GMT

Welcome back to What's new in Microsoft Sentinel. This August, Sentinel innovation kicks off with the AI-powered playbook generator, generally available to all Sentinel customers in the Microsoft Defender portal. Meanwhile, User and Entity Behavior Analytics (UEBA) anomalies enter public preview on the Behaviors layer, with coverage across Fortinet, AWS GuardDuty, Check Point, and Zscaler. In Sentinel data lake, nested API support in the Codeless Connector Framework (CCF) enters public preview to connect data sources whose APIs span multiple calls, and multi-account data ingestion is now generally available for Auth0, CrowdStrike, and Salesforce. Finally, the free Microsoft Threat Intelligence connector for unified SecOps, marking the final phase of MDTI convergence, is now generally available in the Defender portal.

Read on for the details, and explore our resources at the end to go deeper.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake

Sentinel SIEM

AI-powered playbook generator expanded to all Sentinel customers in the Defender portal [Generally Available]

Go from intent to action faster with the AI-powered playbook generator. It is available to all Sentinel customers using the Defender portal with no Security Copilot enablement or additional cost required. Describe the response you want in natural language and generate an editable, code-based playbook complete with tests, documentation, and a visual flow.

Figure 1: Automatically-created visual flow diagram of the playbook.

To get started, confirm you have Automation Playbooks Unified RBAC Read and Write permissions, then select Automation > + Create > Playbook Generator. Read our blog to learn more.

UEBA Anomalies are now built on top of Behaviors, along with expanded coverage through new data sources [Public Preview]

Understand what happened and why it matters in one place. Sentinel adds UEBA anomaly insights and explainable context directly to the Behaviors layer, while expanding coverage across Fortinet, AWS GuardDuty, Check Point, and Zscaler data. This helps you identify unusual activity across identity, network, and cloud environments, reduce investigation time, and focus on the highest-risk behaviors. Enable the Behaviors layer, connect supported data sources, and explore the Insights column in the BehaviorInfo table to get started. Read our blog to learn more and watch our training video for a guided walkthrough.

Sentinel data lake

Nested API support in Codeless Connector Framework [Public Preview]

Nested API support in the Sentinel Codeless Connector Framework (CCF) handles the list-then-detail pattern common across ISV log sources, where a single polling cycle spans multiple dependent API calls. An initial call returns a list of records such as alert IDs or case references, and one or more follow-up calls fetch the full detail for each record in that list. This means you can connect data sources whose APIs are naturally paginated across multiple calls and ingest complete records into Sentinel without building custom middleware or restructuring your endpoints. The pattern is also available through the Visual Studio Code (VS Code) extension for Sentinel connectors, which gives you a guided way to build, test, and package connectors that orchestrate chained requests. Read our blog to learn more, or try it with mock data in our Nested API Lab.

Multi-account ingestion for Auth0, CrowdStrike, and Salesforce [Generally Available]

Sentinel data connectors for Auth0, CrowdStrike Falcon, and Salesforce Service Cloud now support multi-account ingestion — powered by the Codeless Connector Framework (CCF). You can now connect and monitor multiple accounts or tenants from a single, unified connector configuration — no scripts, no hacks.

🔑 Auth0 — Multi-tenant identity monitoring

Security teams managing multiple Auth0 tenants can now ingest logs from all of them into a single Sentinel workspace. Get complete visibility into authentication events, anomalous login patterns, and policy violations across every tenant without switching contexts.

🦅 CrowdStrike Falcon — Consolidated endpoint telemetry

Organizations running multiple CrowdStrike tenants (e.g., across M&A entities or regional subsidiaries) can now stream detection alerts, threat intelligence, and endpoint telemetry from all tenants into Sentinel. One workspace. Full coverage.

☁️ Salesforce — Cross-org security insights

Enterprises with multiple Salesforce orgs can now centralize audit logs, login history, and API activity across all orgs. Detect insider threats, unauthorized access, and compliance gaps without stitching data together manually.

Get started with multi-account ingestion by finding your supported Sentinel data connector.

Microsoft Threat Intelligence connector [Generally Available]

The final phase of Microsoft Defender Threat Intelligence (MDTI) convergence is generally available in the Defender portal, giving you real-time Microsoft threat intelligence across detection, investigation, response, hunting, and automation at no additional cost. The result is a unified SecOps experience that reduces fragmented context and tool handoffs, and creates a clear path from threat signal to informed action. Microsoft Threat Intelligence data that previously required the Premium MDTI connector is available through the free Microsoft Threat Intelligence connector in Sentinel, enabling free and premium indicator feeds through one setup. MDTI APIs are also included for Sentinel customers without a separate license, and the API surface is unchanged, so no migration action is required. Read the blog to learn more.

Additional resources

Blogs and documentation:

Upcoming webinars:

Sep 2: Microsoft Security Immersion Event: Agent Hackathon
Sep 8: Security Immersion Event: Into the Breach
Sep 8–9: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats
Sep 22: Tech Brief: Modernize security operations with a unified platform
Sep 23: Microsoft Security Immersion Event: Shadow Hunter

Stay connected

Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!

Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent

Robert_Moriarty — Tue, 11 Aug 2026 16:00:00 GMT

Overview

We previously announced the public preview of the Microsoft Sentinel connector builder agent via VS code extension, that helps developers build Microsoft Sentinel codeless connectors faster with low-code and AI-assisted prompts. This post walks through a hands-on lab using a mock Network Log API to demonstrate how the Sentinel connector builder agent simplifies building Codeless Connector Framework (CCF) pull connectors. Instead of manually creating ingestion infrastructure and configuration files, you’ll use a guided, conversational workflow in VS Code to generate connector artifacts, test them against a live API, and deploy them into Microsoft Sentinel. The lab focuses on the end-to-end experience ranging from API setup to validated connector deployment so you can see how quickly a working integration can be produced. For additional guidance beyond this lab, refer to our MS Learn documentation.

The Lab Environment

This lab is built around a mock Network Log API hosted as an Azure Function App. The purpose of the lab environment is to give us a live API that we can use to build, validate, and test the Sentinel CCF connector builder agent against end to end. The API exposes 50 synthetic network activity records that look and behave like a real product data source, including web traffic, DNS requests, blocked remote access attempts, malware command-and-control blocks, VPN activity, and other common network events. That makes it a useful stand-in for the type of telemetry many teams want to onboard into Microsoft Sentinel.

The API is intentionally shaped like the kind of source a customer might expose for telemetry retrieval. It uses API key authentication through the X-API-Key header, returns paginated results through a nextLink model, and provides a predictable response structure that the builder agent can map into a pull connector configuration.

The repo contains everything needed for the walkthrough. There is an ARM template to deploy the Function App, reference documentation for the API, and a sample connector package showing the generated polling config, table schema, DCR, and connector definition. The end goal of the lab is straightforward: use the builder agent to generate a CCF pull connector that ingests this API into the custom NetworkLogAPIGetNetworkLogs_CL table in Sentinel.

Prerequisites

Before starting, make sure you have the following:

Azure subscription -- with Contributor access on a resource group (for deploying the Function App) and Microsoft Sentinel Contributor access on a Sentinel-enabled workspace (for deploying the connector)

Microsoft Sentinel workspace -- an existing Log Analytics workspace with Sentinel enabled. See Onboard Microsoft Sentinel to a Log Analytics workspace for more information.

Azure CLI -- See How to install the Azure CLI for more information.

VS Code with the Microsoft Sentinel for Visual Studio Code extension installed.

GitHub Copilot -- with access to premium models. The connector builder agent requires Claude Sonnet 4.5 or 4.6, which uses Copilot premium model credits.

Lab Repository -- Once the aforementioned prerequisites are met, you can access the lab repository here: Azure-Sentinel/Tools/CCF-Connector-Builder-Agent-Accelerator at master · Azure/Azure-Sentinel

Deploying the Mock API

The full CLI commands for this section are available in the repo. For a simpler option, you can use GitHub Copilot to handle the deployment. Enter this prompt:

Follow the deployment instructions in Sentinel-CCF-Pull-Connector-Builder-Agent-Accelerator/agent-instructions.md. Let’s deploy the Network Log API and build a CCF pull connector.

At a high level, the setup is four steps: clone the repo, create a resource group, ensure you have a Sentinel-enabled workspace, and deploy the Function App using the included ARM template. The template takes two parameters: an ApiKey of your choice (the secret the CCF connector will use to authenticate) and your Log Analytics workspace resource ID for Application Insights. Deployment takes about two to three minutes and outputs the FunctionAppName and endpoint URLs you will need later.

Once deployed, verify the API is live:

curl -s -H "X-API-Key: <your-api-key>" \   "https://<functionappname>.azurewebsites.net/api/GetNetworkLogs?page=1&pageSize=3" </functionappname></your-api-key>

You should see a response like this:

The API also exposes an /api/RefreshData endpoint that regenerates the 50 sample records with fresh timestamps. This is useful later in the walkthrough when you want to produce new events and trigger an immediate ingestion cycle without waiting for the next polling interval:

curl -s -X POST -H "X-API-Key: <your-api-key>" \   "https://<functionappname>.azurewebsites.net/api/RefreshData" </functionappname></your-api-key>

Building the Connector with the Sentinel Connector Builder Agent

With the Microsoft Sentinel extension installed and GitHub Copilot running in agent mode, open a Copilot chat and enter a single prompt pointing at the API documentation file:

That is the entire invocation. The agent takes it from there. It works through a structured seven-step sequence: preparation, polling config, table schema, DCR, connector definition, package validation, and summary. The agent produces four files in a sentinel-connectors/NetworkLogAPI_CCF/ output folder:

NetworkLogAPI_PollingConfig.json – This is the API poller configuration. The agent reads the documentation and correctly identifies the GET /api/GetNetworkLogs endpoint, configures API Key authentication via the X-API-Key header, sets up NextPageUrl pagination using $.metadata.nextLink with a $.metadata.hasNextPage stop condition, and wires up the since query parameter for incremental delta pulls using the timestamp field. The RefreshData endpoint is correctly excluded, which the agent recognizes as a maintenance operation, not a security data stream.

NetworkLogAPI_Table.json – This is the custom Log Analytics table schema for NetworkLogAPIGetNetworkLogs_CL. All 20 fields from the API response are mapped to the correct column types, with timestamp promoted to TimeGenerated as the standard Sentinel time column.

NetworkLogAPI_DCR.json – This is the Data Collection Rule. This defines the stream declaration, the workspace destination, and the KQL transform that maps the raw snake_case API fields (sourceIp, destinationIp, threatIndicator, etc.) to their PascalCase table columns.

NetworkLogAPI_ConnectorDefinition.json – This is the connector UI configuration. This drives what the connector page looks like in Microsoft Sentinel: the title, description, prerequisite instructions, the BaseUrl and ApiKey input fields, sample KQL queries, and the connectivity status logic.

The only point where the agent paused for input was to propose a connector description and ask for confirmation before writing it to the file. Everything else such as endpoint selection, auth type, pagination pattern, schema mapping, KQL transform, cross-file consistency was selected autonomously.

To put that in perspective: without the agent, a developer building this connector from scratch would need to manually author four JSON files, understand the CCF schema for polling configs, DCRs, and connector definitions, write the KQL transform by hand, and validate that every cross-file reference lines up correctly. The agent compresses that work, typically hours of reading documentation, trial-and-error, and portal debugging, into a single prompt.

Testing the Connector

Before deploying anything to a Sentinel workspace, the Microsoft Sentinel connector builder agent lets you validate the generated polling config against the live API directly from your editor. Right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Test Connector (Preview), and a Configuration Variables panel opens asking for the two template variables from the polling config: BaseUrl and apiKey. For other API patterns, there may be additional and different inputs. For example, apiKey input could be swapped with clientID and secret if the API supports OAUTH.

Enter the Function App base URL and your API key, and the test runner connects immediately. The panel shows a live polling session. Poll #1 returns HTTP 200 with 50 events, and a countdown timer shows when the next poll will fire. Switching to the Events tab displays the ingested records in a tabular view with columns for timestamp, severity, action, bytesIn, bytesOut, category, and the rest of the mapped fields fresh from the API. Additionally, there are tabs for Headers, Payload, and Response, which can be useful for verifying that your pollerconfig.json configuration provides the expected request to your api with a working response.

Data Extracted:

The Test Connector feature can be used to visualize the response data in a table format to verify that data will land in a Sentinel table based on your configuration.

Request from Poller:

The Test Connector feature can be used to validate the request and response headers that will go out to the API based on the generated poller configuration.

Request Response:
The Test Connector feature shows you the live response from the API with respect to the request going to the API based on the poller configuration.

This is a meaningful pre-flight check. It confirms that auth is working, the $.data events path resolves correctly, pagination is functional, and the polling interval fires as configured all before a single file is deployed to Azure. The most common connector configuration issues (wrong base URL, incorrect header name, mismatched JSON path) surface here in seconds rather than after a failed deployment and a 20-minute wait for Sentinel to attempt its first ingestion cycle. It is also the fastest way to troubleshoot if something goes wrong after deployment, far quicker than pushing changes to Azure and waiting for the connector to poll again.

Deploying and Enabling the Connector

With the connector tested and passing, deployment is the same right-click menu: right-click the sentinel-connectors/NetworkLogAPI_CCF folder, select Microsoft Sentinel → Deploy Connector (Preview). If you are not already signed in to Azure, the extension will prompt you to authenticate. The agent will also provide a clickbox in the chat window to invoke a connector deployment.

Right Click Deploy Connector:

UI Prompt Based Deploy Method:

Once signed in, a workspace picker lists all available Log Analytics workspaces across your subscriptions. Select the one with Sentinel enabled and click Deploy. The extension deploys all four files to the workspace in the correct order: table schema first, then DCR, polling config, and connector definition.

Once deployed, navigate to your Sentinel workspace via https://security.microsoft.com, go to Data Connectors, and find the Network Log API connector. The connector page shows the description, prerequisite notes, and the two credential fields generated by the agent: API Base URL and API Key. Enter your Function App base URL and API key and click Connect. The status updates to show the connector is connected and the deployment succeeded.

Note: Data will appear in the workspace within 5 to 30 minutes depending on the polling interval. Run this query in Log Analytics to confirm ingestion. Note that the agent derives the table name from the vendor name and endpoint, so yours may differ slightly from the example below. Check the agent's summary output or the NetworkLogAPI_Table.json file for the exact name:

NetworkLogAPIGetNetworkLogs_CL | sort by TimeGenerated desc | take 10

If you want to generate a fresh batch of events immediately rather than waiting for the next polling cycle, use the RefreshData endpoint to reset the sample records with new timestamps:

curl -s -X POST -H "X-API-Key: " \   "https://.azurewebsites.net/api/RefreshData"

Next Steps

If you want to go further:

Try it with your own API. The lab repo includes documentation on adapting the polling config, schema, and KQL transform to a real data source.
Review the CCF connector schema documentation to understand the full range of supported configurations: pagination patterns, auth types, incremental pull strategies, and delta filter expressions.
Explore the Microsoft Sentinel content hub to see how published connectors are structured and what the certification requirements look like for production submissions.

Conclusion

Following these steps, you saw how a working Sentinel connector can be generated, tested, and deployed in minutes rather than requiring days of manual configuration and infrastructure setup. If you are an ISV building a Sentinel integration and want hands-on support, Microsoft’s App Assure program is available to help. We partner with ISVs on connector development, validation, and deployment and provide guidance through implementation, testing, and readiness for production. You can get started by reaching out through our intake form.

See our other Sentinel connector feature’s hands-on labs

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

AI-powered playbook generator, now available to more customers

NoaCafri — Fri, 07 Aug 2026 19:28:40 GMT

We’re excited to announce we’re making it easier than ever to go from intent to action with the AI-powered playbook generator now available to more customers.

What’s new

All Microsoft Sentinel customers in Defender portal can now create AI-generated playbooks directly in their automation workflow. As part of this change, Security Copilot enablement is no longer required: playbook generator is now available to more teams out of the box and without any extra cost.

What playbook generator does

Playbook generator uses AI to turn what you want to automate into a working playbook. Instead of hand-building automation in python code, describe the response you need in natural language and get an editable playbook, its tests and documentation generated for you right inside the Microsoft Defender portal.

Faster response automation: go from idea to playbook in minutes.

Built into your workflow: find it under Automation › + Create › Playbook Generator.

Fully editable: generated playbooks are code-based, complete with tests, documentation and visual flow, that you can review and refine.

Who is it for

If you’re using Microsoft Sentinel in your Defender portal, the playbook generator is now within reach. This expansion brings AI-assisted playbook creation to significantly more security teams.

How to get started

Ensure you have the right permissions

To build and deploy generated playbooks, make sure You have the Automation Playbooks Unified RBAC permission with Read and Write access.

Open Microsoft Defender Portal and go to Automation.
Select + Create › Playbook Generator.
Describe the playbook you want to create.
Review, edit, and deploy.

Automatically created visual diagram of the playbook.Phyton code created by playbook generator.

Availability

General availability: Already available.
Cost: Included with Microsoft Sentinel - no additional charge.

Try Playbook Generator in your Microsoft Defender Portal today.

Smarter signals, broader coverage: UEBA anomalies on top of Behaviors layer and new data sources

SaraSamokovlija — Tue, 18 Aug 2026 18:39:45 GMT

Co-authors: Ron Shlomo and Ryan Smith

Security teams don't struggle with a lack of security signals. The real challenge is understanding which activity matters, why it stands out, and where to focus first.

Microsoft Sentinel's Behaviors layer already helps analysts transform raw security events into meaningful behavioral patterns. Today, we're making that experience both smarter and broader.

What if every behavior could immediately tell you not only what happened, but why it matters? We're bringing UEBA anomaly intelligence directly into the Behaviors layer, so every behavior now includes anomaly insights together with explainable context. At the same time, UEBA expands beyond identity signals to support network and cloud data sources, enabling richer behavioral insights across more of your environment and helping security teams detect suspicious activity wherever it occurs.

If you're new to these capabilities, we recommend reviewing our previous announcements on the UEBA expansion and the Behaviors public preview, which provide additional background on the Behaviors layer and its underlying UEBA capabilities.

What's new in Sentinel UEBA and Behaviors layer

Microsoft Sentinel’s Behaviors layer aggregates and sequences individual events into meaningful behavioral patterns, giving SOC teams the security context of who did what to whom and why it matters in one place, instead of sifting through raw telemetry in separated tables.

With this release, we're expanding the Behaviors layer. It now includes UEBA Anomalies and contextual enrichments directly within each behavior. In addition, the Behaviors layer now supports Fortinet logs via the CommonSecurityLog table. We're also expanding Classical UEBA beyond identity signals by adding support for network and cloud data sources: AWS GuardDuty, Check Point, Zscaler and Fortinet (via CommonSecurityLog). Together, these enhancements allow the SOC to receive a richer context and explainable anomaly detection for every behavior across a broader portion of the environment.

Adding context to every behavior—use case

The following example illustrates how UEBA Anomalies on Behaviors help analysts quickly identify suspicious activity by adding context to every behavior.

Scenario: Detecting a compromised FortiGate device

An attacker gains administrative access to a FortiGate firewall and begins making configuration changes to establish persistence and enable future access. Individually, each action may appear legitimate. Together, however, they form a potentially suspicious behavioral pattern. UEBA then layers anomaly insights and explainability on top of these Behaviors, providing the additional context needed to identify suspicious activity.

Examples of observed behaviors include:

Firewall administrator signs in from a new geographic location.
Configuration changes occur outside normal maintenance windows.
A new administrator account is created.
VPN settings or firewall rules are modified to enable new access paths.
Unusual outbound traffic is detected through the FortiGate device.

Rather than presenting these as isolated events, UEBA enriches each behavior with anomaly insights and explainable context. Analysts can immediately understand why the activity stands out. For example, because the administrator has never performed this combination of actions before, the changes occurred at an unusual time, and multiple high-risk modifications happened within a short period. This helps security teams quickly identify high-risk activity, reduce investigation time, and respond before attackers can expand their access within the environment.

KQL examples

//Query 1: Logon and Configuration Change by user for the first time BehaviorInfo | where Timestamp > ago(30d) | where ActionType == "BehaviorFortiGateReconfiguration" | where Insights has "FirstSeen" | extend AdditionalFields = todynamic(AdditionalFields) | extend Hostname = AdditionalFields.ApplianceId | extend User = AdditionalFields.ChangedBy[0] | extend uebaEnrichments = AdditionalFields ["ueba.enrichments"] | extend uebaInsights = todynamic(Insights).Explainability | project ActionType, Description, Categories, AttackTechniques, ServiceSource, DataSources, User, Hostname, AdditionalFields, uebaInsights, uebaEnrichments //Query 2: get HighVolumeAnomaly behaviors to detect high traffic for the suspicious host / IP BehaviorInfo | where Timestamp > ago(30d) | where DataSources has "CommonSecurityLog" | invoke GetAnomalousBehaviorsByValue( "<Hostname>", //Extracted from Hostname in query 1 "HighVolumeAnomaly")

Expanding visibility scross the environment—use cases

The following examples show how the new network data sources extend Behavioral analytics and UEBA Anomalies, helping uncover suspicious activity across more of your environment.

Scenario: Identifying suspicious web access with Zscaler telemetry

A user attempts to access a URL categorized as phishing, malware, spyware, or command-and-control. On its own, the event may appear as just another web-proxy log among thousands generated every day.

With Zscaler telemetry incorporated into behavioral analytics, UEBA identifies that the user has never accessed this high-risk URL category before and enriches the activity with user, destination, source IP, location, ISP, and threat intelligence context, helping analysts immediately understand why the event stands out. Rather than investigating an isolated web access event, analysts can quickly determine whether the activity indicates a phishing attempt or attacker-controlled infrastructure and respond before the compromise spreads.

KQL example

//Query 3: First-time high-risk web category access from an unusual location or ISP Returns phishing, malware, spyware, or C2 category hits that are new for the user and come from an unusual location or network. Check RequestURL and UrlCategory for the destination. BehaviorAnalytics | where TimeGenerated > ago(7d) | where EventSource == "CommonSecurityLog" | where ActivityType == "UnusualHighRiskWebCategoryAccess" | where ActivityInsights.DeviceVendor == "Zscaler" | where ActivityInsights.DeviceProduct == "NSSWeblog" | extend UrlCategory = ActivityInsights.UrlCategory | extend RequestURL = ActivityInsights.RequestURL | extend ISP = DevicesInsights.ISP | extend ThreatIntel = DevicesInsights.ThreatIntelIndicatorType | extend RiskyCategory = ActivityInsights.FirstTimeUserAccessedHighRiskUrlCategory == True or ActivityInsights.FirstTimeHighRiskUrlCategoryObservedInTenant == True | extend UnusualLocation = ActivityInsights.FirstTimeUserConnectedFromCountry == True or ActivityInsights.FirstTimeConnectionFromCountryObservedInTenant == True or ActivityInsights.CountryUncommonlyConnectedFromByUser == True | extend UnusualISP = ActivityInsights.FirstTimeUserConnectedViaISP == True or ActivityInsights.ISPUncommonlyUsedByUser == True or ActivityInsights.IPRegOrgUncommonlyUsedByUser == True | where RiskyCategory and (UnusualLocation or UnusualISP or isnotempty(ThreatIntel))

The following example illustrates how Behaviors built on top of new network data source help analysts identify sensitive administrative activity that might otherwise appear routine.

Scenario: Identifying suspicious FortiGate configuration backups

A network administrator exports a FortiGate configuration backup. On its own, this action is common during maintenance, upgrades, or disaster recovery and is unlikely to trigger immediate investigation.

With Behaviors built on top of Fortinet telemetry, Microsoft Sentinel transforms this raw administrative event into a meaningful security context. Analysts can immediately see who performed the backup, which device was involved, how it was executed (GUI, API, RESTAPI, ssh or CLI), and whether the activity deviates from the user's normal behavior or occurred alongside other suspicious activity.

Instead of reviewing isolated firewall events, analysts can quickly determine whether the configuration export is part of legitimate administration or an early indicator of compromise, reconnaissance, or preparation for persistence.

KQL example

// Query 4: FortiGate configuration backup activity BehaviorInfo | where ActionType == "BehaviorFortiGateBackup" | extend ParsedData = parse_json(AdditionalFields) | extend Device = tostring(ParsedData.ApplianceId), User = tostring(ParsedData.Account), SourceIP = tostring(ParsedData.LoginSourceIP) | project TimeGenerated, Device, User, SourceIP, Description, AdditionalFields | order by TimeGenerated

Getting started

In the Microsoft Defender portal, make sure the Behaviors layer is enabled and supported data sources are connected
Baselines are built for approximately one week for high-quality anomalies.
Explore the insights column in the BehaviorInfo table in Advanced Hunting.
Enabling the new data sources for UEBA and Behaviors layer:

UEBA user interface.

We’d love to hear how your team is using these capabilities. Share your feedback to help us improve and expand coverage.

Why it matters

These updates represent another step in our commitment to making Behaviors and UEBA in Microsoft Sentinel more powerful, more explainable, and more broadly applicable across the environments your security team defends.

Public Preview: Nested API Support Comes to Microsoft Sentinel CCF

Robert_Moriarty — Fri, 07 Aug 2026 17:15:55 GMT

Microsoft Sentinel continues to evolve its capabilities to support an expanding ecosystem of partners and data integrations. Recent innovations include the Codeless Connector Framework (CCF) Push feature, the new Sentinel connector builder agent, and the CCF expansion to pull data from Azure Storage Blob. Each of these reflects our ongoing investment in making it easier for ISVs and developers to build scalable, high-fidelity data connectors that bring telemetry into Sentinel data lake.

Today, we are excited to announce another advancement in this journey – the public preview for Nested API support in CCF.

What is Nested API support and Why it Matters

Nested API support enables a pattern common across many ISV log sources, where a single polling cycle spans multiple dependent API calls: an initial call returns a list of records (such as alert IDs or case references), and one or more follow-up calls fetch the full detail for each record in that list.

This support allows CCF to accommodate the list-then-detail API pattern as it exists in many API designs, so that partners don’t need to restructure or adapt their endpoints. The result is broader integration coverage that allows partners to connect data sources whose APIs are naturally paginated across multiple calls, and then to ingest complete records into Microsoft Sentinel without building custom middleware.

Support for Nested API in the Microsoft Sentinel VS Code extension

This pattern is also available through the Visual Studio Code (VS Code) extension for Microsoft Sentinel connectors. The extension is an agentic tool that helps ISVs and partners build, test, and package data connectors more efficiently, providing a guided experience for bringing data into Microsoft Sentinel.

As part of its design, the extension enables developers to implement Nested API workflows, allowing connectors to orchestrate multi-step API calls and support APIs that require chained or dependent requests. To learn more, see the Sentinel connector builder agent blog and the Microsoft Learn documentation for implementation guidance.

Real-world adoption: Early ISV implementations

A growing set of solutions are already leveraging Nested API support to enable multi-step data retrieval scenarios. These early implementations demonstrate how partners are using this capability to structure connector workflows around their existing APIs. Some of the early adopters and their solutions are listed below.

BigID

BigID integrates with Microsoft Sentinel to extend data security posture management (DSPM) insights into security operations workflows. The solution brings visibility into sensitive, regulated, and critical data across cloud, SaaS, and on‑premises environments, helping security teams understand data‑related risk and exposure. Built on the Codeless Connector Framework (CCF), the integration can leverage capabilities such as Nested API retrieval to ingest more detailed, context‑rich records through multi‑step API calls, supporting more informed investigation and prioritization.

Cisco Email Threat Defense

Cisco Email Threat Defense integrates with Microsoft Sentinel to bring email‑borne threat detections into centralized security operations. The connector ingests all information that can be used as security signals, such as phishing and malware indicators, enabling teams to correlate email activity with broader incidents and improve investigation and response. Built on the Codeless Connector Framework (CCF), the integration supports advanced patterns like Nested API retrieval, allowing more detailed event context to be ingested through multi‑step API calls without requiring changes to the underlying data source.

Idira Audit

Idira® Audit by Palo Alto Networks integrates with Microsoft Sentinel to centralize visibility into privileged identity and access activity. By streaming detailed audit logs—covering system events, user actions, and administrative activity—into Sentinel, security teams can correlate identity‑driven risks with broader security telemetry. Built on the Codeless Connector Framework (CCF), the integration can leverage capabilities such as Nested Application Programming Interface retrieval to ingest more detailed, context‑rich records, supporting faster investigation and more effective response.

In addition to these early third-party adopters, some Microsoft-built connectors that also leverage this pattern are listed below:

Build with Nested APIs in Microsoft Sentinel

Developers and partners can begin leveraging Nested API support today as part of the Codeless Connector Framework. To get started, review the Microsoft Learn documentation for implementation guidance and explore existing connector configurations that demonstrate this pattern. You can also jump right in and explore building with mock data using our Nested API Lab.

As Microsoft Sentinel continues to expand its ecosystem, App Assure works closely with partners to help onboard and optimize integrations. If you are building or extending a connector and would like support, the App Assure team is available to help you get started. Reach out to us via our intake form.

Additional Sentinel Feature Public Preview Announcements

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

Robert_Moriarty — Wed, 05 Aug 2026 16:00:00 GMT

This post walks through building a Microsoft Sentinel Codeless Connector Framework (CCF) RestApiPoller connector that uses the nested API polling pattern. The nested pattern exists for a specific reason: many enterprise APIs do not return enriched records from a single call. Instead, they use a two-step model: a list endpoint that returns identifiers, followed by a detail endpoint that accepts one identifier and returns the full record. Without native support for this pattern, building a Sentinel connector for such an API means writing custom orchestration in code. The CCF nested pattern re places that with a JSON configuration that the engine handles directly.

The lab is built around a mock Contoso Incident API hosted as an Azure Function App. The purpose is to give you a live API you can deploy, inspect, and connect to Sentinel without needing a real product. Once deployed, you will walk through each of the four connector files that make up the integration (the poller config, the DCR, the table schema, and the connector definition) and see exactly how the two-call chain is wired together. By the end of the walkthrough, you will have a working connector ingesting enriched incident records into ContosoIncidents_CL in your Sentinel workspace.

Lab repository: CCF Pull Connector - Nested API Accelerator: clone the repository, then deploy the mock API and connector with a single Copilot prompt. See the README for full instructions. (link to be confirmed on merge)

Related documentation: CCF Nested API Polling Reference

Quick Start

Already familiar with CCF nested polling?

Complete these sections:

Prerequisites
Deploying the Mock API
Deploying the Sentinel Connector
Enabling and Verifying Data

The remaining sections explain how the nested polling configuration, KQL extraction, DCR transform, and connector artifacts work behind the scenes.

Prerequisites

Before starting, make sure you have the following:

Azure subscription with Contributor access on a resource group for deploying the Function App, and Microsoft Sentinel Contributor on a Sentinel-enabled workspace for deploying the connector
Microsoft Sentinel workspace: an existing Log Analytics workspace with Sentinel enabled (Quickstart: Onboard Microsoft Sentinel)
Azure CLI (Install the Azure CLI) installed and authenticated
VS Code with GitHub Copilot installed if you want to use the one-prompt agent deployment option
Lab repository: clone the CCF Pull Connector - Nested API Accelerator repository locally

The Lab Environment

The mock Contoso Incident API exposes exactly the two-endpoint pattern the nested connector is designed for. The list endpoint returns a set of incident identifiers scoped to a time window. The detail endpoint accepts a single identifier and returns the full enriched record for that incident. There is no way to get the full records in a single call; you have to ask for them one at a time.

A call to the list endpoint looks like this:

{ "incidents": [ { "incidentId": "INC-001" }, { "incidentId": "INC-002" }, { "incidentId": "INC-003" }, { "incidentId": "INC-004" }, { "incidentId": "INC-005" } ] }

And a call to the detail endpoint for INC-00 returns:

{ "incidentId": "INC-001", "title": "Suspicious login attempt", "severity": "High", "status": "Active", "affectedUser": "alice@contoso.com", "sourceIp": "198.51.100.42", "createdAt": "2026-05-30T14:22:00Z" }

So for every polling cycle the connector needs to call the list endpoint once, extract the five incidentId values, and then call the detail endpoint five times. That fan-out logic (taking a value from the first response and injecting it into the URL for each subsequent call) is what the nested step configuration handles. The repo contains everything needed for the walkthrough: an ARM template to deploy the Function App, the four connector artifact files, and a solution package that deploys the connector into Sentinel.

Deploying the Mock API

The quickest way to deploy is to open Copilot Chat in Agent mode in VS Code and paste:

Load and follow the deployment instructions at Tools/CCF-Pull-Connector-Nested-Accelerator/agent-instructions.md. Let's deploy a CCF nested API connector.

The agent reads the deployment instructions, collects the values it needs, generates names for anything you do not provide, and deploys end-to-end. The only manual action in the entire flow is clicking Connect in the Sentinel portal once the ARM template has been deployed.

If you prefer to deploy manually, the steps are straightforward. Create a resource group, deploy the Function App using the included ARM template, zip the MockApi/ folder and push the code, then retrieve the Function App API key:

az group create --name contoso-mock-api-rg --location eastus az deployment group create ` --resource-group contoso-mock-api-rg ` --template-file "Tools/CCF-Pull-Connector-Nested-Accelerator/MockApi/azuredeploy_MockApi.json" ` --parameters FunctionAppName=ContosoMockApi Location=eastus $outputs = az deployment group show ` --resource-group contoso-mock-api-rg --name azuredeploy_MockApi ` --query properties.outputs -o json | ConvertFrom-Json $functionAppName = $outputs.functionAppName.value $mockApiBaseUrl = $outputs.mockApiBaseUrl.value Compress-Archive -Path "Tools/CCF-Pull-Connector-Nested-Accelerator/MockApi/*" -DestinationPath contosoapi.zip -Force az functionapp deployment source config-zip --name $functionAppName --resource-group contoso-mock-api-rg --src contosoapi.zip $apiKey = (az functionapp keys list --name $functionAppName --resource-group contoso-mock-api-rg --query functionKeys.default -o tsv).Trim()

Once deployed, verify both endpoints are responding before moving on:

Invoke-RestMethod "$mockApiBaseUrl/incidents" -Headers @{"x-functions-key" = $apiKey} Invoke-RestMethod "$mockApiBaseUrl/incidents/INC-001/details" -Headers @{"x-functions-key" = $apiKey}

How the Nested Step Pattern Works

The entire two-call chain lives inside ContosoIncidents_PollerConfig.json. Here is the full config:

{ "type": "Microsoft.SecurityInsights/dataConnectors", "kind": "RestApiPoller", "properties": { "connectorDefinitionName": "ContosoIncidentsConnector", "dataType": "ContosoIncidents_CL", "dcrConfig": { "streamName": "Custom-ContosoIncidents_CL", "dataCollectionEndpoint": "{{dataCollectionEndpoint}}", "dataCollectionRuleImmutableId": "{{dataCollectionRuleImmutableId}}" }, "auth": { "type": "APIKey", "ApiKey": "{{ApiKey}}", "ApiKeyName": "x-functions-key" }, "request": { "apiEndpoint": "{{mockApiBaseUrl}}/incidents", "httpMethod": "GET", "queryWindowInMin": 5, "queryTimeFormat": "yyyy-MM-ddTHH:mm:ssZ", "startTimeAttributeName": "startTime", "endTimeAttributeName": "endTime", "headers": { "Accept": "application/json" } }, "response": { "eventsJsonPaths": [ "$.incidents" ], "format": "json" }, "stepInfo": { "stepType": "Nested", "nextSteps": [ { "stepId": "fetchIncidentDetails", "stepPlaceholdersParsingKql": "source | project res = parse_json(data) | project incidentId = res.incidentId" } ] }, "stepCollectorConfigs": { "fetchIncidentDetails": { "shouldJoinNestedData": false, "request": { "httpMethod": "GET", "apiEndpoint": "{{mockApiBaseUrl}}/incidents/$incidentId$/details", "headers": { "Accept": "application/json" } }, "response": { "eventsJsonPaths": [ "$" ], "format": "json" } } } } }

The request block at the top defines the parent call, the list endpoint. On every polling cycle the CCF engine calls GET /incidents with startTime and endTime query parameters derived from queryWindowInMin: 5. The response.eventsJsonPaths: ["$.incidents"] tells the engine where to find the data in the response; it walks to the incidents array and treats each element as a separate row.

Those rows do not go to the DCR. Instead, because stepInfo.stepType is set to "Nested", the engine passes each row to the stepPlaceholdersParsingKql expression before doing anything else.

The KQL That Links the Two Calls

This is the most important line in the entire connector:

source | project res = parse_json(data) | project incidentId = res.incidentId

Each row from the list response arrives as raw JSON in a column called data. The parse_json(data) call converts that string into a dynamic object so individual fields can be addressed. The final project extracts incidentId and gives it a column name. That column name, incidentId, is not arbitrary. It must exactly match the $incidentId$ token in the child endpoint URL. The engine reads the output of this expression, takes every value in the incidentId column, and substitutes it into the URL for the next step.

For the Contoso API this produces five values (INC-001 through INC-005), and the engine issues five parallel GET requests:

GET /api/incidents/INC-001/details GET /api/incidents/INC-002/details GET /api/incidents/INC-003/details GET /api/incidents/INC-004/details GET /api/incidents/INC-005/details

Each of those calls returns a full incident record. The eventsJsonPaths: ["$"] in the child response block captures the entire response body as a single event. Those five events are what get sent to the DCR stream, not the five lightweight rows from the list call.

shouldJoinNestedData

The shouldJoinNestedData: false setting on the child step tells the engine not to merge the parent row's fields into the child row before sending to the DCR. In this case the detail response already contains incidentId and all other required fields, so there is nothing to carry forward from the parent. If your list endpoint returns fields that are not present in the detail response (a category, a tenant identifier, a product namespace), setting this to true will merge them in automatically.

The DCR and the KQL Transform

The Data Collection Rule handles what happens to each detail response once it arrives at the Data Collection Endpoint. The streamDeclarations block defines the inbound schema (the shape of the data the CCF engine sends), and the transformKql maps it to the destination table columns.

The transform for this connector is:

source | extend TimeGenerated = now() | project TimeGenerated, IncidentId = ['incidentId'], Title = ['title'], Severity = ['severity'], Status = ['status'], AffectedUser = ['affectedUser'], SourceIp = ['sourceIp']

The extend TimeGenerated = now() sets the ingestion timestamp. The mock API returns a createdAt field on every detail record, but it is not used here; TimeGenerated reflects when the record was received by the pipeline rather than when the incident was created on the source system. The project operators rename each snake_case field from the API response to the PascalCase column names defined in the table schema.

The column names produced by transformKql must exactly match the column names in ContosoIncidents_Table.json. A mismatch causes rows to be silently dropped at ingestion with no error surfaced to the connector status page, which makes it one of the more frustrating issues to debug after the fact.

The Table Schema and Connector Definition

Before looking at the connector definition, it helps to understand what the table object itself is. ContosoIncidents_Table.json deploys a Microsoft.OperationalInsights/workspaces/tables resource, the same resource type that creates any custom log table in your Log Analytics workspace. Its schema block is an array of column definitions, each with a name, a type, and a description:

"schema": { "name": "ContosoIncidents_CL", "columns": [ { "name": "TimeGenerated", "type": "datetime", "description": "Ingestion timestamp." }, { "name": "IncidentId", "type": "string", "description": "Unique identifier of the incident (e.g. INC-001)." }, { "name": "Severity", "type": "string", "description": "Incident severity: Critical, High, Medium, or Low." } ] }

This is the definition that shows up when you query the table. Each column name becomes a field you can reference directly in KQL, and each column type determines how that field behaves when you filter or aggregate on it. TimeGenerated being a datetime is what lets you sort or filter with operators like ago() and between.

The table schema in ContosoIncidents_Table.json defines ContosoIncidents_CL with seven columns: TimeGenerated, IncidentId, Title, Severity, Status, AffectedUser, and SourceIp.

The connector definition in ContosoIncidents_ConnectorDefinition.json drives the portal UI. It defines the connector page title and description, the ingestion activity graph, the sample KQL queries that are surfaced to analysts directly from the connector page, and the connectivity check query that determines whether the connector shows as Connected or Disconnected in the Data Connectors blade. The two Textbox inputs in the instructionSteps block (mockApiBaseUrl and ApiKey) are what feed the {{template}} variables in the poller config when a user clicks Connect. Getting those input names right is what makes the credential handoff from the portal to the connector work without manual intervention.

Deploying the Sentinel Connector

With the mock API running, deploy the Sentinel connector solution using the included mainTemplate.json. The template creates the Data Collection Endpoint, the ContosoIncidents_CL table, the DCR, the poller config, and the connector definition in the correct dependency order.

If you would rather not use the CLI, you can deploy the same template through the Azure portal. Open the Custom deployment blade, choose "Build your own template in the editor," and paste in the contents of mainTemplate.json, then fill in the parameters (workspace, workspace-location, and so on) through the generated form instead of a parameters file. See Deploy template - Azure portal - Azure Resource Manager for the full walkthrough. The CLI steps below are the faster path if you already have the CLI authenticated, but the portal works just as well.

The workspace-location parameter requires special handling because the hyphen in the parameter name causes issues when passed inline to the Azure CLI. Write a parameters file first, then reference it with @:

@{ '$schema' = 'https://schema.management.azure.com/schemas/2019-04-01/deploymentParameters.json#' contentVersion = '1.0.0.0' parameters = @{ workspace = @{ value = '<your-workspace-name>' } 'workspace-location' = @{ value = '<region>' } } } | ConvertTo-Json -Depth 5 | Out-File deploy-params.json -Encoding utf8 az deployment group create ` --resource-group <sentinel-workspace-rg> ` --name mainTemplate ` --template-file "Tools/CCF-Pull-Connector-Nested-Accelerator/ContosoIncidents/Package/mainTemplate.json" ` --parameters "@deploy-params.json" ` --output table</sentinel-workspace-rg></region></your-workspace-name>

The workspace-location value must exactly match the region string returned by az monitor log-analytics workspace show --query location for your workspace.

Enabling and Verifying Data

The ARM deployment registers the connector definition but does not start data collection. To start polling you need to click Connect once in the portal. Navigate to your Sentinel workspace via security.microsoft.com, go to Data Connectors, and find Contoso Incidents (CCF Nested API Accelerator). If it is not immediately visible, click Refresh and wait two to three minutes for the deployment to propagate.

Open the connector page and under STEP 2 - Connect to the Contoso Mock API, enter the mockApiBaseUrl from the deployment output and the ApiKey retrieved earlier, then click Connect. The CCF engine begins polling immediately.

Allow five to ten minutes for the first poll cycle to complete, then confirm data is arriving:

ContosoIncidents_CL | sort by TimeGenerated desc | take 10

You should see five rows, one per mock incident, with all columns populated. From there you can use the sample queries built into the connector page to start exploring the data:

// High and Critical incidents ContosoIncidents_CL | where Severity in ('Critical', 'High') | sort by TimeGenerated desc // Active incidents with source IP ContosoIncidents_CL | where Status == 'Active' | project TimeGenerated, IncidentId, Title, Severity, AffectedUser, SourceIp

Adapting This Pattern to Your Own API

The nested pattern is reusable for any two-tier REST API. The changes needed to adapt the accelerator are mechanical: replace the parent endpoint and update eventsJsonPaths to point to your identifier array, rewrite the stepPlaceholdersParsingKql to extract your identifier field (the column name in the final project must match the $token$ in your child URL), replace the child endpoint URL, and update the DCR stream declaration, transform, and table schema to match your detail response fields.

The shouldJoinNestedData flag is worth thinking through for your specific case. If your list endpoint returns context that is not replicated in the detail response (a tenant ID, a data source label, a parent category), set it to true and those fields will be merged into every child row automatically before it reaches the DCR.

Next Steps

Review the CCF Nested API Polling Reference for the full specification of stepInfo, stepCollectorConfigs, shouldJoinNestedData, and multi-level nesting: CCF Nested API Polling Reference

Review the codeless connector documentation for the full range of supported auth types, pagination patterns, and incremental pull strategies: Create a codeless connector

Explore the Microsoft Sentinel content hub to see how published connectors are structured and what the certification requirements look like for production submissions.

Conclusion

Following these steps, you saw how a CCF nested API connector works at the configuration level: how the stepPlaceholdersParsingKql expression extracts identifier values from the list response, how those values are substituted into the child endpoint URL to produce per-record detail calls, and how the DCR transform maps the raw API fields into a clean Sentinel table. The pattern is deliberately simple to adapt: the KQL expression and the $token$ in the URL are the only two moving parts that link the two calls together.

If you are an ISV building a Sentinel integration and want hands-on support, Microsoft's App Assure program is available to help with connector development, validation, and readiness for production. You can get started by reaching out through our intake form.

What’s new in Microsoft Sentinel: July 2026

vkokkengada — Fri, 31 Jul 2026 16:00:00 GMT

Welcome back to What's new in Microsoft Sentinel. In July, Sentinel adds custom detections support in Sentinel repositories, so you can manage detections as code alongside your analytics rules, playbooks, parsers, and workbooks, authoring in GitHub and deploying through the CI/CD pipelines you already use. In Sentinel data lake, table insights brings table-level observability into the Microsoft Defender portal, helping you track ingestion volume, spot week-over-week changes, and catch connectors that have gone silent, all without running a single KQL query. Connector coverage also expands with GitHub Audit logs, Agari, and Airlock Digital, bringing more of the signals that matter to you into one place.

Read on for the details, and if you're joining us at Black Hat USA 2026, don't miss the keynote from Agentic Security CVP David Weston and other Microsoft Security activities at this event. Explore our resources at the end to go deeper.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake

Sentinel SIEM

Custom detections support in Sentinel repositories [Public Preview]

Custom detections can be managed as code through Sentinel repositories, alongside analytics rules, playbooks, parsers, and workbooks, completing the detections-as-code workflow across the full Sentinel portfolio. Teams can author detections in GitHub, review through pull requests, and deploy via existing CI/CD pipelines or the Microsoft Security Bicep extension. Learn how to manage custom content with repository connections.

Behind the Build with Gigamon: Enriching Sentinel with network-derived telemetry

Learn how Gigamon's integration with Sentinel brings network-derived telemetry into your security investigations, correlated with the identity, endpoint, and cloud signals already in your workspace. By adding this runtime context, you can trace suspicious activity across environments and investigate threats that span traditionally siloed domains, with faster and more accurate investigations, higher-quality signal, and clearer visibility into encrypted and hybrid cloud traffic that logs alone often miss. Read the blog to explore the integration and what it means for your security operations.

Sentinel data lake

Table insights [Public Preview]

Table insights is a built-in monitoring view on the tables page in the Microsoft Defender portal that gives you table-level observability for your Sentinel workspace without running KQL queries or opening a separate workbook.

Table insights surfaces the signals you rely on most:

📊 Ingestion volume by tier – compare analytics versus data lake
📉 Day-over-week ingestion fluctuations – spot drops or spikes against the same day last week
🔝 Top 5 tables by daily ingestion volume – identify your biggest cost drivers at a glance
🕐 Last data received – catch connectors that stopped sending data
💰 Estimated daily ingestion cost – per-table cost to inform tier and retention decisions
⚠️ Volume anomaly – signed percentage change versus baseline to flag unusual behavior early

Figure 1: View all table insights and investigate your table behavior with Sentinel in the Defender portal.

Together, these signals help you spot collection failures early, so you can act before they turn into bigger problems. Learn more.

Connectors [Public Preview]

GitHub Audit logs (via Azure Storage Blob)

The GitHub Audit logs connector ingests GitHub Enterprise audit logs into Sentinel from Azure Blob Storage with near real-time latency, so you can view this data in workbooks, create custom alerts, and strengthen your investigations. This requires Audit log streaming to be set up on GitHub for an Enterprise. Learn how to stream audit logs.

Agari

The Agari Data connector allows ingesting logs from Agari APIs into Sentinel. This connector integrates with Agari Brand Protection (BP) and Phishing Defense (APD). It supports Data Collection Rules-based ingestion time transformations for efficient query execution.

Airlock Digital

Ingests Airlock Digital application control and execution events to strengthen endpoint threat detection and response.

Additional resources

Blogs and documentation:

Upcoming events:

Featured event: Aug 1–6, Black Hat USA 2026 (Mandalay Bay, Las Vegas)

Keynote with Agentic Security CVP David Weston
The end of rare: Defending when offense is cheap
Wednesday, Aug 5 | 9:15 AM – 10 AM
Main stage with Microsoft Security CVP Aarti Borkar and Microsoft Security Research VP Tanmay Ganacharya
Poisoned at the source: Inside Microsoft Threat Intelligence's hunt for supply chain attacks
Wednesday, Aug 5 | 2:30 PM – 3 PM
Main stage with Customer Success GM Wes Malaby
Mind the gap: Turning threat intelligence into decisive action with expert-led defense
Wednesday, Aug 5 | 11:25 AM – 11:45 AM
Mandalay Bay K with Principal Product Manager Naadia Sayed
Agentic security: What's next
Wednesday, Aug 5 | 11:15 AM – 12 PM
Microsoft Security Black Hat USA 2026 VIP mixer hosted by Microsoft Security CVP Aarti Borkar
Swingers at Mandalay Bay Resort – Register here
Wednesday, Aug 5 | 6 PM – 9 PM
Microsoft booth #2144 with live sessions, AMAs, and hands-on demos of our latest security innovations
Learn more in our Black Hat 2026 blog

Upcoming webinars:

Aug 6: Security Immersion Event: Into the Breach
Aug 13–14: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats
Aug 19: Microsoft Security Immersion Event: Shadow Hunter
Aug 20: Microsoft Security Immersion Event: Agent Hackathon
Aug 25: Tech Brief: Modernize security operations with a unified platform

Stay connected

Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!

Announcing the ASIM Parser Creation Agentic Experience

derricklee — Wed, 15 Jul 2026 16:00:00 GMT

Creating high-quality ASIM parsers has always required deep knowledge about source data and ASIM schemas, careful KQL design, and repeated validation cycles. That process is meaningful to understand the whole Sentinel ecosystem, but it can be slow when you are starting from raw source data and trying to get to a production-ready parser.

Today, we are introducing a new agentic experience available now as open source that helps security teams move faster: an AI-guided workflow for creating ASIM parsers end to end.

Why this matters

ASIM parsers are the normalization layer that makes detections, hunting, and analytics portable across data sources. They are foundational, but building them involves many steps:

Gathering source requirements and schema targets
Authoring a parameter-less and a parameterized ASIM parser
Validating schema conformance and data quality
Packaging the parsers into a GitHub pull request for open-source contributions

ASIM normalization is important because it gives security teams a common language across different products and log formats. Without normalization, every detection, hunting query, and workbook has to be rewritten per vendor table, which increases engineering effort and creates blind spots when data sources change. With ASIM, the same analytic logic can operate across multiple sources through consistent field names and semantics.

This directly improves security outcomes by enabling faster content reuse, easier cross-source correlation, and more reliable incident triage. It also reduces long-term maintenance costs, because teams update parsers at the query and mapping layer instead of rewriting detection content each time a connector changes.

The new agentic experience orchestrates those steps for you with clear checkpoints and repeatable outputs.

What is the ASIM parser creation agentic experience?

The experience is built around a specialized set of skills that work together as a workflow. Instead of using a single prompt and hoping for the best, the agent walks through parser creation as a structured process.

At the center is the orchestration skill that coordinates:

Requirement collection
Parser generation
Validation loops that test the parser schema and data outputs
Optional deployment to Log Analytics and PR packaging for Azure-Sentinel

Where can I find these skills?

If you have cloned or forked the Azure-Sentinel repository, the skills are already there! All you need is GitHub Copilot CLI to get started. For more information, you can visit the README or our Learn Docs.

Another way to access these skills is through our Microsoft Sentinel Visual Studio Code Extension. You can simply chat with GitHub Copilot with your intention to create ASIM parsers, and it will call its loaded skills.

What you can expect in practice

When you start with a request like "Create a new ASIM parser for my source table" the agent can:

Gather critical inputs
Build the initial ASIM parser from source requirements
Run schema and data validation
Refine the parser in a loop until error-level findings are resolved (or report remaining blockers)
Build the matching parameterized parser and re-validate
Help deploy or package your parsers into a PR to contribute to open-source

Where this helps most

This workflow is especially useful when:

Data is already flowing into Sentinel, but there are no supporting ASIM parsers yet
Migrating legacy parsing logic to ASIM conventions
Creating a parser needs to happen with almost no delay, without sacrificing validation confidence

It will also reduce onboarding time for analysts who are new to ASIM but comfortable with KQL and Sentinel operations.

Closing

The ASIM parser creation agentic experience is not about replacing engineering judgment. It is about amplifying it.

If you are building ASIM parsers today, now is the right time to pilot an agentic workflow and shape what comes next.

If you are new to ASIM, getting started with parsers is easier than ever. The guided agentic flow walks you through requirements, parser generation, and validation step by step, so you can learn the ASIM model while still producing useful, high-quality parser outputs quickly.

Building toward an Agentic SOC: A Portable, Autonomous Malware Investigation Agent

absharan — Mon, 13 Jul 2026 19:09:25 GMT

Modern Security Operations Centers are not short on tools. They are short on continuity. Analysts jump from alert consoles to data exploration, from enrichment to investigation, and from evidence gathering to response—often across multiple interfaces and disconnected workflows.

A single malware incident may begin in Microsoft Sentinel, require enrichment in Defender, depend on targeted KQL hunting, and end with manual response actions somewhere else. Every handoff adds friction. Every context switch slows triage. And every inconsistency increases the risk of missed signals or delayed containment.

To explore what an Agentic SOC could look like in practice, I built a portable, autonomous malware investigation agent: a user-invocable workflow that takes an incident from investigation to evidence correlation to verdict and, when appropriate, to action.

The goal is simple: one prompt, one workflow, and a full incident lifecycle that moves cleanly from Investigate to Decide to Act.

The Real Problem: SOC Work Is Still Too Fragmented

In a conventional malware investigation, even experienced analysts spend too much time stitching the workflow together:

Pivoting across Sentinel and Defender
Manually extracting entities
Writing and optimizing multiple KQL queries
Context switching between tools
Making decisions with incomplete evidence

The operational impact is familiar to every SOC team:

Increased MTTR
Analyst fatigue
Inconsistent investigation quality

This fragmentation is exactly what a unified Microsoft Sentinel and Defender experience is built to solve, and it is where such an investigation agent demonstrates its value.

The Approach: A Portable Agent for End-to-End Malware Investigations

The agent is designed to handle the full investigation loop—not just enrichment, not just summarization, and not just response orchestration.

End-to-end malware investigation
Evidence-based verdicting
SOC-ready summarization
Optional automated response

Because it is defined as a portable agent, the same investigation pattern can be reused across environments with consistent logic, standardized outputs, and controlled automation boundaries.

Standardized investigations
Repeatable execution
Controlled automation
Cross-environment portability

Architecture Overview (End-to-End Flow)

Visual 1: Agentic SOC Investigation Workflow

User / Analyst Input
“Investigate Incident”

↓

SOC AI Agent
Portable Investigator

↓

Microsoft Sentinel
SecurityIncident • SecurityAlert • Data Lake (KQL)

↓

Entity-Driven Queries
Device • User • File • IP

↓

Evidence Correlation

↓

Verdict + Summary
True Positive • False Positive • Benign True Positive

↓

Optional Actions
Comment • Tag • Isolate

How the Agent Works: A Practical Deep Dive

Prerequisites

VS Code with GitHub Copilot
Microsoft Sentinel MCP server (provides the Triage and Data Lake exploration tools the agent runs on)
Microsoft Defender for Endpoint data (for the Device* hunting tables)
API permissions for any response action (e.g. endpoint isolation)

1. Input & Trigger

The workflow starts with a simple natural-language prompt, for example:

Investigate Defender incident 1939

The input includes:

Defender Incident ID
Optional Sentinel workspace

2. Sentinel-First Investigation

The first design choice is deliberate: the agent starts from Sentinel as the investigation plane, within the Unified Defender Portal, where incidents are correlated across Sentinel and Defender, using it to retrieve incident structure, alert context, severity, timelines, and alert relationships before moving deeper.

Queries:

SecurityIncident
SecurityAlert

Extracts:

Severity
Timeline
Alert relationships

This ensures:

Consistent data plane
Reduced dependency on multiple APIs

3. Entity-Driven Correlation

Instead of launching broad hunts across the environment, the agent narrows the scope using the entities already present in the incident. That makes the investigation faster, cheaper, and more precise.

Extracts entities:

Device
User
File hash
IP/URL

Runs targeted queries only

Example tables:

DeviceProcessEvents
DeviceFileEvents
DeviceNetworkEvents

This is critical for:

Performance

Cost control

Precision

Visual 2: From Incident to Correlated Evidence

Incident	Alerts	Entities	Targeted Queries	Evidence
Incident 1939	Malware detection	device123 userA file.exe	DeviceProcessEvents DeviceFileEvents DeviceNetworkEvents	Correlated execution, origin, and network signals

4. Evidence-Based Verdict

Once the signals are correlated, the agent produces one of three explicit outcomes—grounded in evidence rather than guesswork.

True Positive
False Positive
Benign True Positive

The verdict is:

Based on evidence only
Not guess-driven
Not heuristic overreach

5. SOC-Ready Output Standardization

The final output is intentionally standardized so an analyst can review the outcome quickly, understand the reasoning, and decide what happens next.

One-line verdict
ASCII findings table
Analyst summary
Actions taken
Optional containment recommendation

Visual 3: Standardized Investigation Output

Verdict: True Positive
Category	Findings
Incident Details	Severity: High
Malware Details	Trojan X detected
Device Posture	Real-time protection enabled
User Context	Standard user
Observed Activity	Suspicious process tree
Recommendation	Isolation recommended

Summary

Malware execution confirmed.
Blocked by Defender.
No lateral movement observed.

Actions Taken

Comment added.
Tag applied.
Awaiting isolation decision.

Optional Response & Containment

If permissions are available, the agent can:

Add incident comments
Tag incidents
Update classification
Close incidents
Perform endpoint isolation (gated with human in the loop)

With strict safeguards:

Evidence-backed decisions
Permission validation
Audit traceability

Visual 4: Workspace Portability Logic

Decision Point	Outcome
Workspace provided?	Yes → Use the specified workspace.
Workspace provided?	No → Detect available workspaces.
Only one workspace available?	Yes → Use it automatically.
Multiple workspaces available?	Ask the user to select one.
Missing permissions?	Fall back to read-only behavior.

Security & Operational Rigor

The agent enforces:

No secret storage
Use of existing authentication context
Clear reports of missing permissions
Minimized unnecessary queries

Why This Matters for the Agentic SOC Journey

This solution demonstrates three core pillars of agentic SOC:

1. Deterministic AI Execution

Standardized workflow
Repeatable outcomes
Consistent investigation depth

2. Human-in-the-Loop Control

Analyst decides final actions
No blind automation
Clear explainability

3. End-to-End Closure Capability

This is the most important:

Not just detection
Not just enrichment

Full lifecycle:

Investigate
Decide
Act

What’s Next

This pattern can be extended to:

Identity investigations
Insider risk
Multi-cloud threat correlation
Security Copilot-driven SOC agents

Final Thoughts

Most SOC automation still stops too early—at playbooks, enrichment, or isolated workflow steps. What is still missing in many environments is a cohesive execution model that can carry an investigation from signal to decision without losing context along the way.

Playbooks
Alert enrichment
Partial workflows

This pattern points to something more powerful: composable, intelligent SOC agents that can operate across the full incident lifecycle while keeping humans firmly in control of high-impact actions.

If an agentic SOC is the destination, portable investigation agents are a practical and credible way to start building toward it today.

Get the agent, setup steps, and instructions on GitHub:

SOC Malware Investigator (Portable)SOC Malware Investigator (Portable)

Learn more

Microsoft Sentinel MCP server: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-mcp-overview
Microsoft Sentinel data lake: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-lake-overview
Advanced hunting (Defender device tables): https://learn.microsoft.com/microsoft-365/security/defender/advanced-hunting-overview

Behind the Build with Gigamon: Enriching Microsoft Sentinel with Network-Derived Telemetry

Natee_Pretikul — Wed, 01 Jul 2026 17:51:59 GMT

Behind the Build is an ongoing series spotlighting standout Microsoft partner collaborations. Each edition dives into the technical and strategic decisions that shape real-world integrations—highlighting engineering excellence, innovation, and the shared customer value created through partnership.

Security teams today operate across an expanding set of signals, spanning identity, endpoint, cloud and application environments. Yet many organizations still lack sufficient visibility into how systems communicate across their infrastructure, creating gaps in detection, investigation, and response.

In this edition of Behind the Build, I spoke with Srinivas Chakravarty, vice president, cloud ecosystems at Gigamon, about how Microsoft and Gigamon collaborated to bring network-derived telemetry into Microsoft Sentinel, helping customers enrich security investigations with deeper runtime context and AI-driven insights.

The Evolution of Network Intelligence and Why It Matters

For more than twenty years, Gigamon has helped organizations access and operationalize network traffic across complex environments. Today, the Gigamon Deep Observability Pipeline, helps enable organizations to extract actionable network-derived telemetry across hybrid infrastructure, encrypted traffic, containers, and modern application environments.

That foundation makes the Gigamon Deep Observability Pipeline a strong complement to Microsoft Sentinel. Microsoft Sentinel brings together security telemetry from across the enterprise—including identity, endpoint, cloud, application, and network data sources—while Gigamon contributes enriched network-derived telemetry that provides additional runtime context into how systems, applications, and services communicate. Together, these signals can help organizations gain deeper insight for threat detection, investigation, and response.

As Srinivas put it: “You have logs, you have metrics, you have traces, but network telemetry completes the picture.” Together, these data sources provide deeper context for threat detection, investigation, and AI-driven analysis.

Gigamon and Microsoft partner to design end-to-end solutions for our shared customers, starting with how network traffic is captured, to how it is processed, and ultimately to how it is analyzed within Microsoft Sentinel. The first step in that pipeline is ensuring consistent, scalable visibility into traffic across environments.

Extending Visibility

Gigamon has been working alongside Microsoft’s Azure network virtual access point team to expand how customers access network traffic across Azure and hybrid environments. Customers can leverage the virtual network TAP in Azure environments alongside Gigamon telemetry capabilities across on-premises, cloud, and hybrid deployments.

This visibility layer is foundational to the broader architecture. The Gigamon Deep Observability Pipeline helps ensure organizations can access, optimize, and enrich network traffic before transforming it into actionable telemetry for downstream analysis in Microsoft Sentinel.

Turning Network Telemetry into Actionable Security Insights

The integration between Gigamon and Microsoft Sentinel is designed to maximize both fidelity and operational efficiency. Gigamon deep packet inspection capabilities extract and enrich nearly 6,000 metadata attributes from network traffic, transforming raw packets into curated telemetry designed for downstream analysis.

That telemetry is delivered into Microsoft Sentinel through a Codeless Connector Framework (CCF) push connector, where it can be correlated with identity, endpoint, and cloud telemetry. By bringing these signals together, organizations can more easily trace suspicious activity across their environments and investigate threats that span traditionally siloed domains.

Rather than overwhelming analysts with raw network data, the integration prioritizes actionable metadata that can be correlated across traditionally siloed domains. “When you bring this data into Sentinel, you’re no longer analyzing it in isolation, you’re correlating it across the entire estate,” said Srinivas.

Delivering Customer Value: A Unified Investigative Experience

While the technical architecture is important, the ultimate measure of success is the impact on customers. By combining Gigamon’s network intelligence with Microsoft Sentinel’s analytics and AI capabilities, organizations can gain a more complete view of their environments, one that helps reduce fragmentation and accelerate investigations.

“Customers are looking for a single investigative plane,” Srinivas explained. “When you bring all of this together, it can help significantly reduce the time to detect and respond.”

This helps manifest four key outcomes:

Accelerated investigations through correlation across network, identity, endpoint, and cloud telemetry
Improved signal quality through curated, high-value network-derived metadata
Greater operational efficiency through a unified investigation experience in Microsoft Sentinel
Enhanced visibility into encrypted, East-West, and hybrid cloud traffic activity that is often difficult to analyze through logs alone

By helping to address gaps that exist when using network or log data in isolation, the combined Gigamon and Microsoft solution can help SOC teams move more quickly from signal to action.

From Ingestion to Insight: Building with Agentic AI

Bringing telemetry into Microsoft Sentinel was only the first step. A major area of collaboration between Microsoft and Gigamon focused on leveraging Sentinel's AI and data platform capabilities to enable agentic workflows that can reason over enriched network-derived telemetry alongside broader security data.

“It’s truly working backwards from customers,” said Srinivas. “We are driven by what customers want and we help each other out, we unblock each other at every step of the way to make these joint solutions possible.”

The result is Gigamon's Security Posture Insight Agent, which leverages Microsoft Sentinel platform capabilities to enrich investigations with deep packet-derived evidence including JA4 fingerprints, decrypted TLS metadata, and lateral-movement flows. This can help give analysts faster access to runtime evidence that might otherwise require manual packet analysis and correlation across tools.

Expanding the Possibilities of the Platform

As the collaboration evolves, both teams see opportunities to expand the role of network-derived telemetry across emerging AI and hybrid cloud security use cases. Areas of potential exploration include AI application visibility, expanded runtime intelligence, and deeper integration between observability, security analytics, and AI-driven workflows.

“The platform approach will win, especially in an AI-driven world,” said Srinivas. “It’s about ecosystems coming together.”

That ecosystem mindset of bringing together best-in-class data, analytics, and AI is what enables organizations to stay ahead of increasingly complex threats.

Final Thoughts

This collaboration highlights what’s possible when strong engineering partnerships are grounded in customer outcomes. By combining network-derived telemetry from the Gigamon Deep Observability Pipeline with analytics and AI capabilities of Microsoft Sentinel, organizations can gain deeper runtime visibility, accelerate investigations, and improve AI-driven security operations.

As the partnership continues to evolve, Microsoft and Gigamon are working together to help customers build more unified, intelligent SOC experiences across increasingly complex hybrid cloud environments.

For software companies building on Microsoft Sentinel, the Gigamon collaboration also demonstrates how partners can leverage Microsoft App Assure’s Sentinel Advisory Service, a no-cost program that helps partners design secure, high-performance solutions on Microsoft Sentinel while accelerating time to market. From development to deployment, App Assure ensures your solution meets Microsoft’s standards while accelerating time to market. Ready to get started building a Sentinel solution? Submit a request to App Assure.

To read previous entries in our Behind the Build series, see below:

The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

Mohit_Kumar1 — Tue, 30 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The portal change was the easy part. The real upside is the operating model it unlocks—generative AI in every workflow, behavioral analytics across hybrid and multi-cloud, native threat intelligence, and SOC optimization recommendations that tell you exactly where to invest next.

If the first five parts of this series were about what changes and how to plan for it, this part is about what you get on the other side. Microsoft Defender is the only place where Security Copilot agents, the unified UEBA experience, native MDTI convergence, and the full SOC optimization recommendation engine come together—and each one moves a needle that classic Sentinel could not move alone.

None of these capabilities require a forced cutover. Most of them light up the moment a workspace is connected. The story is not “give up Sentinel for Defender”—it is “your existing investment now compounds with capabilities you did not have before.”

What this post covers

Security Copilot: embedded experience, standalone portal, and AI agents
UEBA: same engine, unified entity pages, new data sources, unified IdentityInfo schema
Threat intelligence: MDTI converged natively, richer STIX data model, actor-centric investigations
SOC optimization: from manual workbooks to personalized, cross-service recommendations
Persona implications, common misconceptions, a do-this-week checklist, and the series wrap-up

Security Copilot in Defender

Microsoft Security Copilot is a generative AI-powered security solution. Customers can interact with Security Copilot across their Sentinel and Defender data in Defender (embedded experience and agents) and the standalone copilot portal (securitycopilot.microsoft.com).

Core capabilities

Investigate and remediate threats; incident summarization, guided step-by-step response actions, triage complex alerts into actionable summaries
Build KQL queries and analyze scripts; natural language → KQL in advanced hunting, reverse engineer suspicious PowerShell, batch, and bash scripts
Understand risks and manage posture; prioritized risk insights, exposure context, and threat actor intelligence from Microsoft and open source
Develop reports for stakeholders; generate incident reports in natural language, tailored to audience tone and language

AI agents

Microsoft-built and partner-built agents are available through the Security Store in Defender, automating SOC tasks such as incident triage, access reviews, and vulnerability remediation. Custom agents can be built using agent builder, APIs, MCP, and Graph.

Transition considerations

The embedded experience of Security Copilot and agents are available in the Defender portal and not in the Azure portal.
No configuration migration needed; available once licensed.
Train SOC analysts on Security Copilot as part of Defender onboarding.

Why this lands well: Generative AI is not bolted on to the side of the SOC—it is embedded in the surfaces where work already happens. Triage, KQL authoring, scripted-attack analysis, and stakeholder reporting each get a copilot, and the agent marketplace means the catalog grows without you writing more code.

UEBA: Same engine, richer surface

Most User and Entity Behavior Analytics (UEBA) functionality carries over to Defender with minimal disruption—anomaly detection, behavioral baselines, and investigation priority scoring all continue to work. However, there are meaningful differences in how UEBA surfaces within the unified experience that analysts and engineering teams should understand before transitioning.

The Microsoft Sentinel UEBA behaviors layer transforms high-volume raw security logs into structured, plain-language behavioral summaries (“who did what to whom”), adding context such as MITRE ATT&CK mappings and entity relationships to improve investigation clarity and efficiency.

These behaviors are neutral activity summaries (not alerts), aggregating and sequencing events to help analysts detect patterns, hunt threats, and build simpler detections, ultimately speeding up investigation and response without requiring deep knowledge of underlying log sources.

What changes in Defender

The standalone entity behavior blade from the Azure portal is no longer available. Instead, UEBA insights are integrated directly into the unified entity pages under assets (accounts, hosts, mailboxes) and evidence (IPs, files, URLs). Users flagged with behavioral anomalies are automatically tagged with a “UEBA anomalies” label on the user page, showing confidence scores and anomaly counts—making it easier to prioritize investigation without navigating to a separate blade. Additionally, the incident graph now supports a “Go hunt” action on user entities that surfaces all related anomalies, and advanced hunting queries against UEBA-related tables display contextual banners suggesting joins with the anomalies table for richer results. Also, in Defender, UEBA now has behavior layers.

New data sources (Defender only)

After transitioning, UEBA gains access to additional data sources that are not available in the Azure portal: AAD managed identity sign-in logs, AAD service principal sign-in logs, AWS CloudTrail, device logon events, Okta single sign-on, and GCP audit logs. These expand behavioral baselines beyond traditional user sign-ins to cover service principals, multi-cloud activity, and device-level logon events—a significant uplift for organizations with hybrid or multi-cloud environments.

IdentityInfo table: Two flavors, now unified

The IdentityInfo table has historically existed in two separate versions: one populated by Microsoft Defender for identity (MDI) in advanced hunting, and another populated by Microsoft Sentinel’s UEBA engine in log analytics.

Important - Table-level RBAC on IdentityInfo: If Table-level RBAC has been delegated to the Sentinel IdentityInfo table, this permission model is not carried over to Defender. Table-level RBAC for the IdentityInfo table is not supported in the Defender portal. Review and update your workspace RBAC delegations before migrating to avoid unexpected access gaps. For details, see the Investigate with UEBA in the Defender portal section in the Microsoft documentation.

After onboarding to Defender, these merge into a unified IdentityInfo table that includes fields from both sources. If UEBA is enabled, the UEBA-specific columns—such as BlastRadius, GroupMembership, CompanyName, DeletedDateTime, EmployeeId, OtherMailAddresses, State, and Tags—are automatically visible in the unified schema. Without UEBA enabled, these columns are not available.

The key action item here is that the unified schema introduces field name differences that can break existing queries.

The following table maps old field names to the new unified schema:

Log analytics field	Unified schema field
AccountCloudSID	CloudSid
AccountCreationTime	CreatedDateTime
AccountSID	OnPremSid
AccountUPN	AccountUpn
AdditionalMailAddresses	OtherMailAddresses
MailAddress	EmailAddress
OnPremisesDistinguishedName	DistinguishedName
RiskState	RiskStatus
SAMAccountName	AccountName
SourceSystem	IdentityEnvironment
StreetAddress	Address
UserType	TenantMembershipType

Additionally, UserState and UserStateChangedOn no longer exist in the unified schema and must be removed from any queries that reference them.

Important caveat: Existing Sentinel analytic rules and workbooks that query IdentityInfo via the log analytics API continue to hit the Sentinel table in log analytics—they are not automatically redirected to the advanced hunting table. However, any queries executed in advanced hunting in Defender use the unified table. Teams should verify both query paths during transition.

Why this lands well: The same UEBA engine you already trust, now embedded in entity pages where investigations actually happen, fed by additional multi-cloud and identity data sources that simply do not exist on the Azure portal side.

Threat intelligence converged natively

Azure portal versus Defender at a glance

Aspect	Azure portal	Defender
Custom threat intelligence management	Sentinel’s threat intelligence blade for ingesting, viewing, and managing custom indicators (IOCs). Threat intelligence analytics rule matches against data sources automatically.	Defender’s threat intelligence blade is focused on Microsoft-curated intelligence integrated directly into the unified experience. Threat intelligence ingestion using STIX/TAXII is unchanged architecturally but is managed from the Defender UI rather than a standalone Sentinel experience. Customers can add/import their own threat intelligence using bulk file imports, or add new threat intelligence objects.
Microsoft threat intelligence	Threat intelligence analytics rule provides high-fidelity alerts using Microsoft’s domain, IP, and URL threat indicators across CEF, Syslog, OfficeActivity, AzureActivity, DNS.	Threat intelligence analytic rules are also present. Microsoft Defender threat intelligence (MDTI) converged into a unified experience in Defender, where threat intelligence is now surfaced natively across Defender and Microsoft Sentinel through threat analytics, investigations, and hunting workflows. Microsoft Threat Intelligence insights are embedded directly into incidents to provide enriched context and can also be accessed seamlessly through Security Copilot prompts. Security Copilot leverages Microsoft threat intelligence and non-Microsoft plugins.

Aspect

Azure portal

Defender

Custom threat intelligence management

Sentinel’s threat intelligence blade for ingesting, viewing, and managing custom indicators (IOCs). Threat intelligence analytics rule matches against data sources automatically.

Defender’s threat intelligence blade is focused on Microsoft-curated intelligence integrated directly into the unified experience. Threat intelligence ingestion using STIX/TAXII is unchanged architecturally but is managed from the Defender UI rather than a standalone Sentinel experience. Customers can add/import their own threat intelligence using bulk file imports, or add new threat intelligence objects.

Microsoft threat intelligence

Threat intelligence analytics rule provides high-fidelity alerts using Microsoft’s domain, IP, and URL threat indicators across CEF, Syslog, OfficeActivity, AzureActivity, DNS.

Threat intelligence analytic rules are also present. Microsoft Defender threat intelligence (MDTI) converged into a unified experience in Defender, where threat intelligence is now surfaced natively across Defender and Microsoft Sentinel through threat analytics, investigations, and hunting workflows.

Microsoft Threat Intelligence insights are embedded directly into incidents to provide enriched context and can also be accessed seamlessly through Security Copilot prompts. Security Copilot leverages Microsoft threat intelligence and non-Microsoft plugins.

Transition considerations

Continue managing custom threat intelligence feeds using Sentinel connectors and the threat intelligence experience for TAXII/STIX feeds
Keep the threat intelligence analytics rule enabled for automated indicator matching; resulting alerts can still flow into Defender incidents
Use MDTI context and Security Copilot prompts to enrich investigations
Threat intelligence is no longer Sentinel-only

In Defender, threat intelligence is:

Linked to Defender incidents
Visible in threat analytics
Usable in cross-product hunting

This is not possible in the Azure portal experience, which is Sentinel-scoped only.

MDTI convergence (native, not a connector)

MDTI is converged directly into Defender + Sentinel
Threat actor profiles, campaigns, and IOCs surface automatically
No separate MDTI portal or workflow is required

This convergence does not fully materialize in the Azure portal experience.

Richer STIX data model in Defender

Defender emphasizes richer relationships, such as:

ThreatIntelIndicators
ThreatIntelObjects
Actor ↔ tool ↔ infrastructure relationships

This enables actor-centric investigations, not just IOC matching.

Better correlation and investigation

Threat intelligence automatically enriches unified incidents
Indicators connect to affected endpoints, users, mail, and cloud workloads

Why this lands well: Threat intelligence stops being a side-product. Microsoft-curated intelligence and your custom feeds both flow into the same incident view, surface in threat analytics, and become huntable across Defender + Sentinel—with Security Copilot in the loop for enrichment.

SOC Optimization: From workbooks to recommendations

Azure portal versus Defender

Portal	SOC optimization model
Azure portal	No native SOC Optimization prior to May 2024. Customers used the MITRE ATT&CK coverage page (Preview) and community workbooks (Workspace Usage, Security Operations Efficiency) for manual, non-opinionated assessment No personalized recommendations; analysts had to interpret workbooks themselves Available in Azure portal (since May 2024 public preview)—same recommendation engine. However, the Azure portal provides Sentinel-only visibility and lags Defender in surfacing newer recommendation types and aggregation views, such as risk-based optimization and cross-service context Sunsets March 31, 2027, along with the rest of the Azure portal Sentinel UI
Defender	SOC optimization overview tile shows recent optimization activity, threat-based coverage tiers (low, medium, high), and ingestion trends Three GA recommendation types: data value (identify unused or low-value ingested data), threat-based coverage (close detection gaps against specific threats), and similar organizations (benchmarking) Preview capabilities: risk-based recommendations, AI-powered MITRE ATT&CK tagging, and unused columns detection Cross-service coverage: Unified view spans Sentinel + Defender workloads, not just Sentinel Recommendations API (Preview, 2024-01-01): GET/PATCH/triggerEvaluation for automation; scales for MSSPs. Permissions: Standard Sentinel RBAC (Reader to view, Contributor to action)

Transition considerations

Not Defender-exclusive: Core recommendation engine runs in both portals—no functionality loss for customers who transition early
Defender advantages: Cross-service coverage (Sentinel + Defender), richer overview tile, and Preview-only risk-based recommendations are Defender exclusives
Preview features evolving: Risk-based, AI MITRE tagging, and unused columns remain in Preview—verify GA status against “What’s new in Sentinel” before relying on them
Retire manual workbooks: Phase out reliance on the Workspace Usage and Security Operations Efficiency workbooks; SOC optimization supersedes them with personalized, actionable recommendations
Action tracking: Use the recommendations API to track which optimizations your team actions over time—useful for MSSPs reporting SOC maturity to customers

Why this lands well: You stop guessing what to improve. The engine tells you where coverage is weak, where ingestion is wasted, and how peer organizations are configured—and it does so across Sentinel + Defender, not just one product.

Persona implications

Persona	What this part means for you
SOC analyst	Security Copilot in-line for triage, incident summaries, KQL drafting, and script reverse-engineering. UEBA anomalies show up on the entity page itself, not a separate blade.
Threat hunter	Unified IdentityInfo, multi-cloud UEBA data sources, MDTI-enriched investigations, and natural-language-to-KQL all in one surface.
Detection engineer	Update IdentityInfo field names in existing queries; verify both log analytics and advanced hunting paths during transition.
SOC manager	SOC optimization gives you a personalized, cross-service action list. Retire the manual workbooks; track action rate through the recommendations API.
MSSP operator	SOC optimization recommendations API scales for MSSP reporting; agents from the Security Store help automate repetitive customer-facing SOC tasks.

Clearing up common misconceptions

“Security Copilot is only available in the standalone portal.”
It’s not. The embedded experience and agents are available inside Defender once licensed—no configuration migration needed.
“UEBA loses functionality after the transition.”
UEBA functionality remains. Anomaly detection, baselines, and priority scoring all carry over—and you gain multi-cloud and service-principal data sources that do not exist in the Azure portal experience.
“All my IdentityInfo queries will keep working unchanged.”
Partially. Sentinel analytic rules and workbooks hitting log analytics still work; Advanced hunting queries use the unified table with new field names—verify both paths during transition.
“MDTI needs a separate portal or connector.”
It doesn’t. MDTI is converged natively into Defender + Sentinel—threat actor profiles, campaigns, and IOCs surface automatically.
“SOC Optimization is Defender-only.”
The core engine runs in both portals. Defender adds cross-service coverage, the richer overview tile, and Preview-only recommendation types.
“Community workbooks for usage and efficiency are still the recommended path.”
Not anymore. SOC optimization supersedes them with personalized, actionable recommendations—phase the manual workbooks out.

Do this week

Enable the embedded experience in Defender and pilot incident summarization on one active incident if you are licensed for Security Copilot
Walk through the SOC optimization overview tile with your manager—pick one data-value and one threat-based recommendation to action this sprint
Inventory queries that reference the legacy log analytics IdentityInfo fields; map them against the unified schema field-name table and prioritize updates
Confirm UEBA is enabled where applicable so the additional unified-schema columns light up
Open the Defender threat intelligence pane and verify MDTI context is surfacing on at least one current incident
Try one natural-language-to-KQL prompt in advanced hunting via Security Copilot—a quick “aha” for the team
Evaluate at least one Microsoft-built or partner-built agent from the Security Store for a high-volume repetitive task if you are an MSSP

Closing the series

Six parts in, the picture should be clear: the Microsoft Sentinel transition to Defender is not a forced UI swap. It is the consolidation of SIEM and XDR into a single operating model—one incident queue, one detection rules view, one hunting surface, one governance plane, and a single AI-first toolchain.

Everything you have built carries forward. Analytics rules continue to fire. Playbooks continue to run. Workbooks continue to render. Your Azure RBAC continues to govern. And the new capabilities—XDR correlation, custom detections, Security Copilot, the data lake, UEBA on multi-cloud, MDTI convergence, SOC optimization—are the upside you collect for making the move.

March 31, 2027 sets the deadline. The adoption helper sets the starting line. Everything in between is yours to design—and this series exists so you can design it with confidence.

Read the rest of the series

Each part in this series stands alone—pick the angle that matters most to you, or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi-tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

What’s new in Microsoft Sentinel: June 2026

TomerBrand — Tue, 30 Jun 2026 16:43:18 GMT

Welcome back to What's new in Microsoft Sentinel. In June, Sentinel SIEM’s Advanced Security Information Model (ASIM) broadens its normalization, so one analytic rule can reach more sources with less per-source work and, additionally, two new ASIM schemas can now bring asset inventory and AI agent telemetry into common form. In Microsoft Sentinel data lake, the Agent Identities Asset Connector adds the identity context behind your AI agents, helping you see who owns an agent and what permissions it holds. In Sentinel MCP, graph tools help security teams investigate threats and optimize security coverage by visualizing relationships across identities, devices, alerts, and signals in a unified graph experience.

Read on for the details, and explore the resources at the end to go deeper.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake
Sentinel MCP
Microsoft Security Store

Sentinel SIEM

Advanced Security Information Model (ASIM) parsers and schemas [Generally available]

The Advanced Security Information Model (ASIM) in Sentinel normalizes logs into common schemas, so one analytic rule can cover many sources without managing each native schema. ASIM coverage has expanded across more Azure services, broader AWS CloudTrail activity, and a range of third-party firewall, identity, and proxy products, so your detections reach more of your environment with less per-source work. Two schemas also join ASIM: Asset Entities normalizes asset inventory so you can correlate files and assets across investigations, and AI Agent Events normalizes telemetry from AI-driven workflows and autonomous agents. Browse the ASIM parsers on GitHub to explore, file issues, or contribute. Learn more in our blog.

Sentinel transition to Defender blog series

By March 31, 2027, all Microsoft Sentinel customers transition to Defender. This six-part series guides you through moving your Sentinel experience from the Azure portal to Defender, where SIEM, XDR, threat intelligence, AI, and automation come together in one experience. Your analytics rules, playbooks, workbooks, log analytics workspace, and access assignments all carry forward while the operational layer becomes more connected and intelligent. Starting early matters because you realize the benefits sooner, including a unified incident queue, cross-product correlation, Security Copilot, Sentinel data lake, and SOC optimization. Across the six-part blog series you get 1) the strategic shift, 2) the anatomy of incident and data changes, 3) detection and automation, 4) the governance shift across roles and access, 5) a readiness playbook with the adoption helper and cost guidance, and 6) a look at the AI-first SOC. Each part stands alone, so you can read in order or jump to what matters most to you.

Sentinel data lake

Agent Identities Asset Connector [Public preview]

The Agent Identities Asset Connector brings identity context for AI agents into Sentinel. Activity connectors like Agent 365 and Microsoft 365 Copilot already show you what AI agents do, but activity alone cannot tell you who owns an agent, what permissions it holds, or how it is governed. This connector fills that gap with four asset tables covering agent owners, agent identities, agent blueprints, and the service principals tied to those blueprints. Together they form a connected agent identity graph you can trace from owner to identity to blueprint to permissions to the resources an agent touches. Joining this asset data with activity data in Sentinel data lake lets you detect anomalous behavior relative to permissions, spot over-permissioned or misconfigured agents, and follow full execution chains for end-to-end traceability. To get started, install the Agent 365 and Microsoft 365 Copilot solutions in Content Hub and enable the asset and activity connectors. Learn more.

Sentinel MCP

Sentinel MCP graph tools [Public preview]

Microsoft Security Graph MCP tools, recently introduced in the Microsoft Sentinel MCP Server data exploration collection helps security teams investigate threats by exploring relationships between identities and device assets, and threat and activity signals ingested by data connectors and surfaced by analytic rules. Starting from an alert, analysts can follow the exposure path across connected entities — tracing lateral movement, understanding blast radius, and identifying configuration gaps — all from a single, interactive workspace. The tool provides a clear graph view that highlights dependencies and makes it easier to understand how content interacts across your environment. This helps security teams assess coverage, optimize content deployment, and identify areas that may need tuning or additional data sources. Executing graph queries via the MCP tools will trigger the graph meter. Learn more.

Microsoft Security Store

Partner testimonials from Adaquest and Glueckkanja

For partners like Adaquest and Glueckkanja, the Microsoft Security Store helps not only put their years of knowledge, understanding, and best practices into a scalable, packaged solution, it gives them the ability to democratize that expertise and take it to market globally. Security Store operationalizes their expertise as always-on defenses — discoverable, deployable, and driving real outcomes inside the tools that security teams rely on every day.

See how the Security Store is helping security teams act on threats faster with the right solutions and to be ready when it matters most:

Additional resources

Blogs and documentation:

Upcoming webinars and events:

July 15–16: Microsoft Virtual Training Day: Predict and Defend Against Cybersecurity Threats
July 22: Microsoft Security Immersion Event: Shadow Hunter
July 23-24: Microsoft Virtual Training Day: Introduction to Microsoft Security
July 28: Tech Brief: Modernize security operations with a unified platform
July 29: Security Immersion Event: Into the Breach

Stay connected

Check back each month for the latest innovations, updates, and events to ensure you’re getting the most out of Microsoft Sentinel. We’ll see you in the next edition!

Your readiness playbook: adoption helper, costs, APIs, and the checklist

Mohit_Kumar1 — Mon, 29 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

The transition is not a project—it is a sequence of small, ordered decisions. Here is the readiness tool that scores your environment in minutes, the cost story you can take to finance, the API strategy that future-proofs your integrations, and the FAQ list that answers the questions your team is already asking.

Most transition anxiety comes from not knowing what you do not know. The Defender transition is mature enough that Microsoft has packaged the readiness work into a script, the cost work into an estimator, and the API work into a clear migration story—and the most common questions are already answered.

This part is the practical playbook. It does not introduce new architecture; it gives you the levers you can pull right now to know exactly where you stand, what it will cost, what to integrate with, and how to brief the people asking questions.

What this post covers

Defender adoption helper: a free readiness assessment with a visual dashboard
Cost story: identical Sentinel pricing, optional new capabilities, and the new estimator
The API strategy: SecurityInsights for workspace, Defender APIs for SOC, Graph security for the long run
FAQ list: the five questions every stakeholder asks, answered
Persona implications, common misconceptions, and a do-this-week checklist

Defender adoption helper

Overview

The Sentinel-Defender-helper-script is a PowerShell-based assessment tool designed to evaluate the readiness of Microsoft Sentinel workspaces before onboarding them into Microsoft Defender. It automates the discovery of potential compatibility issues, configuration gaps, and behavioral changes that organizations should address prior to the transition. The tool generates a structured CSV output that feeds an interactive HTML dashboard, providing security teams with a clear, visual summary of findings and actionable recommendations.

Important: This script is not an official Microsoft product or supported solution. No Microsoft Customer Services & Support (CSS) ticket can be raised for issues related to this tool, and bug fixing is not guaranteed beyond the author's willingness to maintain it. No rights can be derived from this solution—incorrect or missing information generated by this script may lead to customer production disruption. Test it before using it in production environment.

How it works

The tool operates in three phases:

Authentication

The operator authenticates against Microsoft Entra ID using one of two supported modes. In User mode, the script initiates an interactive device code flow through the browser, leveraging the well-known Azure PowerShell first-party client ID — no app registration is required. In app mode, a pre-configured service principal with a client secret is used for unattended execution. In both cases, the account must hold the Microsoft Sentinel Reader role on each target workspace.

Analysis

For each workspace defined in the sentinelEnvironments.json configuration file, the script calls the Azure Resource Manager REST APIs to inspect five areas:

Defender data – Queries the retention settings of 21 Defender tables (e.g., DeviceInfo, EmailEvents, IdentityLogonEvents). Tables with default 30-day retention do not need separate ingestion into Sentinel, whereas tables with extended retention (e.g., 730 days) must continue to be stored in the log analytics workspace.
Analytics rules – Examines every analytics rule for conditions that may cause issues after onboarding: Fusion engine enablement (Fusion is automatically disabled post-transition), rules that do not generate incidents (alerts become invisible in Defender), incident reopening settings (not supported in Defender—new incidents are created instead), custom alert grouping (overridden by the Defender XDR correlation engine), and Microsoft incident creation rules (deactivated after onboarding). Disabled rules are flagged as informational only.
Automation rules – Inspects automation rule triggers and conditions for deprecated or incompatible patterns: use of incident title instead of analytics rule name, use of incident provider instead of alert product name, dependencies on Fusion-generated incidents, reliance on the description field (removed from SecurityIncident after onboarding), the Updated By = Microsoft 365 Defender value (which becomes Other), and alert-based triggers (which will only fire for Sentinel-originated alerts post-transition).
Data lake region – Verifies whether the workspace region supports the data lake (Auxiliary tier) capability, checking against the list of currently supported Azure regions.
Table tiers – Enumerates all tables in the workspace and flags those using the basic tier, which must be converted to analytics or auxiliary before onboarding. Tables already on the auxiliary tier are noted as future data lake tables.

Output

All findings are collected into a flat CSV file (results.csv) with a consistent schema containing the row type (env, check, or score), workspace name, section, severity status, a human-readable message, and an optional sub-item identifier for grouping (e.g., the rule name). Per-section scores and a final readiness percentage are calculated automatically. The data lake checks are reported separately and do not affect the final readiness score.

Severity classification

Status	Meaning
Ok	No action required—the configuration is compatible with Defender.
Warning	Requires attention before onboarding—the configuration will cause a behavioral change or loss of functionality.
Informational	No action required and does not block migration (e.g., tables with default retention, disabled rules). Counts as passed in the final score.

Analyzing the findings

The generated CSV is loaded into the accompanying HTML dashboard (dashboard.html), which provides:

A multi-workspace overview with readiness scores and pie charts for each environment
Per-workspace detail panels that break down findings by section (Defender data, analytics, automation, data lake region, table tiers)
Multi-select filters to isolate Ok (Passed), Warning, or Informational findings
Grouped rule views—analytics and automation rules are grouped by name, with individual sub-checks shown underneath
Items overview cards summarizing the count and distribution of findings per section
Export to PDF—either per workspace or across all environments at once
Direct Azure portal links for each section, allowing operators to navigate directly to the relevant blade
A built-in knowledge base with recommendations mapped to official Microsoft documentation
A multitenant guidance tab covering access models (GDAP, Azure Lighthouse, B2B collaboration), MSSP best practices, and known limitations

Project contents

File	Description
DefenderAdoptionHelper.ps1	Main PowerShell script that performs the assessment via Azure REST APIs and generates the CSV output
dashboard.html	Self-contained interactive HTML dashboard that visualizes the CSV findings
sentinelEnvironments.json	Configuration file listing the Sentinel workspaces (subscription ID, resource group, workspace name) to be analyzed
results.csv	Generated output file consumed by the dashboard

Why this lands well: You go from “I think we are ready” to a percentage score and a list of named items in under an hour—with a knowledge base that links each finding to documentation. The hardest part of any migration is no longer the hardest part.

Cost story

Cost model

The Microsoft Sentinel pricing remains same for analytics tier data. The cost advantage of Defender comes from flexible billing and features (data lake, graph, MCP) that don’t exist in the Azure portal.
Use the new Sentinel cost estimator to analyze your data ingestion and retention cost.

Sentinel data lake can introduce variable cost, but in most environments, it reduces overall cost meaningfully—by letting you keep long-tail data in a cheaper tier instead of paying analytics-tier rates for data you rarely query.

Reference SKU table

SKU	Meter type	Price
Data lake ingestion	Data processed (GB)	$0.05 USD
Data processing	Data processed (GB)	$0.1 USD
Data lake query	Data analyzed (GB)	$0.005 USD
Advanced data insights	1 compute hour	$0.15 USD
Data lake storage	Data stored (GB/month)	$0.026 USD
Graph	1 compute hour	$3 USD

Why this lands well: Same analytics tier price, plus new tiers and capabilities that let you do things you simply could not do before. Run the estimator before you guess—most teams find the data lake reduces total spend once long-retention data is moved off the analytics tier.

The API strategy

The SecurityInsights API remains operational, but its coverage is scoped to Sentinel-specific resources and data. It does not surface Defender XDR incidents, Advanced Hunting data, or unified SecOps capabilities - meaning integrations built on it will lack access to the core unified experience.

Organizations relying on the SecurityInsights API should plan to migrate to the Microsoft Graph Security API as soon as possible. The Graph API provides unified coverage across Defender XDR incidents, Advanced Hunting, cases, and all emerging SecOps capabilities—areas the legacy Sentinel-only API does not expose. Migrating now reduces integration debt as Sentinel capabilities continue to consolidate into the unified Defender portal.

Common tasks

Create/update a Sentinel incident (workspace object): SecurityInsights incidents
List/manage Sentinel analytics rules: SecurityInsights alert rules
Integrate with unified incidents: Defender incidents API and Graph security incidents
Run Defender hunting programmatically: Graph security runHuntingQuery

Sentinel versus Defender versus Microsoft Graph security

Dimension	Microsoft Sentinel REST API (SecurityInsights)	Microsoft Defender APIs	Microsoft Graph security API
API surface	Azure resource manager (ARM) API under Microsoft.SecurityInsights	Product-specific REST APIs (/api/*) for Defender	Unified Microsoft Graph endpoint (/security/*)
Primary purpose	Workspace configuration and SIEM/SOAR management	Operational SOC actions in Defender	Unified security operations and automation across products
Typical usage	Infrastructure and content lifecycle management	Incident, alert, and detection operations	Cross-solution incident, alert, hunting, and threat intelligence integration
Scope of data	Sentinel-only (workspace-scoped)	Defender detections and signals	Aggregated signals across Defender + Sentinel
Incidents access	Sentinel incidents (Azure portal model)	Defender incident model	Unified incident model (Defender + Sentinel)
Alerts access	Analytic rule-generated alerts	Defender alerts	Unified alerts across providers
Detection management	Yes (analytic rules; automation rules)	Yes (custom detection rules)	No (read/act; no rule authoring)
Hunting	Yes (KQL via log analytics)	Yes (Advanced hunting)	Yes (Advanced hunting through runHuntingQuery)
Threat intelligence (IOCs)	Yes (TI CRUD; TAXII/STIX)	Limited	Yes (unified threat intelligence submission and investigation)
Automation and SOAR	Yes (logic apps playbooks; automation rules)	Limited native automation	Yes (event-driven workflows via Graph+ logic apps)
Authentication and permissions	Azure RBAC + Entra ID	Entra app permissions (Defender scopes)	Entra app permissions (Graph; unified RBAC)
Portal alignment	Azure portal (legacy Sentinel UX)	Microsoft Defender	Microsoft Defender
Multitenant/MSSP	Azure-subscription centric	Supported	Best fit through Graph + GDAP / MTO models
Strategic direction	Configuration and management API	Product API (still supported)	Strategic, long-term unified API

Microsoft Graph security API – Overview

The Microsoft Graph security API provides a unified interface and schema to integrate with security solutions from Microsoft and ecosystem partners; it federates queries to onboarded security providers and aggregates responses.

What you use it for (common SOC/platform scenarios)

Consolidate and correlate security alerts from multiple sources
Pull and investigate incidents and alerts from services that are part of or integrated with Microsoft Defender
Automate security tasks/workflows/reporting and send threat indicators (where applicable) into Microsoft products

Advanced hunting through Graph (high-value capability)

Graph security supports advanced hunting through runHuntingQuery, allowing you to run KQL on Microsoft 365 Defender advanced hunting tables and use results to enrich investigations.

Quotas/limits to keep in mind

Queries generally explore up to the past 30 days of data
Results can return up to 100,000 rows
You can make at least ~45 calls/min/tenant (varies by tenant size); requests can be throttled with HTTP 429 when resources are exhausted
If a request runs longer than 3 minutes, it times out
Query output has an overall 50 MB size limit

Why this lands well: You do not have to rewrite anything urgently. Keep using SecurityInsights for Sentinel workspace work, layer Defender APIs for operational SOC actions, and treat Microsoft Graph security as the strategic direction for anything new—a single endpoint that already federates across products.

FAQ list: Questions every stakeholder asks

“Is this transition mandatory?”

Yes, but you have time. After March 31, 2027, Microsoft Sentinel will no longer be supported in the Azure portal and will be available only in Microsoft Defender. All customers will be redirected to Defender for Sentinel security operations.

However, starting your transition now is strongly recommended to immediately access exclusive capabilities like Security Copilot, Sentinel data lake, and SOC optimization—features only available in Defender.

“Do I need to migrate my workspace?”

Workspace migration is not required. This is a common misconception. Your Sentinel workspace, log analytics workspace, and all data remain in their current Azure location. The transition is simply connecting your existing workspace to Defender for management.

Nothing about your data storage, retention, or access changes. You are not moving data—you are adding a new portal interface to the same underlying workspace.

“Will my costs change?”

There isn’t a cost change from the portal transition itself. Your Microsoft Sentinel pricing and billing model remains identical regardless of which portal you use. Data ingestion costs, commitment tiers, and log analytics charges all stay the same.

The only new potential costs are optional features available exclusively in Defender:

Security Copilot: Requires separate licensing if you want AI-powered investigation assistance
Sentinel data lake: Only incurs charges if you enable long-term retention beyond standard 90-day analytics tier

Standard Sentinel operations (data connectors, analytics rules, automation, hunting) have zero cost change from transitioning.

“Can I still use Azure portal?”

Yes, until March 31, 2027. During the transition period, you can use both portals simultaneously:

Azure portal for configuration management (data connectors, analytics rules, automation)
Defender for security operations (incidents, hunting, investigations)

Many organizations adopt a hybrid approach during transition: security analysts work primarily in Defender for day-to-day operations, while SOC engineers use the Azure portal for configuration and rule development.

After the March 2027 deadline, Sentinel security operations will only be available in Defender. However, the underlying Azure infrastructure (log analytics workspace, logic apps for playbooks) will remain accessible through the Azure portal for resource management.

“What if I use multiple workspaces?”

Multiple workspaces are fully supported. Defender has robust multi-workspace capabilities:

How it works:

Connect all your Sentinel workspaces to Defender (one-time setup per workspace)
Designate a primary workspace that feeds the unified incident queue
Use the workspace switcher in Defender to view or query other workspaces
Advanced Hunting can query across multiple workspaces simultaneously using the workspace function

For MSSPs managing customer tenants:

GDAP (granular delegated admin privileges) is now supported in Defender with MTO including Sentinel capabilities
Azure Lighthouse continues supporting cross-tenant workspace management
Each customer tenant’s workspaces can connect to Defender

Considerations:

Only the primary workspace contributes to the unified incident queue
Other workspaces are accessible for hunting, queries, and investigation but don’t merge incidents into the main queue
This prevents overwhelming analysts with incidents from test/dev workspaces while maintaining access to all data

Why this lands well: Every objection your stakeholders raise has a clean, source-grounded answer—mandatory but with runway, no data move, no surprise cost, two portals during transition, and full multi-workspace support.

Persona implications

Persona	What this part means for you
SOC manager	Run the adoption helper across all workspaces and use the dashboard to brief leadership with a readiness score, not a hunch.
Architect	Use the API comparison to plan your long-run integration story: SecurityInsights for workspace config, Defender APIs for SOC ops, Graph security as the strategic direction.
Finance/FinOps	Run the Sentinel cost estimator with current ingestion and retention numbers. Model what moving long-retention data from analytics to data lake does to monthly spend.
Integration engineer	Inventory existing SecurityInsights API consumers; decide which new integrations should be built on Graph security from the start.
Stakeholder/ Sponsor	Use the FAQ list as a one-pager for executives and security leadership—the five questions everyone asks, with grounded answers.

Clearing up common misconceptions

“This is a workspace migration.”
It isn’t. Your Sentinel and log analytics workspaces stay where they are—you connect them to Defender.
“Costs will go up automatically.”
Analytics tier pricing is unchanged. New cost only appears if you opt into Security Copilot or enable the data lake—and the lake often reduces total cost when long-retention data moves off the analytics tier.
“My API integrations will break on day one.”
SecurityInsights remains the API for Sentinel workspace operations. Defender APIs and Graph security extend the surface area—they do not replace what you have.
“I have to pick one portal.”
Until March 31, 2027, both portals are supported. Most teams run a hybrid model during transition.
“My multi-workspace setup will not work.”
It will. Multi-workspace is fully supported. Designate a primary for the unified queue and use the workspace switcher for the rest.
“I need an app registration to run the adoption helper.”
Not required. User mode uses the well-known Azure PowerShell first-party client ID through device code flow—no App Registration required. App mode is available for unattended runs.

Do this week

Clone the Defender adoption helper and run it across at least one production workspace; open the dashboard and walk the findings with your SOC team.
Take the warnings the adoption helper surfaces and create one tracking item per warning (analytics rule cleanup, automation rule cleanup, table tier conversions).
Run the Sentinel cost estimator with your current ingestion + retention numbers—model the lake scenario for long-retention tables.
Inventory which systems call the SecurityInsights APIs today; for any new integration starting this quarter, default to Microsoft Graph security.
Circulate the FAQ list (or a one-pager version of it) to executives and security leadership before they ask.
Confirm whether your primary workspace region supports the Sentinel data lake—it determines part of the tiering plan.
Calendar a transition kickoff for the next two weeks—the readiness work above gives you exactly the right inputs.

Continue the series

Each part in this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multitenant patterns.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

The governance shift: RBAC, URBAC, data lake, and MSSP

Mohit_Kumar1 — Thu, 25 Jun 2026 20:11:19 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Governance is the silent dependency every transition trips on. Read about how roles, data tiering, and multi-tenant operations evolve in Defender, and why each change unlocks something your old model could not.

Detection engineers debate KQL. Architects debate roles. The Defender transition is interesting because it updates to simply both - but the governance changes are the ones that quietly determine whether your unified SOC actually works the way you designed it on the whiteboard.

The good news: everything is normal on day one. Your existing Azure RBAC assignments keep functioning. Your Sentinel data stays where it is. Your MSSP delegations remain intact. What changes is what is now possible: data-scoped permissions that are not tied to a single workspace, a tiered data model that lets you keep years of history without keeping years of analytics-tier cost, and a multi-tenant view that spans up to 100 customer tenants with a single sign-in.

This post walks through each governance shift, what carries forward, and what is genuinely new—from the perspective of the architect who has to sign off and the SOC lead who has to operate it.

What this post covers

Roles and personas: who owns what after the transition
From classic Azure RBAC to Unified RBAC (URBAC): coexistence, then convergence
The data lake as a governance construct: tiering, retention, residency
Multi-tenant management and the MSSP operating model
Persona implications, common misconceptions, and a do-this-week checklist

Roles and personas: nothing breaks on day one

Transitioning to Defender does not eliminate existing Azure RBAC assignments – all continue to function. Once URBAC is activated, it becomes the source of permissions/authorization. The unified platform introduces a new permissions model: Microsoft Defender XDR Unified RBAC (URBAC), which can coexist with or replace classic Azure RBAC for Sentinel access.

Once URBAC is enabled in Defender, URBAC becomes the source of permissions and not Azure RBAC. It is preferred to migrate the classic Sentinel roles to URBAC ones after onboarding the log analytic workspaces.

Before transitioning, SOC leads and identity administrators should review the full role matrix and persona assignments and understand which personas require updated assignments. Customers can import roles using the import wizard; this way there is no need to create URBAC roles manually.

Why URBAC is the upgrade: URBAC is data-scoped + cross-workspace, not tied to a single workspace boundary. Another benefit of migrating to URBAC is the use of Sentinel scoping with row-level RBAC. And finally, it allows you to manage all of your roles and permissions in a single holistic access management system.

Persona-by-persona view

Security analysts – Triage and investigate incidents using the unified incident queue; require the Security Operator unified RBAC role. Entra global roles are not required for incident triage across Defender and Sentinel—a custom Defender unified RBAC role provides the necessary permissions with more granular scoping.
Security engineers – Build detections, manage content, and onboard data; require Sentinel Contributor (see mapping with URBAC). For SOAR tasks, roles such as logic app Contributor and Microsoft Sentinel automation Contributor can still be managed and assigned to Security engineers using Azure RBAC
SOC managers / architects – Plan RBAC strategy and map existing Azure RBAC to URBAC; govern least-privilege access across workspaces
Automation – Execute playbooks and automation rules; the roles related to automation (Microsoft Sentinel automation Contributor, logic app Contributor, Microsoft Sentinel playbook Operator) post-transition are not yet supported through URBAC, but can still be managed using Azure RBAC
Service principals – Service principals are currently not supported in URBAC; assigning permissions to a service principal or GDAP user group is planned to go public preview soon. Do not enable URBAC if service principals are in use in Microsoft Sentinel in the Azure portal.

Why this lands well: Day One continuity for every existing role assignment, with a clear path to a more capable model. You choose when to flip URBAC on, the import wizard does the heavy lifting, and you get data-scoped, cross-workspace permissions you never had in classic Sentinel.

Azure RBAC and URBAC: coexistence, then convergence

The transition does not force a permissions cutover. Sentinel permissions currently configured keep working exactly as they do today. You can also use URBAC for Sentinel permissions, ensuring you can manage your access management for Defender and Sentinel in a single holistic access management system. Once you turn URBAC on, it becomes the source of truth for permissions instead of Azure RBAC.

How they compare

Dimension	Classic Azure RBAC (Sentinel)	Unified RBAC (URBAC) in Defender
Scope model	Workspace-bound—a role grants access to one log analytics workspace at a time. In addition, you can configure row and table level conditions	Workspace-bound and scoped; A role grants access to one or more log analytics workspaces at the time, while also providing row-level Sentinel scopes if desired
Permissions surface	Reader, Responder, Contributor (plus automation-specific roles like logic app Contributor, playbook Operator)	Reader, Responder, Contributor created through URBAC custom roles; classic roles map in through the import wizard
Source of truth	Source of permissions until URBAC is enabled	Once enabled in Defender, URBAC becomes the source of permissions—not Azure RBAC
Service principals	Fully supported	Not currently supported in URBAC—keep managing these through Azure RBAC, even when URBAC is enabled
Automation roles	Logic app Contributor, Microsoft Sentinel automation Contributor, playbook Operator	Not currently supported in URBAC—keep managing these through Azure RBAC
Row-level scoping	Possible through log analytics row-level or table-level conditions, but this does not propagate to Sentinel experiences	Sentinel scoping (row-level access) supported and propagates to experiences (alerts, hunting, incidents)

Transition considerations

Onboard the log analytics workspaces first, then move the classic Sentinel role assignments to URBAC
Use the import wizard rather than re-creating URBAC roles manually—it preserves your existing assignment intent
If you rely on service principals for any Sentinel access (CI/CD, automation, integrations), please be aware that these are not yet supported in URBAC. The import wizard will detect this and will import the roles, but not assign them to service principals. If the role only includes service principals in the assignment, it can't be imported. Track the URBAC roadmap and plan accordingly, this support will be available soon. You can continue to configure these in Azure RBAC for now, even when URBAC is enabled.
Keep automation-related role assignments in Azure RBAC—they are not supported through URBAC today.
When you enable URBAC and assign roles, they are synchronized back to Azure as well. For example, a Sentinel Reader role created in URBAC will also create the role in Azure RBAC. If you then change the role in Azure RBAC (instead of on URBAC), it can create a sync issue. Disabling and enabling the workspace on URBAC will resolve the issue. This does not affect scenarios where Azure RBAC is the only source of permissions (logic apps for example), but it is something to be aware of.
Take advantage of row-level RBAC and cross-workspace scoping where you previously had to compromise.

Why this lands well: You get a more capable permissions model without a forced cutover. Classic roles keep working, the import wizard handles the migration, and the new data-scoped model finally matches the way modern SOCs think about access.

Sentinel data lake as a governance construct

All data ingested into the analytics tier (log analytics workspace) is automatically mirrored into the Sentinel data lake tier when Sentinel data lake is enabled, ensuring a single authoritative copy of security data that can be queried using KQL, notebooks, and advanced hunting tools without duplicating ingestion pipelines.

Security architects should use Sentinel data lake for historical threat hunting, retroactive IOC matching, compliance retention, and AI-assisted investigations, while keeping latency-sensitive detections and alerts in the analytics tier. Use the Sentinel cost estimator to calculate your environment’s need and refer to the pricing table to know more.

What the data lake gives you

Supports interactive and async KQL queries across all connected Sentinel workspaces.
Query external data sources without moving data (Public Preview), including Microsoft Fabric, Azure Databricks, and Azure Data Lake Storage Gen2.

Transition considerations

Sentinel data lake must be provisioned in the same Azure region as the primary Sentinel workspace and is not available in all regions—check the latest geographical availability and data residency.
When Sentinel is accessed through Defender, processed and configuration data may follow Defender regional processing, which can differ from the log analytics workspace region.
Customer-managed keys (CMKs) are not supported for data stored in the Sentinel data lake; Microsoft-managed keys are used.
Compare the analytics tier and data lake tier when sizing your retention strategy.

Region availability note: Sentinel data lake is not available in all Azure regions. Validate availability for your primary workspace region before planning enablement—the supported regions list is the authoritative reference and is updated as new regions come online.

Why this lands well: You finally separate “hot” detection data from “warm/cold” investigation data without rebuilding pipelines. One copy of the truth, two tiers, KQL across both—and a clear regional/governance story you can take to your data protection officer.

Multitenant management and the MSSP operating model

MSSPs and large multitenant enterprises have always had to stitch together Lighthouse, GDAP, and per-workspace navigation. Defender does not eliminate those building blocks—but it does add a unified cross-tenant view that genuinely simplifies day-to-day operations.

Azure portal versus Defender for multitenant

Portal	Multi-tenant model
Azure portal	Azure Lighthouse for cross-tenant visibility through ARM delegation Multi-workspace incident view; analysts pivot between workspaces for deep investigation Cross-workspace KQL through workspace operator (recommended to limit up to 10 workspaces to avoid latency and timeout) Per-workspace Azure RBAC; no centralized cross-tenant role management
Defender	Multitenant management (MTO) unified view across up to 100 tenants with single sign-in Unified incident queue, cross-tenant advanced hunting (SIEM + XDR), and content distribution profiles Dual RBAC: Azure RBAC for data + unified RBAC (URBAC) for portal access, currently with B2B, with centralized management Critical: MTO does not replace Lighthouse—Lighthouse is still required to access Azure resources such as Azure policy and function apps GDAP for Sentinel in Public Preview

Transition considerations

Maintain Lighthouse: Do not remove existing delegations—Lighthouse is still required to access Azure resources such as Azure policy and function apps.
100-tenant limit: Large MSSPs may need multiple MTO configurations or prioritize active tenants. MSSPs can also leverage tenant groups to organize tenants collectively and switch multitenant view between groups. Microsoft hasn't published a timeline for raising this ceiling—monitor the Defender XDR release notes for updates
Tenant-boundary isolation: Correlation engine operates within tenant boundaries—incidents never merged across tenants.
Playbook distribution gap: Automation rules and playbooks (logic apps) are not currently supported as distributable artifacts through MTO content distribution profiles, but you do have the ability to run logic apps hosted on “home tenant” to run on “target tenant” without deploying the artifact.

Where partners and MSSPs add value

Managed security service providers (MSSPs) and Microsoft partners bring specialized expertise in planning and executing Sentinel transitions to Defender. Partners accelerate your transition timeline, reduce operational risk, and ensure your team maximizes the value of unified security operations from Day One.

Key advantages of working with a partner:

Transition expertise: Partners have hands-on experience transitioning multiple customer environments and can anticipate challenges specific to your industry, architecture, and security maturity level.
Multi-tenant complexity: MSSPs managing Sentinel for multiple customers can navigate enhanced GDAP delegation, Azure Lighthouse configurations, and cross-tenant workspace management.
Accelerated onboarding: Partners provide structured onboarding programs combining technical setup, SOC analyst training, and workflow optimization to minimize time to value.
Custom automation development: Partners can develop logic apps playbooks, custom analytics rules, and hunting queries tailored to your environment and threat landscape.
Ongoing optimization: Post-transition, partners offer SOC optimization services leveraging the enhanced capabilities in Defender including AI-powered recommendations, cost management, and detection coverage gap analysis.

To find Microsoft partners specialized in Sentinel and Defender, visit partner.microsoft.com or consult your Microsoft account team for recommendations.

Why this lands well: A single cross-tenant view that does not force you to abandon what you have. Lighthouse + GDAP + MTO each do a different job, and the unified incident queue across tenants is the kind of capability MSSPs have been asking for.

Persona implications

Persona	What changes for you
SOC analyst	Single security Operator URBAC role across workspaces; the day-to-day triage experience does not require knowing which workspace an alert came from.
Security engineer	Sentinel Contributor maps into URBAC for SIEM content; keep logic app Contributor and automation Contributor in Azure RBAC for SOAR work.
SOC manager/ architect	You own the URBAC migration plan, the tier-versus-lake retention strategy, and the multi-tenant access model. Use the import wizard to preserve existing intent.
Data protection officer	The data lake adds a tier with its own residency and encryption story (Microsoft-managed keys, regional availability). Document it as part of your data flow inventory.
MSSP operator	Unified incident queue across up to 100 tenants; Lighthouse, GDAP, and B2B each remain in the picture but for different purposes. Plan tenant groups and content distribution profiles early.

Clearing up common misconceptions

“Turning on URBAC breaks my existing Azure RBAC assignments.”
No. Classic Sentinel roles continue to function. URBAC becomes the source of permissions once enabled, but it can be migrated from your existing assignments using the import wizard.
“I have to move my Sentinel data into the data lake.”
No. Data ingested into the analytics tier is automatically mirrored into the data lake when the lake is enabled—a single authoritative copy, no duplicate ingestion.
“MTO replaces Azure Lighthouse for MSSPs.”
No. MTO and Lighthouse coexist—Lighthouse is still required for Azure resource access (Azure policy, function apps); MTO provides the unified cross-tenant SOC view.
“If I enable URBAC, my logic apps playbooks break.”
No. Automation-related roles (logic app Contributor, automation Contributor, playbook Operator) keep working under Azure RBAC.
“Data lake is available everywhere Sentinel is.”
No. The data lake must be in the same Azure region as the primary Sentinel workspace and is not available in all regions—always check the geographical availability list before planning.
“MTO will merge incidents across tenants.”
No. The correlation engine operates within tenant boundaries—incidents are never merged across tenants. MTO provides visibility and operational consistency, not cross-tenant correlation.

Do this week

Inventory who holds which classic Sentinel role (Reader, Responder, Contributor, Automation roles) and which identities are service principals.
Defer URBAC enablement and document the dependency if any service principals hold Sentinel access.
Stand up a test URBAC scope using the import wizard—validate that analyst, engineer, and architect personas see what you expect.
Confirm your primary Sentinel workspace region is on the Sentinel data lake supported regions list.
Decide the analytics tier versus data lake tier split: which tables you want hot for detection and which you want warm for hunting/compliance.
Map your existing Lighthouse + GDAP footprint to the MTO model if you operate multi-tenant, and identify tenants for an initial MTO configuration (under the 100-tenant cap).
Schedule the transition planning session now if you work with an MSSP or Microsoft partner to compress weeks of work and surface issues you would otherwise find in production.

Continue the series

Each part of this series stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

How analytics rules, playbooks, workbooks, and hunting evolve—and why the toolbelt doubled, not shrank.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

A guide to innovating threat hunting with Microsoft Sentinel custom graph

Matt_Lowe — Wed, 24 Jun 2026 18:06:41 GMT

Microsoft Sentinel platform offers a growing list of tools and features, with graph being a cornerstone capability.

Sentinel graph is a relationship-first method for organizing and querying data within Microsoft Sentinel data lake. Activities amongst entities (users, devices, emails, IPs, applications, etc.) become a navigable structure that avoids a complex table structure. Rather than stitching together data and evidence via complex joins, users can follow multi-hop connections in order to understand insights such as blast radius, unseen pivots in malicious behavior, and investigative details that may not be as obvious within regular logs, all while visualizing these paths to assist in communicating evidence and findings.

This blog will walk through how to create custom graphs using GitHub Copilot chat experiences in Sentinel VS Code. And how to leverage out-of-the-box graph samples to build custom graphs addressing security outcomes. Custom graphs are available in public preview.

Prerequisites and Tooling

Sentinel data lake enabled in the tenant, this is where the data for the graph will be stored.
Users will need read/write permissions on Sentinel data lake data. And either security operator or security admin permissions to save a custom graph in the tenant.
Visual Studio Code (VS Code) will need to be installed, as it is essential for building and saving graphs.
The Jupyter notebook extension, Microsoft Sentinel extension, and GitHub Copilot extension will need to be installed from within VS Code. These are key pieces for configuring and managing graphs.
(Optional) Microsoft Sentinel MCP server if using MCP tools like the data exploration tool.

Building a new custom graph

The starting point is within Visual Studio Code (VS Code), where the custom graph will be built via GitHub Copilot and the Sentinel graph authoring tool. Make sure to have a GitHub account logged in within VS Code, then start a chat with Copilot via View > Chat. This will open a chat window on the right side of the screen.

Determining security telemetry for investigation

If unsure about which tables are available within the environment or the columns to focus on for hunting/investigations, turn to the Sentinel MCP server. With the Sentinel MCP server, users can explore the threat landscape within their environment as well as see which data sources currently exist within the Sentinel data lake. This process can be done using natural language with Copilot to obtain the information needed to perform the task at hand.

“List the most important tables within my Microsoft Sentinel data lake environment that would build a blast radius for a compromised user account. List the best columns to use for this scenario. Format the response as a table”

The tables and columns that can be used are now known. The next step is to use these tables to construct a custom graph with help from GitHub Copilot. For this example, a blast radius graph will be built to assist in reviewing the impact of compromised accounts within the environment:

“List the top 5 compromised or targeted accounts within my environment. List which types of attacks are involved with those accounts. Summarize the information into a simple to read table”

Given this response, there are a few options for going forward:

Return to the Microsoft Defender portal and attempt threat hunting/review this with other analysts
Ask Copilot to provide threat hunting queries or perform incident investigations for the top users who are most targeted
Build custom graphs to visualize threat data around the most targeted accounts

For this example, we will use option 3.

Building graph mappings with GitHub Copilot

To begin building a custom graph from scratch, a new prompt is submitted, this time tagging the Sentinel extension’s graph authoring tool. An example of the type of prompt to use is below:

“@Sentinel /graph-authoring I want to investigate the blast radius of a compromised user and what systems/ app/ devices that they accessed based on users authentication activity. Please use at least SignInLogs, NonInteractivelogs, DeviceLogon, Onprem AD logs, IdentityInfo, and AADRiskyUsers.

The graph should help investigate the following security outcomes:

What is the user's current risk level and risk score from Identity Protection?

Which applications and resources did a user authenticate to?

Are there sign-ins from risky IP addresses, Tor exit nodes, or anonymizers?

Are there non-interactive sign-ins from unexpected locations or devices?

Which machines did a user log on to locally/remotely (RDP)?

Which user accounts have been active on a compromised device?

A few guidance for data ingestion:

Ensure to filter out any data that has NULL or empty values for key Nodes and Edges
Filter all data for last 14 days
Do not map json arrays as Keys in Nodes or Edges”

Note: To ensure that the graph that is written matches the desired scenario, it helps to provide outcomes or guidance to the graph authoring tool.

If a Juypter notebook is not already open within the VS Code, Copilot will build a new notebook based on the prompt given. Once Copilot is done, select a kernel to run the notebook. This can be done from the top right of the Notebook:

Click on Select Kernel.
Click on Microsoft Sentinel.
Choose a pool option for the compute cluster.
Once a pool is picked, click on the run button next to one of the code cells to boot up the compute pool (this can take up to 5 minutes)
Once connected, users can either go through and click the run button next to the code cell to run the code or click the Run All button at the top of the Notebook.

For each cell in the Notebook:

Cell 2

This section of the notebook is for mporting the sentinel_graph library and configures Spark settings. This is essentially setting up the notebook environment for executing the rest of the code.

from sentinel_graph import notebook notebook.requires(sentinel_graph="0.3.8") spark.conf.set("spark.sql.parquet.datetimeRebaseModeInRead", "CORRECTED")

Cell 3

This section is performing more Sentinel specific configurations by defining which Sentinel workspace to use, which timerange to use, which tables to use, etc. This is defining which data sources should be considered when building the graph.

from pyspark.sql import functions as F from sentinel_lake.providers import MicrosoftSentinelProvider lake_provider = MicrosoftSentinelProvider(spark=spark) LOG_ANALYTICS_WORKSPACE = "Woodgrove-LogAnalyiticsWorkspace" # Auto-detected from the Microsoft Sentinel extension TARGET_USER = "ram723@int.zava-private.com" # Time filter — 7 days for broader blast radius context time_filter = F.col("TimeGenerated") >= F.expr("current_timestamp() - INTERVAL 7 DAYS") # --- IdentityInfo: user profile, roles, group memberships, risk --- df_identity_info = ( lake_provider.read_table("IdentityInfo", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter(F.lower(F.col("AccountUPN")) == TARGET_USER.lower()) ) # --- SigninLogs: interactive sign-ins to resources --- df_signins = ( lake_provider.read_table("SigninLogs", LOG_ANALYTICS_WORKSPACE) .filter(time_filter) .filter( (F.lower(F.col("UserPrincipalName")) == TARGET_USER.lower()) & (F.col("ResultType") == "0") # successful sign-ins ) )

Cell 4

This section is defining and building the nodes that will be used in the graph. The definitions include what events look like, which entities are involved, and how they are considered for each node type.

# 1. User node (the target user) user_nodes = ( df_identity_info .select( F.col("AccountUPN"), F.col("AccountDisplayName"), F.col("RiskLevel"), F.col("RiskState"), F.col("AssignedRoles"), F.col("GroupMembership"), F.col("BlastRadius"), F.col("Department"), F.col("JobTitle"), F.col("IsMFARegistered"), F.col("IsAccountEnabled") ) .distinct() .withColumn("AccountUPN", F.lower(F.col("AccountUPN"))) )

Cell 5

This section is building out the schema for the graph. The schema for a graph is taking the columns and details from the tables in cell 3 while also tying them to the nodes and edges built in cell 4.

# Build nodes first builder = ( GraphSpecBuilder.start() # === NODES === .add_node("User") .from_dataframe(user_nodes) .with_columns("AccountUPN", "AccountDisplayName", "RiskLevel", "RiskState", "AssignedRoles", "GroupMembership", "BlastRadius", "Department", "JobTitle", "IsMFARegistered", "IsAccountEnabled", key="AccountUPN", display="AccountUPN") # Then add edges and finalise into a GraphSpec spec = ( builder # === EDGES === .add_edge("AccessedInteractive") .from_dataframe(edge_user_resource_interactive) .source(id_column="UserUPN", node_type="User") .target(id_column="ResourceName", node_type="Resource") .with_columns("AppDisplayName", "TimeGenerated", "IPAddress", "ConditionalAccessStatus", "AccessType", "EdgeKey", key="EdgeKey", display="AccessType")

Cell 6

This cell will take the schema from cell 5 and will load it into the graph visual builder. This will give a sample of what the graphs made with this Notebook will look like. These samples are fully interactive and will give an example of how it will look within the Defender portal. For example:

Please note that the Authoring Agent may provide a different looking schema if following along with this example. The schema above is just meant to provide an example of what one will look like within a Notebook.

Cell 7

This cell is taking each of the following steps performed and is going to compile and build the graph based on the data from the Sentinel data lake. This may take a few minutes to perform.

With the custom graph built, the next step is to create a Graph Job to save the custom graph in the tenant for persistent use. If necessary, users can go back into the notebook to refine, expand, and improve the custom graph.

Publishing graph

Publishing a graph is the process of saving the graph in a tenant, allowing for the graph to be scheduled for recurring refreshes or as needed. This process saves the graph to the tenant and enables other SOC members to access this graph from within the Defender portal.

To publish a custom graph, this must go through a Graph Job. This option is available within the Notebook experience as a button near the top:

Clicking on the Create Scheduled Job button will open a new tab within VS Code with the jobs settings and the option to publish:

There are two types of job schedules:

On Demand: Saves the custom graph to the tenant and will persist the custom graph for 30 days. After 30 days, the graph will be auto deleted.
Scheduled: Saves the custom graph to the tenant and will rebuild with new security telemetry based on a user defined schedule.

Once everything is prepped, the custom graph can be published to the tenant by hitting the Submit button. Users can view and monitor the creation progress by finding the graph within the Sentinel extension navigation as it shows the graphs available for the environment:

Finding and selecting the custom graph will open up a new tab that shows details around the graph. This includes details around the name, creation status (creating, ready, etc), author, and publishing date.

Near the top, there are tabs for Job Details and Graph Query. These options allow the user to review the current Graph Job, make changes to the Graph Job, or query the graph within the notebook.

Querying the graph in Defender

Once the custom graph has been published and the creation status is Ready, users can query the new graph in the Defender Portal:

Expand the Microsoft Sentinel navigation.
Select Graphs.
Either find the card with the graph title or search for it within the menu.
Once found, click Query Graph to open it.

The graph will open in the schema view. The schema here is a visual representation of which nodes, edges, and relations are part of the graph. This is what was built in the notebook. To query it, a user can write GQL queries or use ones that are provided. For this example, a query provided in the Getting Started tab will be used. This is a generic query that will show everything in a graph:

// Visualize any graph MATCH (x)-[y]->(z) RETURN * LIMIT 100

More focused queries will yield more focused results. For example:

MATCH (n_user:User)-[e_ip:SignedInFrom]->(n_ip:IPAddress) MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMHERE' AND n_ip.IPAddress = 'IPADDRESSHERE' RETURN n_user, e_ip, n_ip, e_signin, n_app

MATCH (n_user)-[x]->() MATCH (n_user)-[e_signin:InteractiveSignIn]->(n_app:Application) WHERE n_user.UserPrincipalName = 'ENTERUSERNAMEHERE' RETURN *

From here, a user can continue the hunt, remediate the concerns, escalate this for further attention and remediation, or refine the graph as needed.

Refining Graphs

Throughout the process, the custom graph may need to be updated for various reasons, including:

The scope of the hunt/investigation has expanded due to new information or the hypothesis being updated based on findings
The original hypothesis of the hunt was incorrect or needs to be changed
Important nodes are missing from the graph and need to be added

To achieve this, return to VS Code and use the GitHub Copilot chat experience to add new telemetry, nodes, edges, or properties in the existing graph.

The below example illustrates adding Azure resources as new assets by prompting the Sentinel graph authoring tool and instructing it on what needs to be added.

Running the cells of the Notebook will yield an updated graph that includes the new changes:

Graph samples in the Sentinel VS Code extension

To help with learning, building, and using Sentinel graph, there are 5 graph samples included in the Sentinel extension within VS Code.

These can be found by clicking on the Sentinel extension and looking under Notebook Samples > Graphs. Each graph included contains a Jupyter notebook containing the graph schema and mappings, as well as graph queries which can be run against the graph.

These graphs ingest certain security telemetry and expect them to already exist within the Sentinel lake instance that is being used. If needed, the graph mapping can be updated to include/ exclude security telemetry as needed. These graph samples are also located within the Sentinel GitHub repository.

Let’s look at one of the sample graphs – Phishing Email Killchain to understand how it can help during a security investigation.

Using a graph: phishing email kill chain scenario

Phishing is the number one initial access vector, yet investigating a phishing campaign requires correlating data across multiple Sentinel tables: EmailEvents, EmailUrlInfo, UrlClickEvents, EmailAttachmentInfo, DeviceFileEvents, and DeviceProcessEvents. Each table uses a different join key (NetworkMessageId, AccountUpn, SHA256, DeviceName), and analysts must stitch results together manually across several Defender portals.

The core question every SOC analyst needs to answer is: “Who received the email, clicked the URL, downloaded the attachment, and executed it on their device?” In KQL, answering this requires 5+ sequential queries and 30–60 minutes of manual correlation. The Phishing Email Kill Chain graph fuses all of these tables into a single connected structure with 10 node types and 12 edge types, making it possible to answer that question in seconds with a single GQL traversal. SOC teams can create this graph in their tenant and start investigating phishing campaigns using graph-powered insights.

Investigation with the Phishing Email Killchain graph

Multi-hop traversal. The full kill chain from email to endpoint execution is a 4-hop path: Email → Attachment → Process → Device. In KQL, each hop is a separate join with a different key column. In the graph, it’s one MATCH clause.

Structural detection. Campaign topology is visible as the graph’s shape — senders fanning out to emails, emails fanning out to users, shared URLs converging into hubs. These patterns are structural properties requiring no aggregation queries.

Click-exposure overlay. The graph overlays email delivery and URL click paths in a single view. An analyst instantly sees which users received a phishing email AND clicked the embedded URL — no separate UrlClickEvents join needed.

Example queries

Below are three queries from the published phishing_email_killchain graph that demonstrate these capabilities. Each query is a single GQL statement that replaces multiple KQL joins.

Query 1: Full Kill Chain — Email to Endpoint

This query traces the complete attack path: phishing email → malicious attachment → process execution → endpoint device. In KQL, this requires joining 4 tables with different keys and temporal proximity filtering.

MATCH (e:Email)-[ha:HasAttachment]->(att:Attachment) -[tp:TriggeredProcess]->(p:Process)-[od:OnDevice]->(d:Device) RETURN e, ha, att, tp, p, od, d LIMIT 10

Figure 1: Two complete kill chains — Invoice_Q3.xlsm → EXCEL.EXE → DESKTOP-FIN01 and DocuSign_Contract.pdf.exe → cmd.exe → DESKTOP-SALES02. Each path is one traversal replacing 4+ KQL joins.

Query 2: Campaign Topology — Sender to Email to User to URL

This query visualizes the full campaign structure: which senders sent which emails, who received them, and what URLs were embedded. The graph’s fan-out shape immediately reveals the blast radius and shared infrastructure.

MATCH (s:Sender)-[se:Sent]->(e:Email)-[re:ReceivedEmail]->(u:User), (e)-[cu:ContainsUrl]->(url:Url) RETURN s, se, e, re, u, cu, url LIMIT 10

Figure 2: Campaign topology — 2 senders, 2 emails fanning out to 9 users and 2 URLs. The shared URL node (c0ntoso-share...) receiving edges from both emails reveals coordinated campaign infrastructure.

Query 3: URL Click Exposure — Who Clicked the Phishing Links

This query shows which emails contained URLs and which users clicked them. The Email → URL → User click chain is a single traversal that replaces joining EmailUrlInfo with UrlClickEvents.

MATCH (e:Email)-[cu:ContainsUrl]->(url:Url)<-[cl:ClickedUrl]-(u:User) RETURN e, cu, url, cl, u LIMIT 10

Figure 3: Click exposure — 3 users clicked phishing URLs from 3 different emails. Each cluster shows Email → URL → User, instantly identifying click-through victims.

These are just 3 examples of what is possible when using GQL on a graph. Users can author their own GQL queries to run on this graph to show other possibilities.

Additional graph samples

As mentioned, the Phishing Email Killchain graph is one of five graph samples that are available today for use within the VS Code Sentinel Extension. The remaining graphs are:

Behavioral Attack Chain

Ingests data from the SentinelBehaviorInfo, SentinelBehaviorEntities, AlertInfo, AlertEvidence, ThreatIntelIndicators, and BehaviorAnalytics tables to model the relationships between different detections, MITRE tactics/techniques, entities, and threat intel to high different traversals that are difficult to do with just KQL alone.

Databricks Outbound Exfiltration

Ingests data from the DatabricksNotebook, DatabricksSecrets, DatabricksDBFS, DatabricksClusters, DatabricksJobs, DatabricksSQLPermissions, IdentityInfo, AADUserRiskEvents, and BehaviorAnalytics tables to map Databricks notebook and cluster activities to the identities used in order to enable detections of unusual outbound data movement, privilege escalation, and data exfiltration patterns.

DNS C2 Beaconing

Ingests data from the DeviceNetworkEvents, DeviceInfo, and ThreatIntelIndicators to model DNS resolution patterns to detect C2 beaconing and other malicious patterns.

OAuth Privilege Escalation

Ingests data from the EntraServicePrincipals, AADRiskyServicePrincipals, and AADServicePrincipalSignInLogs tables to trace OAuth consent chains, credential abuse, and privilege escalation paths to identify hub users, over-permissions identities, and backdoor patterns that may exist.

Closing

This blog showcased an example of how a custom graph can be made with data within Microsoft Sentinel data lake and the help of GitHub Copilot, investigating a phishing email kill chain situation, and how to leverage the several graph templates that are provided in Sentinel.

Get started today by using one of the template graphs, building your own graph, or by checking out the public documentation for Sentinel graph.

Note: Custom graph API usage for creating graph and querying graph will be billed according to the Sentinel graph meter.

Public Documentation: https://learn.microsoft.com/azure/sentinel/datalake/sentinel-graph-overview

GQL Reference: Graph Query Language (GQL) reference for Microsoft Sentinel graph (Preview) | Microsoft Learn

Planning graph Costs: Plan costs and understand pricing and billing - Microsoft Sentinel | Microsoft Learn

Detection and automation, reimagined

Mohit_Kumar1 — Thu, 18 Jun 2026 18:31:03 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

How analytics rules, playbooks, workbooks, and hunting evolve in Defender—and why the new toolbelt makes detection engineering faster, automation richer, and hunting genuinely cross-platform.

If you build detections for a living, the move to Defender is one of the most meaningful shifts to your workflow in years—and for most teams, it’s a welcome one. Your existing analytics rules don’t disappear. Your playbooks don’t need to be rewritten. Your workbooks continue to function exactly as they do today. What changes is the scope of what you can detect, automate, and investigate from a single experience.

That scope now includes endpoint, identity, email, cloud apps, and Sentinel data together—enabling analysts to query across data sources in a single KQL experience, investigate from one incident queue, and automate with richer response actions. Custom detections introduce near-real-time detections with native Defender response actions. Security Copilot can help generate playbooks from natural language prompts. Advanced hunting now spans Defender and Sentinel data together, dramatically expanding what hunters can pivot across. Conduct end-to-end threat hunting with hunts. The result isn’t a smaller toolset or a forced replacement of what exists today. It’s an expanded one.

In this post, we’ll walk through the major shifts across detection engineering, automation, hunting, workbooks, and case management—including where existing investments carry forward unchanged, where the experience improves, and how to choose the right tool for the right scenario moving forward.

What this post covers

Detection: analytics rules and custom detections converge into a shared experience
Automation : playbooks are enhanced
Workbooks: same canvas, richer investigative context
Hunting: from Sentinel-focused hunting to cross-platform advanced hunting
Case management: investigations finally get a durable workspace
A quick note on watchlists
Persona implications, common misconceptions, and a practical “do this week” checklist

Detection: Analytics rules and custom detections converge

Detection engineering is more flexible in Defender.

Teams still have access to familiar scheduled analytics rules and SIEM-style detections and now gain access to custom detections—a faster, more modern detection model designed for Defender telemetry and near-real-time response.

Sentinel rule types:

Scheduled query rules – traditional KQL-based detections that run on a schedule
Microsoft security rules – Microsoft-managed detections for Defender services and other Microsoft security products
Anomaly rules – ML-driven behavioral detections
Threat intelligence rules – detections powered by indicator matching
Custom detections – modern detections powered by advanced hunting queries with near-real-time execution and native response actions

One of the biggest architectural shifts is the retirement of the Fusion analytic rule in favor of the Defender correlation engine. Instead of managing Fusion separately, analysts now benefit from correlation directly within Defender incident processing.

At the same time, the rules experience becomes simpler. Defender surfaces both Sentinel analytics rules and custom detections together in a single rules view.

What changes after onboarding to Defender

Several important operational changes happen automatically:

Fusion is replaced by the Defender correlation engine
Microsoft incident creation rules tied to Defender products are no longer surfaced separately
Related alerts are consolidated into richer incidents within Defender
Analytics rules and custom detections appear together in one experience

This also changes how organizations should think about detections moving forward.

Historically, Microsoft security alerts often flowed into Sentinel as individual security alerts generated by Microsoft products. In Defender, those alerts are correlated natively into a single incident queue, reducing duplicate incidents and simplifying investigations.

Why custom detections matter long term

Custom detections unlock new capabilities for detection engineering in Defender. They provide:

Faster, near-real-time streaming detections
Built-in response actions
Cross-platform visibility
Cost efficiencies for Defender telemetry
A streamlined authoring experience integrated with advanced hunting

As feature parity continues to improve, most organizations building new detections on Defender telemetry will likely standardize on custom detections moving forward.

That doesn’t mean analytics rules disappear. They remain critical for:

Cross-vendor SIEM use cases
Firewall and network telemetry
OT environments
SaaS and custom log scenarios
Broad correlation across non-Defender sources

The outcome is practical flexibility: your existing analytics rules and detections keep running in one rule interface that spans both worlds, so you can reach for the best engine for the data source and use case you’re solving.

What changes after Defender onboarding

Change	Detail
Fusion disabled	The advanced multistage attack detection (Fusion) rule is no longer supported. Its functions are replaced by the Defender correlation engine. Similar to the Fusion rule (advanced multistage attack detection), Defender correlation is also available in secondary workspaces, but only in the scope of Sentinel data in those workspaces.
Microsoft incident creation rules	Microsoft Security alert rules are no longer displayed. In Microsoft Sentinel in the Azure portal, security alerts are individual detections generated when Sentinel or integrated Microsoft security services identify suspicious or malicious activity in your environment. When Microsoft Defender products are connected to Sentinel in the Azure portal, their alerts flow into Sentinel as security alerts. These alerts are produced by Microsoft-managed detection logic and surfaced in Sentinel for unified triage. After enabling Sentinel in Defender, analytic rules do not trigger alerts. These security alerts can be seen and queried on the SecurityAlert table. The analytic rules that previously triggered the security alerts in the Azure portal won’t be visible in Defender.
Unified rules view	The custom detection rules blade under Advance Hunting in Defender displays both Sentinel analytics rules and custom detections in a single view.

Transition considerations

Once Fusion is automatically disabled, verify that XDR correlation is generating multi-stage incidents in Defender with alerts from several sources, and stop relying on Fusion-specific customizations or automation tied to Fusion incidents.
The XDR Correlation engine is not limited to Defender and Sentinel data sources.
Strengthen entity mappings (accounts, hosts, IPs) on your analytics rules to maximize correlation quality, and monitor post-transition incident volume for fewer, but richer, consolidated incidents.

When Defender connector is enabled in Sentinel (Azure portal), connector automatically replaces those rules and providing two-way integration. You can still use an automation rule with the product name that generated the alert.

Why this lands well: Two detection models, one rules view. You don’t pick a side, instead you reach for the right tool: custom detections for Defender-native signals with near-real-time response and analytics rules for cross-vendor SIEM use cases. The convergence is on the roadmap, not a forced cutover.

Custom detections versus analytics rules

Use when…	Custom detections (Defender)	Analytics rules (Sentinel)
Data source	Defender telemetry (endpoint, identity, email, cloud apps) in addition to Sentinel tables	Non-Defender, cross-vendor, and custom logs ingested to Sentinel
Speed/workflow	Faster, near real-time detections with native response actions. See custom detection rules.	SIEM detections after ingestion, automation through playbooks/automation rules
Detection logic	KQL, within Defender schema limits	KQL with full Sentinel flexibility

When custom detections fit best

Your detection is based on Defender signals (endpoint/identity/email/cloud)
You want faster detections and built-in XDR response actions
You operate primarily in Defender
Recommended as the default detection across Defender and Sentinel signals

When Sentinel analytics rules fit best

You need non-Defender data (firewalls, SaaS, OT, custom logs)
You need cross-source/cross-vendor KQL correlation in SIEM
You’re building classic SIEM use cases

Automation and SOAR: playbooks enhanced, not retired

In Azure Sentinel (legacy portal), playbooks are logic apps that automate response actions, typically triggered by automation rules on incident or alert creation. This provides robust SOAR (Security Orchestration, Automation, and Response) capabilities but requires analysts to manage playbook triggers and execution from the Azure interface.

Defender changes: In Defender, playbook usage is enhanced and slightly redefined ( Generate playbooks using AI in Microsoft Sentinel | Microsoft Learn).

Comparison

Capability	Azure portal	Defender
Manual triggers	Playbooks can be run manually on incidents, alerts, and entities from the Sentinel incident page Manual execution is a common way to test or perform analyst-driven remediation	Playbooks can run manually on incidents and alerts surfaced in the Defender incident queue Manual execution remains supported, but some entity-level manual actions are increasingly handled through native Defender experiences
Built-in response actions	Limited native actions Remediation typically relies on playbooks (logic apps) to perform actions such as isolating devices, disabling users, opening ITSM tickets, or sending notifications	Rich built-in Defender response actions available directly in the incident (e.g., device isolation, user containment, attack disruption) Reduces the need for custom playbooks for common containment scenarios; playbooks are used for orchestration and cross-tool workflows
Automation rule compatibility	Automation rules trigger playbooks on incident creation/update or alert creation Clear separation between Sentinel alerts and incidents	Incident-triggered automation rules apply to unified incidents (Sentinel + Defender) Alert-triggered rules act only on Sentinel-origin alerts The “analytic rule name” condition is key to scoping rules to Sentinel-specific detections in a unified incident model
AI and automation	No native Security Copilot experience Playbook logic is authored manually in logic apps	Security Copilot augments investigations and response – see Security Copilot with Microsoft Sentinel Playbook generator (preview) enables AI-assisted creation of playbooks from natural language prompts AI summaries and guided response reduce the need for bespoke enrichment-only playbooks

Key transition considerations

Review and adjust automation rules
Leverage built-in actions
Playbook testing
Slight delay in automation (up to ~5-10 minutes between incident creation and automation rule execution)
Dual automation strategy

Summary

All existing playbooks continue to run on Azure logic apps infrastructure (the playbook definition itself is not migrated). Defender surfaces these playbooks and allows triggering them, but you’ll still design and edit playbooks in the Azure portal’s logic apps designer—the available playbook triggers and actions are unchanged. No rewrites are required, but you should adapt how and when playbook triggers and actions are invoked to align with the new unified incident model. Playbooks remain a core part of your SOAR toolkit, and are now enhanced by on-demand usage and upcoming AI integration.

Why this lands well: Zero playbook migration. Your SOAR investment carries forward exactly as it is, and the new built-in Defender response actions (device isolation, user containment, attack disruption) cover the most common containment scenarios out of the box, so your custom playbooks can focus on the orchestration and cross-tool workflows that truly need them.

Workbooks: same canvas, better surroundings

Workbooks provide interactive visualizations and dashboards for investigation, monitoring, and reporting across Microsoft Sentinel data. With the move to Defender, workbooks remain a core analysis asset, while the surrounding experience improves through tighter integration with unified incidents, hunting, and cross‑product visibility.

Comparison

Capability	Azure portal	Defender
Authoring and storage	Workbooks are created, edited, and stored in Azure (log analytics/Sentinel) Full authoring experience available in the Azure portal	Same workbooks and storage (no duplication) Authoring still primarily happens in Azure; Defender focuses on consumption and navigation
Access and navigation	Accessed directly from Microsoft Sentinel → Workbooks Context switching required between Sentinel and other security tools	Workbooks are discoverable and accessible from Defender alongside incidents and hunting Reduced context switching when moving from an incident to visual analysis
Data scope and context	Visualizes Sentinel data sources connected to the workspace Limited native awareness of Defender XDR-generated context	Workbooks benefit from unified Sentinel + Defender signals available in the same investigation flow Better alignment with unified incidents and entities
Incident and investigation integration	Used as a parallel investigation aid; analysts manually correlate workbook insights with incidents	Workbooks complement the unified incident queue, enabling faster pivoting from incidents to dashboards and hunting views
Feature parity and enhancements	Full feature set for workbook creation and customization	No functional regression Incremental experience improvements through unified navigation and cross-product visibility rather than workbook-specific redesign

Key considerations

No migration is required
Azure remains the source of truth
Stronger investigative flow
Not replaced by Copilot
Consistent access model
Optional broader sharing

Best practices

Standardize key workbooks
Design for pivoting
Reuse, don’t duplicate
Pair with hunting
Review periodically

Why this lands well: Zero workbook migration. Every dashboard, every visualization, every reporting layer you’ve built keeps working and gets better surroundings: discoverable from incidents, paired with hunting, contextualized by unified entities.

Hunting: from focused Sentinel to cross-platform advanced hunting

Hunting and advanced hunting both support threat detection and investigation, but they differ in scope and use. Hunting in Microsoft Sentinel focuses on Sentinel logs and is best for hypothesis-driven KQL investigations within Sentinel. Retention of the data used for hunting follows Sentinel log settings. Advanced hunting in Microsoft Defender provides a unified experience across Sentinel and Defender XDR data, enabling cross-platform queries, real-time remediation, and automation. Defender data is typically retained for 30 days, with longer retention available through Sentinel data lake. In short, hunting is best for focused Sentinel investigations, while advanced hunting is built for broader, cross-platform analysis and response.

What changes

Sentinel queries and functions become view-only in Defender (can execute but not edit directly)
Editing requires returning to Azure portal during transition period
Major advantage: Advanced hunting in Defender allows querying across both Sentinel tables and Defender XDR tables in a single query
Query history shows all queries run across both data sources

Advanced hunting benefits

Cross-platform hunting: Single KQL query spans endpoint (Defender for Endpoint), email (Defender for Office 365), identity (Defender for Identity), and Sentinel data sources
Unified schema: All tables accessible in one query editor with schema browser
Saved Sentinel queries available: Your existing hunting queries remain accessible
Custom detections: Convert hunting queries into detection rules (Defender XDR custom detections for Defender tables; Sentinel analytics rules for Sentinel tables)

Comparison

Feature	Hunting (Sentinel)	Advanced hunting
Data scope	Sentinel logs only	Sentinel + Defender XDR
Portal	Sentinel	Defender
Retention	Based on Sentinel settings	30 days (Defender), longer via Sentinel
Actions	Create rules/incidents	Real-time remediation + custom detections
Complexity	Focused on Sentinel	Cross-platform queries

Why this lands well: One KQL query, four detection surfaces. Threat hunters now span endpoint, identity, email, cloud apps, and Sentinel in a single query—with real-time response actions one click away. Saved Sentinel queries carry forward; the canvas just got bigger.

From incident-centric to case-centric investigation

The detection, automation, and hunting shifts we just walked through all converge on the same question: once the SOC has a richer set of incidents, cross-platform hunts, and automated containment running, where does the longer-form investigative work actually live? In the Azure portal, the incident has always been the top of the work stack—there was nowhere above it to organize a multi-week campaign investigation, a proactive hunt, or an IoC chase across many incidents. Teams reached for OneNote pages, email threads, and external tickets. Defender closes that gap with a new primitive: the case.

Case management in Defender is a native, security-focused workspace for SecOps work that spans multiple incidents—including multi-incident campaigns, threat hunting, IoC and threat-actor tracking, and detection-tuning backlogs.

Cases are only available in Defender and require a Sentinel workspace connection. See Manage security operations cases natively in Microsoft Defender.

Comparison

Capability	Azure portal	Defender (cases)
Multi-incident container	Not available; incidents are the top-level work item	Cases natively link multiple incidents and IoCs
Workflow and status	Fixed incident statuses (New/Active/Closed)	Customizable case statuses defined by SOC admins (defaults: New, Open, Closed)
Task tracking	Not available	Built-in tasks with owner, priority, due date, and status
Collaboration	Comments on individual incidents	Rich-text comments, attachments (up to 10 per comment), and a full activity audit log
Linking	Not available	Link cases to incidents and to threat intel indicators (preview)
Access control	Microsoft Sentinel RBAC roles	Microsoft Defender unified RBAC or Sentinel roles (Reader/Responder/Contributor)

Service limits

100,000 cases per tenant
500 GB of attachments per tenant
100 linked incidents per case
See Microsoft Sentinel service limits for the full set of platform limits

Transition considerations

Develop guidelines for when analysts should create a case (e.g., multi-incident campaigns or proactive threat hunts)
If you currently use external ticketing systems (ServiceNow, JIRA) for multi-incident tracking, determine how cases complement or integrate with them

Why this lands well: Investigations finally have a home above the incident. Multi-incident campaigns, hunts, and IoC chases stop living in OneNote pages and external tickets, and start living next to the security data—with their own status, tasks, comments, and audit trail. Nothing about your existing incident workflow changes; cases simply give you a durable layer for the work that used to fall between the cracks.

A quick note on watchlists

Not everything in this transition is changing—and that’s a feature, not an oversight. Watchlists are a good example: a primitive that was already doing its job well, and that simply carries forward unchanged into the unified experience.

No changes. Watchlists remain an Azure Sentinel feature for semi-static, custom lookup tables.

Aspect	Azure portal	Defender
Surrounding context	Standalone Sentinel blade	Unified with Defender incidents, hunting, and entity pages

Transition considerations

Watchlists can be accessed under the configuration section as well as through watchlist queries alongside Defender XDR data
You can upload a watchlist created from a CSV or other source

Why this lands well: Your existing watchlists keep working, your existing KQL keeps working, and the surrounding context just got richer—the same lookup table now joins against Defender entities and incidents alongside Sentinel data. Zero migration, broader reach.

What this means for each persona

Persona	What changes in this part
Detection engineer	Two engines, one rules view Reach for custom detections on Defender signals (faster, native response actions); keep Sentinel analytics rules for non-Defender and cross-vendor SIEM Strong entity mappings matter more than ever—they fuel XDR correlation quality
SOAR/Automation owner	Zero playbook migration—logic apps stay where they are Re-aim automation rules at unified incidents Lean on built-in Defender response actions for routine containment Explore the playbook generator (preview) for AI-assisted authoring
Threat hunter	Your KQL canvas is now cross-platform Saved Sentinel queries carry forward (view-only in Defender during transition; edit in Azure) “Convert hunt to detection” becomes part of the daily loop
SOC analyst	Workbooks are right where the incident lives Hunting is one click from triage via “Go hunt” Built-in response actions reduce the playbook hops for common containment
Architect	Decide your detection-by-source policy: Defender data → custom detections; cross-vendor SIEM → analytics rules; firewalls/SaaS without native detections → Sentinel Plan a dual-automation period while incident triggers shift to unified

Clearing up common misconceptions

“My analytics rules will be deleted.”
No analytics rules deleted. Sentinel analytics rules continue to function and appear in the unified custom detection rules blade alongside custom detections.
“I have to rewrite my playbooks.”
No rewrite required. All existing playbooks continue to run on Azure Logic Apps. Defender surfaces and triggers them; authoring still happens in Azure.
“Custom detections fully replace analytics rules today.”
Not yet. Microsoft is converging them only when custom detections reach full parity.
“My workbooks need to be re-created in Defender.”
No need. Same workbooks, same storage, no duplication. Authoring stays in Azure; consumption improves in Defender.
“Fusion is still running quietly.”
It is not. Fusion is replaced by the Defender correlation engine. Verify XDR correlation is generating multi-stage incidents and retire any Fusion-tied customizations.
“Advanced Hunting and Hunting are the same thing.”
They’re complementary. Hunting is focused on Sentinel while advanced hunting spans Sentinel + Defender XDR with real-time response actions.

Do this week

Inventory analytics rules by source: Rules targeting Defender data (candidates for custom detections), rules targeting non-Defender (stay as analytics rules), rules targeting firewalls/SaaS without native detections (Sentinel).
Confirm strong entity mappings (accounts, hosts, IPs) on your active analytics rules—these drive XDR correlation quality.
Pilot one custom detection on Defender data with a built-in response action (e.g., device isolation) end to end.
Review your automation rules: which key on incident name, which key on analytic rule name, which trigger playbooks. Plan the dual-automation period.
Validate that all existing playbooks remain triggerable from the unified incident queue.
Run one advanced hunting query that joins Defender XDR tables with Sentinel tables—a small “aha” for the team.
If you use Security Copilot, enable the embedded experience and the Microsoft Sentinel integration to surface incident summaries and guided response.

Continue the series

All six parts of this series publish close together. Each one stands alone—pick the angle that matters most to you, or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

The component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 4 – The governance shift: RBAC, URBAC, data lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi-tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

Anatomy of the change

Mohit_Kumar1 — Wed, 17 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Incidents, alerts, correlation, and data—what actually changes with the new platform, and why it works in your favor.

When you open Microsoft Sentinel in Microsoft Defender for the first time, the shift feels immediate: investigations are cleaner, workflows are more connected, and analysts can move through incidents with far less context switching.

Instead of pivoting between multiple queues, disconnected investigations, or duplicated alerts, SOC teams gain:

One unified incident queue
One attack story
One place to investigate and respond
One connected experience across Microsoft security signals

But the biggest improvements happen behind the scenes. The move from the Azure portal to Defender brings together incident correlation, alert handling, automation, and data investigation in ways that help SOC teams reduce manual work, improve visibility, and accelerate response.

This post breaks down the core changes, what remains familiar, and the practical steps teams can take now to prepare.

What we will cover

In this post we’ll guide you through some changes as you begin using Defender:

A more connected incident experience
Alerts and schemas evolve for easier investigations
Your underlying data architecture stays intact
Content hub and existing investments continue to work

We’ll also cover:

What these changes mean for different SOC roles
Common misconceptions
A practical “do this week” checklist
For a complete overview of the new experience, visit the Microsoft Defender portal overview on Microsoft Learn.

A more connected incident experience

Incidents are the center of security operations. This is where many teams will immediately notice the benefits of Defender.

In Defender:

Correlation is no longer done by “Fusion” and now is managed through Defender’s correlation engine, creating alerts once across Defender and Sentinel data
Correlation is richer and more connected
Related activity is grouped together more effectively
Analysts investigate through an attack story instead of isolated alerts

The result is a more streamlined investigation flow where one campaign or attack chain can be represented as a single incident instead of several disconnected records that must be manually stitched together.

Analysts gain access to:

Attack story visualization
Related assets and evidence
Investigation timelines
Correlated activities
Cross-domain context
Integrated hunting experiences

For organizations using Sentinel data lake and graph capabilities, analysts can also better visualize attack propagation paths and understand how activity may spread across environments. This helps reduce investigation time while improving clarity and confidence during triage.

Incident management – side by side

Aspect	Azure portal	Defender
Incident list	Time range picker for filtering incidents by date Filter and sort by status, severity and product name Auto-refresh every 30 seconds Product name (Sentinel or Defender) and alert count visibility	Centralized list of incidents with Defender incidents that have a retention period of 180 days while the Sentinel incidents have a retention period that depends on the underlying data retention settings in log analytics (hot interactive retention) In Defender, incidents can be sourced from different services and the retention of the data related to these incidents depends on the default data retention period for these services If you need to retain Defender incident data for longer than 180 days, you must explicitly extend the retention period in the Sentinel workspace settings Incidents and alerts are now shown under the investigation and response menu and can be filtered based on source service The incidents page has a tab with alerts grouped into the incident, as well as a tab showing similar incidents Customizable columns and sortable incidents by ML-powered priority score Exporting and link copying options
Incident details	Overview tab with timeline showing alerts and bookmarks Entities and similar incidents matching UEBA insights Comments and tasks for SOC processes	Sections for attack story, alerts, assets, investigations, evidence and responses, and always-visible incident detail pane Actions include triggering Sentinel playbooks, exporting incident details in PDF, merging or linking incidents Activities tab indicates if automation rules or playbooks were run as part of the incident response An alert can be promoted to incident Blast radius analysis of propagation path (requires Sentinel data lake and graph) is a graph-based visualization in Microsoft Defender that shows how an attack can spread from a compromised entity to other critical assets Security Copilot integration optimizes incident investigation and response
Incident creation	Created by Sentinel analytic rules, or Fusion from bookmarks/hunting queries	Each connected Microsoft Sentinel workspace is treated as a separate data source In multi-workspace setups, you designate one primary workspace and only the primary workspace will receive Defender incidents and alerts and correlation with Defender alerts will also only occur in the primary Secondary workspaces can continue to ingest Defender tables if configured in the table menu in Defender, while correlation in the secondary workspaces is scoped to data within the secondary workspace Fusion will be replaced by correlation in the primary and secondary workspaces Defender can still merge similar incidents based on detected commonalities Incidents can be created by analytic rules, custom detections, or alerts from different data sources—including Sentinel—while manual incident creation is on the roadmap
Management actions	Owner assignment, status (new/active/closed), severity, comments, tags, investigation graph, run playbook	Stays the same, plus: update name, change severity, assign to users/teams, add tags, update status (active/in progress/resolved), close with resolution classification, run Sentinel playbooks directly, request Defender experts, export PDF, merge/link incidents AI-generated playbooks (with Security Copilot) with enhanced automation rules allow you to complete automation when a security alert is created
Collaboration	Comments (HTML/markdown), bookmarks	Activity log for tracked comments and audits, tasks feature with assignments and due dates
Closing	Classification required (true positive, benign positive, false positive, undetermined)	Resolution classification required for closure
Querying	KQL through log analytics	KQL through advanced hunting or Sentinel data lake exploration, where advanced hunting allows querying Sentinel and Defender data in a single unified experience
Security alerts	Visible as part of an incident	Can be promoted to incident, and also part of an incident
Alert details	Alert sub-menus from incident Alert details include severity, status, analytics rule, etc. Entity profile pages	Full alert properties with MITRE tactics mapping Entities and evidence with contextual actions Activities timeline, alert tuning tool, and links to correlated incidents Customizable alert timeframe filter up to 180 days of alert history
Attack story	Legacy investigation graph requiring entity mapping in analytics rules Limited to incidents up to 30 days old Greater context switching required	Chronological attack story with replay capability Graph filtering (Preview) by severity, status, service source and entity type Incident graph with full attack scope and spread Entity pivoting from attack graph “Go hunt” for direct advanced hunting across devices, files, etc. Immediate remediation actions without losing context

What remains the same

Incident properties (title, description, severity, MITRE ATT&CK enterprise framework, tactics and techniques mapping) are preserved. Incidents still aggregate alerts and entities as evidence. Manual incident creation from hunting queries is still supported. Alerts and incidents can still be created by API or Logic App.
The Microsoft Sentinel Responder role is the minimum least privilege role required by a SOC analyst to manage incidents, cases, tasks, threat intelligence, and automation rules related to incident management. This role maps to the security Operator in URBAC (Unified RBAC).

Correlation becomes more connected

One of the most important evolutions is the move from Fusion correlation to the Defender correlation engine.

This shift helps:

Reduce duplicate incidents
Improve multi-stage attack correlation
Consolidate related activity into richer investigations
Reduce manual merging work for analysts

The goal is simple: give analysts fewer, higher-quality incidents with more context attached.

Existing analytics rules continue to work, while newer custom detection experiences continue to evolve alongside them.

Microsoft Security alert rules are no longer displayed. With Sentinel in the Azure portal, security alerts are individual detections generated when Sentinel or integrated Microsoft security services identify suspicious or malicious activity in your environment. When Defender products are connected to Sentinel in the Azure Portal, their alerts flow into Sentinel as security alerts. These alerts are produced by Microsoft managed detection logic and surfaced in Sentinel for unified triage. After enabling Sentinel in Defender, analytic rules do not trigger alerts. These security alerts can be seen and queried on the SecurityAlert table; the analytic rules that previously triggered the security alerts in the Azure portal won’t be visible in Defender.

The custom detection rules blade in Defender displays both analytics rules and custom detections in a single view.

Why this lands well: One correlation engine instead of two means fewer duplicate incidents, fewer manual merges, and an investigation surface (attack story + blast radius) that’s richer than the legacy investigation graph it replaces.

Considerations for incidents and correlation

Verify that any SOC automation closing or updating incidents using the Sentinel API is redirected to the Microsoft Graph security API.
Incident IDs, AlertIDs and URLs will change (Defender uses its own identifiers).
Incident names are auto generated by the Defender correlation engine and may differ from Sentinel analytics rule names. Update triage routing or SLA workflows that rely on the name of the incident. Customers can apply correlation exclusions at the analytic rule level or at the tenant level which will not affect the incident title and will then not merge alerts.
Review any workflow that depends on Fusion-generated incidents, since Fusion is replaced by Defender correlation.
In Defender, teams can use tags, saved queries, and custom hunting tables to capture and organize investigation context after a hunting exercise, providing flexible ways to carry forward important findings.

Alerts and schemas evolve for easier investigation

As Sentinel continues to evolve within Defender, incident management becomes more streamlined, connected, and cost-efficient. Instead of relying on separate “Microsoft security alerts” analytics rules to generate incidents from Defender workloads including endpoint, identity and cloud applications now are automatically correlated by the Defender engine into a unified incident queue.

This new approach helps eliminate duplicate incidents and gives security teams a cleaner, more consolidated investigation experience by bringing related alerts together into a single incident. It also enables organizations to modernize their operations by shifting from alert-level automation to incident-centric workflows, while taking advantage of Defender-native automation capabilities.

Beyond operational simplicity, this model can also help optimize costs. Since alert data is available without requiring additional log analytics ingestion, organizations can be more selective about ingesting raw logs and focus instead on scenarios where deeper investigations, long-term retention, or compliance requirements make it necessary.

Key transition actions

To transition effectively organizations should first retire legacy “Microsoft incident creation rules” analytics rules and rely on the individual Defender connectors for alert ingestion. Automation strategies should then be reviewed and adjusted, as incident handling shifts from multiple alert-driven records to a single, correlated incident model—often requiring incident-level workflows.

The integration also introduces bi-directional incident synchronization between Sentinel and Defender, enabling consistent state management across both environments, although the operational focus should move to Defender. Additionally, the new alert schema separates alert metadata and evidence. Organizations are encouraged to adopt the AlertInfo and AlertEvidence tables in place of the legacy SecurityAlert schema (supported in Advance Hunting) to support richer investigation scenarios.

Field-level differences – alert metadata

Concept	Azure (SecurityAlert)	Defender (AlertInfo)
Alert ID	SystemAlertId	AlertId
Name	AlertName	Title
Severity	Severity	Severity
Product / Provider	ProviderName	DetectionSource / ServiceSource
Description	Description	Title / Description equivalent
Time	TimeGenerated	TimeGenerated

The key shift here is naming normalization standardized across Defender signals.

Field-level differences – entity/evidence modeling

Concept	Azure (SecurityAlert)	Defender (AlertEvidence)
Entities	JSON (Entities)	Rows (1 row per entity)
Entity type	Inside JSON	EntityType column
Host	JSON field	DeviceName, DeviceId
User	JSON field	AccountName, AccountSid
IP	JSON field	IPAddress
File	JSON field	FileName, SHA256

The key shift here is denormalized JSON pivoting to strongly typed columns for easier joins, filters, and aggregations.

Querying differences – before and after

Azure (classic):

SecurityAlert | extend Entities = parse_json(Entities) | mv -expand Entities | where Entities.Type == "account"

Defender (recommended):

AlertInfo | join AlertEvidence on AlertId | where EntityType == "Account"

By leveraging the unified Microsoft Defender connector, your SOC gains efficiency (no double handling of the same threat), clarity (one incident is just one campaign or attack chain), and potential cost savings.

Why this lands well: The new schema isn’t a migration tax, it’s a query model that’s easier to write against, easier to teach new analysts, and avoids the JSON parsing Sentinel detection engineers have previously managed.

Your underlying data architecture stays intact

In this process, you can be assured that your log analytics workspace, retention settings, data export, and governance controls all carry forward.

Aspect	Azure portal	Defender
Storage	Log analytics workspace in Azure	Log analytics workspace in Azure (unchanged)
Storage tiers	Analytic logs, Basic logs, Auxiliary logs, Archive	· Analytics logs, Basic logs, Auxiliary logs, Archive (unchanged) · Changing the tier for Basic logs or Auxiliary logs requires you to go to the log analytics workspace experience in the Azure portal. Sentinel data lake for long-term retention onboarding is optional and available once Sentinel is configured in the Defender portal · If the primary workspace is onboarded to Sentinel data lake, the Basic logs and Auxiliary log tables are converted to the data lake tier
Workspace default retention	Configured in log analytics workspace settings	Workspace default retention continues to be configured in the Azure portal or through CLI/API (unchanged)
Per-table retention	Configured per table in log analytics	Per-table retention and tier management is available directly in Defender

Note on data lake availability: Microsoft Sentinel data lake is not yet available in every Azure region. Check current region coverage on Microsoft Learn before planning onboarding: Geographical availability and data residency in Microsoft Sentinel. Your data lake is provisioned in the same region as your primary Sentinel workspace.

Content hub and existing investments continue to work

Content Hub remains the mechanism for discovering and deploying solution packages (connectors, analytics rules, workbooks, playbooks) for Sentinel. Over 450+ solution templates from Microsoft, partners, and community contributors are available in the Sentinel solutions catalog.

Transition considerations

Content hub is fully available in Defender. There is no need to switch back to the Azure portal for content management.
Repositories (CI/CD for Sentinel content) and Community continue to function in Defender.
No changes to content update mechanisms. Solutions continue to receive updates through Content Hub as before.

What this means for each persona

Persona	What changes in this part
SOC analyst	One unified incident queue. Attack story replaces the legacy investigation graph. “Go hunt” is one click away. Bookmarks are gone—use tags and saved queries instead.
Detection engineer	“Microsoft security alerts” analytics rules retire. AlertInfo + AlertEvidence become the canonical schema for new detections and hunting queries. Fusion-dependent logic moves to XDR correlation behavior.
Automation/SOAR owner	Re-point any incident-update automation to the Microsoft Graph security API. Shift triggers from alert-level to incident-level. Review SLA and routing workflows that key on incident names.
Architect	Decide your primary workspace explicitly—only the primary receives Defender incidents and alerts and gets XDR correlation. Plan retention deltas (Defender XDR 180 days versus Sentinel-extended).
Compliance / Data owner	Log analytics, retention, and per-table controls are unchanged. Data lake onboarding is optional. Document the data residency story for any auditor questions—the storage layer hasn’t moved.

Clearing up common misconceptions

“Fusion still runs in the background.”
It does not. Fusion is replaced by the Defender correlation engine on the primary workspace.
“My Sentinel data has to migrate.”
It does not. The log analytics workspace is unchanged. Storage, retention, and per-table settings carry forward.
“I lose my existing analytics rules.”
Sentinel analytics rules continue to function and are visible in the unified custom detection rules blade alongside custom detections. The roadmap converges them only when custom detections reach full parity.
“Incident IDs will stay the same, so my tickets won’t break.”
Incident IDs and URLs change in Defender. Update any external ticketing or webhook integration.
“My Content Hub solutions need to be re-installed.”
They don’t. Content Hub is still available in Defender. Solutions, repositories, and community all continue to work.

Get started

Designate your primary Sentinel workspace and document the decision. Only the primary receives Defender incidents/alerts and gets XDR correlation.
Inventory automations that update or close incidents through the Sentinel API. Mark them for re-pointing to the Microsoft Graph security API.
Identify external systems keyed on incident IDs, URLs, or incident names. Flag for update.
Pilot one new hunting query using AlertInfo + AlertEvidence to build team familiarity with the new schema.
Confirm Content Hub solutions and repositories pipelines are visible and operational from Defender.
If long-term retention is on your roadmap, confirm your primary workspace region is supported by the data lake before planning onboarding: Geographical availability and data residency.

Continue the series

All six parts of this series are published together. Each one stands alone—pick the angle that matters most to you or read them in order.

Part 1 – Beyond a portal move: The strategic shift to Defender

Why the transition matters at the architecture and program level—the executive framing, the deadline, and the analyst validation.

Part 3 – Detection and automation, reimagined

How analytics rules evolve into custom detections, the shift from alert-driven to incident-driven SOAR, and how hunting changes.

Part 4 – The governance shift: RBAC, URBAC, data Lake, and MSSP

The move from Azure RBAC to URBAC, the data lake operating model, and multi -tenant patterns.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

A practical plan: the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

Introducing New Additions to Microsoft Sentinel Normalization and ASIM

derricklee — Wed, 17 Jun 2026 15:00:00 GMT

TL;DR: New ASIM parsers for Azure Firewall, Key Vault, AWS CloudTrail (EC2, S3, IAM), and 10+ third-party products. Two new schemas — Asset Entities and AI Agent Events. Plus changelogs on GitHub and a heads-up on an upcoming breaking change in ProcessEvent parsers.

What's New

Security teams deal with logs from dozens of sources, each with its own schema. This painpoint makes it harder to write detections that work everywhere. The Advanced Security Information Model (ASIM) solves this by normalizing logs into a common schema, so a single analytic rule can cover a wide variety of sources without worrying about the source schema.

Over the past few months, we have shipped a wave of new parsers, schemas, and improvements to ASIM. Here's everything you need to know.

ASIM Parsers

Azure Firewall

Azure Firewall logs were previously only supported from the AzureDiagnostics table. Now, we support the dedicated resource-specific tables:

Table	ASIM Schema
AZFWDnsQuery	DNS
AZFWNetworkRule	NetworkSession
AZFWApplicationRule	WebSession

Azure Key Vault

Logs that are going to both AzureDiagnostics and resource-specific table AZKVAuditLogs are now normalized in the Audit Event schema.

Azure Synapse SQL and Azure SQL Database

Logs that are going to both AzureDiagnostics and resource-specific table SQLSecurityAuditEvents are now normalized to the Audit Event schema.

Azure Traffic Analytics

We have added support for the NTANetAnalytics table from Azure Traffic Analytics under the Network Session schema.

AWS CloudTrail

AWS CloudTrail previously only mapped to the Authentication schema. Now, you can correlate EC2, S3, and IAM activity through ASIM alongside your Azure telemetry:

AuditEvent — Normalized EC2 events
FileEvent — Normalized S3 events
UserManagement — Normalized IAM and Cognito events

Additional Parser Support

We have also integrated the following third-party sources into ASIM:

Authentication — Normalize sign-in and identity events for cross-source threat detection.

CheckPoint Smart Defense
Cisco IOS
Cisco ISE
Fortinet FortiGate
Okta (OktaSystemLogs)
Palo Alto — PAN-OS
Palo Alto — Global Protect
VMware vCenter

Web Session — Normalize proxy and web gateway traffic.

Cisco Umbrella Proxy Logs

New ASIM Schemas

We have created two new schemas to expand support new use cases.

Asset Entities — Provides a normalized view of asset inventory data, enabling you to correlate files and assets across detections and investigations.
AI Agent Events — Normalizes telemetry from AI-driven workflows and autonomous agents.

Other Changes

GitHub Changes

Changelogs for every ASIM parser have been created to better help you understand updates and bug fixes we have implemented. As an example, here is the change log for the Authentication ASIM unifying parser. View Changelog

Breaking Changes

While aligning our ProcessEvent parsers to the official documentation, we found a naming inconsistency in the _Im_ProcessCreate function:

Documentation specifies the parameter as targetusername_has
Deployed parsers used targetusername

What we changed: Both parameter names are now accepted.

What you need to do: Update your analytic rules and queries to use targetusername_has. The legacy targetusername parameter will be deprecated in Summer 2026.

What's Next

We are continuing to expand ASIM with new parsers and schema capabilities to make detection authoring and log correlation even more powerful.

BlueVoyant is also investing heavily in the ASIM ecosystem, building parsers that enhance detection coverage for their customers. See how they are using ASIM to operationalize detections.

Want to get involved? Browse the ASIM parsers on GitHub, file issues, or contribute your own. We'd love to hear your feedback.

Announcing Public Preview: Agent Identities Asset Connector for Microsoft Sentinel

Krishna_Sagar_B_V — Tue, 16 Jun 2026 17:00:01 GMT

As organizations accelerate adoption of AI agents across Microsoft 365 and enterprise environments, security teams face a fundamental shift:

Agents are becoming first-class identities and securing them requires understanding both their behavior and their identity context.

We are excited to announce the Public Preview of the Agent Identities Asset Connector for Microsoft Sentinel, a foundational capability that delivers identity context for AI agents, completing the visibility required for end-to-end agentic security.

Completing the picture: From activity to identity-aware security

With the A365 (Agent 365) Observability Connector and M365 Copilot connectors, Sentinel customers already have deep visibility into:

Agent activity and execution flows
Prompts, tools, and data access
Cross-agent interactions

However, activity data alone cannot answer critical security questions, such as:

What is this agent?
What permissions does it have?
Who owns or governs it?
How does it fit into the broader identity ecosystem?

The Agent Identities Asset Connector addresses this gap by bringing agent identity data into the Sentinel data lake, enabling correlation with activity signals to deliver enriched, contextual security insights.

Introducing the Agent Identity data model

This connector introduces four core asset tables that together define the agent identities:

Agent Users

Represents human principals responsible for agents, including owners, sponsors, or administrators.

What it provides:

Ownership and accountability relationships
Mapping of agents to human context
Organizational and governance linkage

Why it matters for security:

Enables accountability and traceability for agent actions
Helps answer: Who is responsible for this agent?
Critical for incident response, governance, and compliance audits

Sample Query

EntraAgentUsers | where tenantId has 'TENANTGUIDHERE' | summarize by displayName, userPrincipalName, agentIdentityBlueprintId, agentIdentitySPID, mailNickname, accountEnabled

Agent Identities

Represents the agent itself as a first-class identity, including its lifecycle and configuration.

What it provides:

Unique identity for each agent
Lifecycle state (e.g., active, disabled)
Metadata describing the agent type and context

Why it matters for security:

Elevates agents from hidden service constructs to first-class security principals
Enables identity-aware detection and hunting
Forms the foundation for monitoring agent behavior at identity granularity

Sample Query

EntraAgentIdentities | where tenantId has 'TENANTGUIDHERE' | summarize by displayName, createdDateTime, accountEnabled

Agent Blueprints

Represents the definition and design of agents, how they are constructed and what capabilities they are intended to have.

What it provides:

Blueprint or template defining agent behavior
Configuration patterns and logical design
Reusable constructs across multiple agents

Why it matters for security:

Enables understanding of intended vs. actual behavior
Identifies systemic risks across agents built from the same blueprint
Supports proactive risk assessment and governance at scale

Sample Query

EntraAgentIdentityBlueprints | where tenantId has 'TENANTGUIDHERE' | summarize by displayName, createdDateTime, isDisabled, groupMembershipClaims, signInAudience, publisherDomain

Agent Blueprint Service Principals

Represents the service principals tied to agent blueprints, which define the permissions and execution boundaries.

What it provides:

Service principal identities used by agents
Permission scopes and access configurations
Linkage between blueprint design and runtime execution

Why it matters for security:

Exposes what access an agent actually has
Enables detection of over-permissioned or misconfigured agents
Critical for enforcing least-privilege access and Zero Trust principles

Ingesting this data opens the SOC to new opportunities for use cases that meet the growing needs for awareness of agentic workloads within the environment.

A Unified Asset Graph for Agentic Security

Together, these four tables will enable a connected agent identity graph depicting connections such as Agent User → Agent Identity → Agent Blueprint → Service Principal → Resources/Data.

This enables Sentinel customers to gain access to key insights and options, such as:

Tracing who owns an agent
Understanding how it is configured
Analyzing what permissions it operates with
Correlating with what it actually does (activity)

Unlocking Asset + Activity Correlation

With the addition of these agent identity tables, Sentinel customers can now combine activity data from the A365 Observability and Copilot connectors with the asset information brought in from the Agent Identities connector to unlock deeper visibility into security scenarios:

Identity-aware investigations that correlate agent actions with identity, ownership, and permissions to identify which agents performed an action and understand how/why it was allowed
End-to-end traceability by showing the full execution chains, highlighting the identity, tools, and data that was used by an agent
Enriched detection and hunting by joining identity, asset, and SIEM data together within Sentinel data lake to better detect anomalous behavior relative to permissions, identify risky configurations, and improve detection fidelity.
This reflects a core Sentinel principle:

Asset data enriches activity data to provide deeper, more actionable security insights.

From Observability to Agentic Security

The Agent Identities connector marks a shift from traditional observability to true agentic security within Sentinel. While customers previously had strong visibility into agent behavior, they often lacked the critical identity and governance context needed to fully understand and control their agent ecosystem. This release bridges that gap by providing a comprehensive, identity-centric view that connects agent activity with ownership, permissions, and relationships. As a result, customers can evolve from simple observability to enriched context and ultimately to actionable control, enabling end-to-end agent governance, identity-driven detections, and graph-based security insights. By establishing agents as raw first-class identities within Sentinel and unifying identity and activity signals, this capability lays the foundation for a cohesive security model that integrates human, non-human, device, and AI agent identities into a single, unified security data platform within Sentinel data lake from Entra, M365, and other sources.

Getting Started

To unlock the full value of agentic security in Microsoft Sentinel, enable:

✅ Install Agent 365 and M365 Copilot Solutions in Content Hub
✅ Enable Agent Identities Asset Connector provided by the solution
✅ Enable A365 Observability Connector provided by the solution
✅ Enable M365 Copilot Connector from the Microsoft Copilot solution

Together, these provide a comprehensive asset + activity view for AI agents in your environment.

Final takeaway

Effective security requires both visibility and context. With the Agent Identities connector, Sentinel now delivers both for AI agents.

Transform your security operation with a unified experience in Defender

Mohit_Kumar1 — Tue, 16 Jun 2026 16:00:00 GMT

Co-authored with Lizet Pena, Caroline Mutua, Alvin Kua and Marco Sudahl

Security operations teams today are being asked to do more than ever: respond faster, manage increasing data volumes, reduce operational complexity, stay ahead of evolving threats, and balance cost and efficiency.

That’s why Microsoft is bringing Microsoft Sentinel into Microsoft Defender: to bring together SIEM, XDR, threat intelligence, AI, and automation into a single experience.

By March 31, 2027, all Microsoft Sentinel customers will be automatically transitioned to Defender. But this transition is about far more than a new interface. It’s an opportunity to modernize the SOC, streamline operations, and unlock capabilities designed for the AI-first era of security operations.

This blog kicks off a six-part series to help you confidently navigate the transition ahead of time, understand what changes (and what doesn’t), and maximize value along the way.

Why this post, and why now

This is the first of a six-part helping customers transition their Sentinel experience from the Azure portal to Defender:

Part 1 – Beyond a portal move (You are here)
○ Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data
○ Part 3 – Detection and automation, reimagined
○ Part 4 – The Governance Shift: RBAC, URBAC, Sentinel data lake, and MSSP
○ Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and checklist
○ Part 6 – The AI-First SOC: Copilot, UEBA, threat intelligence, and SOC optimization

The strategic shift in one paragraph

Defender represents the convergence of Microsoft’s security capabilities into a single operational experience. Instead of switching between disconnected tools and workflows, security teams can work from one integrated environment spanning SIEM, XDR, threat intelligence, AI-powered investigation and response, cross-domain correlation, and SOC automation. Defender helps analysts investigate incidents faster, enables better collaboration across teams, and reduces operational friction across the security lifecycle. Most importantly, it creates a foundation for the future of AI-assisted and agentic security operations.

Why migrate early?

While the transition becomes mandatory in 2027, organizations that start earlier can begin realizing value immediately.

Moving to Defender today helps organizations:

Streamline analyst workflows with a unified incident queue
Reduce investigation time through advanced cross-product correlation
Take advantage of Security Copilot experiences integrated into Defender
Simplify operations across Sentinel and Defender products
Modernize governance and access management models
Prepare their SOC for AI-driven investigation and response
Take advantage of the latest innovations.

Rather than treating migration as a compliance deadline, many customers are approaching it as a strategic modernization initiative for their SOC.

What changes, and what stays the same

One of the most important things to understand is that this is not a “rip and replace” migration. The foundational elements of Microsoft Sentinel remain intact while the operational experience evolves.

Area	What changes	What stays
Management plane	Defender becomes the primary experience	The Sentinel portal in Azure remains usable until March 31, 2027
Incident model	Unified incident queue across Sentinel + Defender, XDR correlation, attack story view	Log analytics remains the core storage layer
Access control	Unified RBAC (URBAC) preferred for cross-product, fine-grained access	Azure RBAC continues to work until role migration to URBAC; service principals are not supported in URBAC
Data	Data lake for long-term retention and advanced analytics	No workspace migration required
Cost	Data lake can materially reduce overall cost by shifting high-volume logs out of the analytics tier, also allowing longer term retention at a lower cost (up to 12 years)	No change in the business model after moving over to Defender

The key takeaway: customers are not rebuilding their environments from scratch. Existing investments continue to work while the operational layer becomes more integrated and intelligent.

What Defender unlocks

The transition to Defender is designed to unlock capabilities that are difficult to achieve in siloed environments.

Security Copilot: Defender enables deeper integration with Security Copilot, including:

AI-assisted incident triage
Natural-language investigation workflows
Guided response recommendations
Natural language to KQL experiences

Copilot capabilities help reduce analyst fatigue and accelerate investigation workflows.

Unified correlation: With a single engine across all your alerts you can create richer, more contextual incidents spanning identities, endpoints, email, cloud apps, and data sources. This means you spend less time stitching alerts together manually and more time focused on high-confidence incidents.

Data lake: Sentinel data lake introduces new flexibility for long-term retention, large-scale analytics, and cross-workspace investigation scenarios. For many customers, this creates opportunities to balance visibility, compliance, and cost more effectively.

Case management: Collaborate across teams to respond to incidents.

Playbook generator: Create custom workflow automations using natural language.

Sentinel graph: Visualize relationships across users, devices, and activities to investigate attack paths, blast radius, and root cause.

Sentinel MCP server: Let AI agents and Copilot query Sentinel in natural language through a unified, identity-secured Model Context Protocol interface

Triage agent: Autonomous Security Copilot agent that triages high-volume alerts (phishing, identity, cloud) with AI reasoning and a transparent rationale.

What this means for you

Different roles feel this transition differently. Use this as a quick orientation as later posts go deep on each.

Role	What to pay attention to
Security analyst	New incident queue, attack story view, and Copilot-assisted triage – your day-to-day surface changes most.
Detection engineer	Custom detections become the forward direction; analytics rules continue to work but the model is evolving from SIEM to XDR detection.
SOC manager	URBAC governance, data lake blast-radius, and incident-centric automation reshape how you run the SOC.
MSSP and Partner	Multi-tenant view (up to 100 tenants), planning to support up to 1k tenants, unified incident queue, dual RBAC model – Lighthouse is still needed for Azure resources.

Clearing up common misconceptions

“The transition is optional.”
No. Customers must migrate their experience by March 31, 2027.
“We need to migrate our workspaces.”
You do not need to migrate log analytics workspaces simply to use Microsoft Sentinel in Defender.
“This is only a UI change.”
Defender introduces meaningful operational and architectural improvements across investigation, correlation, governance, automation, and AI-assisted workflows.
“The transition itself increases costs.”
There is no additional licensing charge simply for using Sentinel in Defender. Optional capabilities—such as Security Copilot or Sentinel data lake usage—may introduce additional costs depending on adoption and usage patterns.

How to get started

Align your stakeholders: Brief your SOC leadership and detection engineering leads on the March 31, 2027 deadline and the platform shift narrative.
Form a readiness team: Identify a small working group (analyst + engineer + SOC manager + identity owner) to own the readiness effort.
Explore Defender: Start familiarizing yourself with Defender and workflows.
Assess your data strategy: Review how leveraging the data lake may fit into your future strategy.
Follow Tech Community: Get more information in this series

Additional resources

Further reading: The Microsoft Security Community post Migrate Sentinel to Defender – Why it is a security architecture decision, not just a portal change frames the same thesis from an architectural lens. For the official transition guidance, start with the Microsoft Learn article Connect Microsoft Sentinel to the Microsoft Defender portal.

Continue the series

This is the first of six parts. The remaining posts will be published over the coming days. Each one stands alone, so you can read them in order as they go live or jump to the angle that matters most to you once it's out:

Part 2 – Anatomy of the change: Incidents, alerts, correlation, and data

If you want component-level mechanics: how the XDR correlation engine replaces Fusion, why incidents are no longer alert-centric, and what changes (and doesn’t) in your data architecture.

Part 3 – Detection and automation, reimagined

If you write detections or run automation: the shift from analytics rules to custom detections, the move from alert-driven to incident-driven SOAR, and how hunting evolves.

Part 4 – The governance shift: RBAC, URBAC, Sentinel data lake, and MSSP

If you own identity, access, or multi-tenant operations: the move from Azure RBAC to URBAC, Sentinel data lake, better blast-radius identification, and the MSSP model.

Part 5 – Your readiness playbook: Adoption helper, costs, APIs, and the checklist

If you need a practical plan: a walk-through of the Defender adoption helper, cost reality, API strategy, and the migration checklist.

Part 6 – The AI-first SOC: Copilot, UEBA, Threat intelligence, and SOC optimization

If you want to see the destination: how Security Copilot, UEBA, threat intelligence, and SOC optimization combine into a fundamentally different operating model.

Microsoft Sentinel Blog articles

What’s new in Microsoft Sentinel: August 2026

Sentinel SIEM

AI-powered playbook generator expanded to all Sentinel customers in the Defender portal [Generally Available]

UEBA Anomalies are now built on top of Behaviors, along with expanded coverage through new data sources [Public Preview]

Sentinel data lake

Nested API support in Codeless Connector Framework [Public Preview]

Multi-account ingestion for Auth0, CrowdStrike, and Salesforce [Generally Available]

Microsoft Threat Intelligence connector [Generally Available]

Additional resources

Stay connected

Building Microsoft Sentinel Connectors in Minutes with the Sentinel Connector Builder Agent

Overview

The Lab Environment

Prerequisites

Deploying the Mock API

Building the Connector with the Sentinel Connector Builder Agent

Testing the Connector

Deploying and Enabling the Connector

Next Steps

Conclusion

AI-powered playbook generator, now available to more customers

What’s new

What playbook generator does

Who is it for

How to get started

Ensure you have the right permissions

Availability

Smarter signals, broader coverage: UEBA anomalies on top of Behaviors layer and new data sources

What's new in Sentinel UEBA and Behaviors layer

Adding context to every behavior—use case

Scenario: Detecting a compromised FortiGate device

Examples of observed behaviors include:

KQL examples

Expanding visibility scross the environment—use cases

Scenario: Identifying suspicious web access with Zscaler telemetry

KQL example

Scenario: Identifying suspicious FortiGate configuration backups

KQL example

Getting started

Why it matters

Public Preview: Nested API Support Comes to Microsoft Sentinel CCF

Building a CCF Nested API Pull Connector: A Technical Lab Walkthrough

Quick Start

Prerequisites

The Lab Environment

Deploying the Mock API

How the Nested Step Pattern Works

The KQL That Links the Two Calls

The DCR and the KQL Transform

The Table Schema and Connector Definition

Deploying the Sentinel Connector

Enabling and Verifying Data

Adapting This Pattern to Your Own API

Next Steps

Conclusion

What’s new in Microsoft Sentinel: July 2026

Sentinel SIEM

Custom detections support in Sentinel repositories [Public Preview]

Behind the Build with Gigamon: Enriching Sentinel with network-derived telemetry

Sentinel data lake

Table insights [Public Preview]

Connectors [Public Preview]

GitHub Audit logs (via Azure Storage Blob)

Agari

Airlock Digital

Additional resources

Blogs and documentation:

Upcoming events:

Featured event: Aug 1–6, Black Hat USA 2026 (Mandalay Bay, Las Vegas)

Upcoming webinars:

Stay connected

Announcing the ASIM Parser Creation Agentic Experience

Why this matters

What is the ASIM parser creation agentic experience?

Where can I find these skills?

What you can expect in practice

Where this helps most

Closing

Building toward an Agentic SOC: A Portable, Autonomous Malware Investigation Agent