rss.livelink.threads-in-node

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

Natee_Pretikul — Tue, 30 Jun 2026 16:00:00 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, enables 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 reduces fragmentation and accelerates investigation.

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

This manifests in 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 addressing 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 gives 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

Reminder: Next Tuesday 6/23 at 9AM PST we will be hosting an 'Ask Microsoft Anything' session on Tech Community for the Sentinel SIEM Migration Experience!

Trevor_Rusher — Thu, 18 Jun 2026 22:25:31 GMT

Join us for a live demo and AMA on the Microsoft Sentinel SIEM migration experience. We’ll show how the experience helps teams move from legacy SIEMs like Splunk and QRadar into Microsoft Sentinel with a more guided, lower-friction path. We’ll cover what it does today, how it works, and the questions customers ask most, then open it up for live Q&A.

Link here: Ask Microsoft Anything: The Microsoft Sentinel SIEM Migration Experience

Hope to see you there!

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.

Reset Data Lake?

DaithiG — Fri, 12 Jun 2026 09:54:30 GMT

Hi,

Is the only want to reset or change the Data Lake to contact Microsoft Support. We've a ticket open for a few days now. The Data Lake was setup as in a test subscription and we really need to delete it/reset it and start again under a proper production subscription.

Thanls

Detecting AI agents and non-human identities in Microsoft Sentinel: the classic-agent blind spot

Marcel_Graewer — Tue, 09 Jun 2026 13:57:23 GMT

Build 2026 made the direction official. The industry is moving from the app era into the agent era, and Microsoft spent a real share of the keynote on securing agents across their lifecycle, from discovering what is exploitable to governing what is running in production. On the identity side the centerpiece is Microsoft Entra Agent ID, now generally available, which gives AI agents first-class identities and extends Conditional Access, Identity Protection, and full audit logging to them.

That is good news for agents you build the new way. It is not the whole picture, and the gap is where most SOCs will get hurt first.

Modern agents are covered. Classic agents are not.

Entra Agent ID draws a hard line between two kinds of agent.

Modern agents are created through the Agent ID platform, each backed by an agent identity blueprint. They carry a proper Agent ID, a full audit trail, and the complete set of governance capabilities, including Identity Protection for Agents, which establishes a baseline for an agent's normal activity and flags anomalies automatically.

Classic agents are everything that came before, or that gets built outside the platform: AI agents implemented as ordinary service principals or app registrations, for example Copilot Studio agents created before Agent ID was enabled, or any home-grown automation calling Graph with client credentials. In the Entra agent registry they appear with "Has Agent ID: No," and that flag matters, because the Agent ID protections apply to identities that actually hold an Agent ID. Classic agents sit outside Identity Protection for Agents and Conditional Access for Agents.

Here is the uncomfortable part. The non-human identities you already run, the service principals behind your pipelines, your integrations, your scripts, your pre-platform Copilot Studio bots, are almost all classic agents. They tend to outnumber your human accounts, they have no MFA in any meaningful sense, and a credential added to one does not show up in the Azure portal. The new platform protections do not reach them. Until you migrate them, the only place you get detection coverage on that population is your SIEM.

So this is the job Sentinel does that Agent ID does not: detect risky behavior on the classic, service-principal-backed agents that the platform cannot yet protect.

The telemetry you have, and the one switch people forget

Three tables carry most of the signal.

AADServicePrincipalSignInLogs records service principal authentications, the client-credentials sign-ins your agents and automation use. No user, no MFA, just an app proving it holds a secret or certificate.

AADManagedIdentitySignInLogs does the same for managed identities.

AuditLogs records directory changes, including the one that matters most for persistence: a new credential added to an application or service principal.

One practical warning before any of this works. Service principal and managed identity sign-in logs are not streamed by default. You have to enable those categories explicitly in the Entra diagnostic settings feeding your workspace. Plenty of teams write the detection, never check, and never notice the table is empty. Verify that first.

Detection 1: a new credential on a service principal or app

Adding a secret or certificate to an existing service principal is one of the cleanest persistence techniques in a Microsoft cloud. The attacker compromises a privileged user or app, drops a fresh credential on a service principal that already holds useful Graph permissions, and now has access that survives password resets and session revocation. It maps to MITRE T1098.001, Account Manipulation: Additional Cloud Credentials. For a classic agent it is especially nasty, because there is no Identity Protection baseline watching it.

// Detection 1: new secret or certificate added to an application or service principal // MITRE T1098.001 - Account Manipulation: Additional Cloud Credentials AuditLogs | where OperationName has_any ("Add service principal", "Certificates and secrets management") | where Result =~ "success" | extend Initiator = coalesce( tostring(InitiatedBy.user.userPrincipalName), tostring(InitiatedBy.app.displayName)) | extend InitiatorIp = tostring(InitiatedBy.user.ipAddress) | mv-apply Target = TargetResources on ( where Target.type =~ "Application" | extend TargetName = tostring(Target.displayName), TargetId = tostring(Target.id), KeyChanges = Target.modifiedProperties ) | mv-apply Prop = KeyChanges on ( where tostring(Prop.displayName) =~ "KeyDescription" | extend NewKeys = parse_json(tostring(Prop.newValue)), OldKeys = parse_json(tostring(Prop.oldValue)) ) | extend AddedKeys = set_difference(NewKeys, OldKeys) | where array_length(AddedKeys) > 0 | project TimeGenerated, Initiator, InitiatorIp, TargetName, TargetId, AddedKeys | order by TimeGenerated desc

The operation filter catches the three shapes this event takes in the log: "Add service principal," "Add service principal credentials," and "Update application - Certificates and secrets management." The modifiedProperties parsing isolates the KeyDescription change, and set_difference confirms a key was actually added rather than removed, so rotating out an old credential does not, on its own, fire the rule.

False positives come from legitimate rotation and from automation that provisions app credentials (CI/CD, infrastructure as code). The initiator is the discriminant. A credential added by your deployment pipeline's service account at the usual time is routine. The same change initiated by an interactive admin out of hours, or by an account that never normally touches app credentials, is what you want to surface. Allow-list the expected initiators, not the targets.

Detection 2: a classic agent signing in from a first-seen IP

A service principal that has only ever authenticated from your Azure regions and suddenly signs in from somewhere new is a strong signal that its credential has been lifted and is being used elsewhere. Service principals have stable, boring network behavior, which makes a first-seen IP a far cleaner indicator for them than it is for roaming human users. This is the behavioral baseline Identity Protection gives you for free on modern agents, rebuilt in KQL for the classic ones it ignores. MITRE T1078.004, Valid Accounts: Cloud Accounts.

// Detection 2: classic-agent service principal signing in from a previously unseen IP // MITRE T1078.004 - Valid Accounts: Cloud Accounts let baseline = 14d; let detection = 1d; let KnownIPs = AADServicePrincipalSignInLogs | where TimeGenerated between (ago(baseline + detection) .. ago(detection)) | where tostring(ResultType) == "0" | summarize KnownIPSet = make_set(IPAddress) by AppId; AADServicePrincipalSignInLogs | where TimeGenerated > ago(detection) | where tostring(ResultType) == "0" | lookup kind=leftouter KnownIPs on AppId | where set_has_element(KnownIPSet, IPAddress) == false | summarize FirstSeen = min(TimeGenerated), Resources = make_set(ResourceDisplayName, 10) by ServicePrincipalName, AppId, IPAddress | order by FirstSeen desc

The query builds a per-application baseline of source IPs over the previous two weeks, then flags any successful sign-in today from an address outside that set. Two tuning notes. Brand-new service principals have no baseline, so they surface on first use. That is usually worth seeing once, but you can exclude AppIds younger than the baseline window if it gets noisy. And if your agents egress through shifting cloud IP ranges, widen the comparison from an exact IP to the autonomous system number or a known-range allow-list, otherwise you will chase your own infrastructure.

This complements Agent ID, it does not replace it!

The endgame is not to run these rules forever. It is to shrink the population they apply to. Inventory your tenant for agents marked "Has Agent ID: No," prioritize the ones holding sensitive Graph permissions, and migrate them onto the Agent ID platform, where Identity Protection and Conditional Access take over the baselining you are doing here by hand. Microsoft has signaled a migration path from classic to modern agents. Treat these two detections as the coverage you need in the meantime, and as a permanent safety net for anything that never makes the move.

If you do one thing this week: enable the service principal sign-in log category, deploy detection 1, and pull a list of every service principal that had a credential added in the last 90 days. That list alone tends to be more interesting than people expect.

Cheers, Marcel

The Worm in the Supply Chain: How Defender for Endpoint and Sentinel for SAP BTP Caught Shai-Hulud

MartinPankraz — Mon, 08 Jun 2026 10:52:16 GMT

On 29 April 2026, malicious versions of multiple SAP ecosystem npm packages were briefly published, creating a supply-chain exposure for SAP Cloud Application Programming (CAP) development environments and CI/CD pipelines.

For a brief window that morning, affected developers have executed a credential-stealing payload on a workstation or, in higher-impact cases, within a CI/CD pipeline.

SAP developers don't usually think of themselves as a juicy npm target. CAP, BTP, Fiori - that's enterprise turf, not crypto-stealer type territory – Until it is. Join me for the ride.

See our latest click-video for an even more dynamic experience of SAP compromises.

Affected packages and scope

Four official npm packages from the SAP development ecosystem were published in malicious versions that day. Security researchers are calling the campaign "Mini Shai-Hulud" - the little cousin of the worm family that has been chewing its way through open-source registries for months. So, the "mini" part is a generous description in my opinion.

Shai-Hulud has wriggled directly into the SAP supply chain, and that detail alone deserves a pause... SAP CAP is now interesting enough to have become a target.

Four packages, all wearing legitimate SAP branding, all quietly swapped for evil twins:

@cap-js/sqlite v2.2.2 @cap-js/postgres v2.2.2 @cap-js/db-service v2.10.1 mbt v1.2.48

These packages are not peripheral dependencies. The @cap-js/* modules are part of the SAP CAP Model used across custom development on SAP BTP, while mbt is the Cloud MTA Build Tool commonly embedded in CI/CD workflows that package and deploy Multi-Target Applications to BTP and on-premises environments. At roughly 930,000 weekly downloads, the combined exposure created meaningful downstream attack surface.

The good news: SAP spotted the compromise fast, yanked the bad versions, and shipped clean replacements. The official guidance lives in SAP Security Note 3747787 - which carries the list of indicators of compromise, file hashes, and mitigation steps.

Enough theory and evidence talk! Now, SHOW ME the detection!

When the worm stirs beneath the sand, weak defenses vanish first.

Observed telemetry in Microsoft Security products

See below excerpt of Microsoft Defender for Endpoint from a compromised developer machine. The worm was neutralized immediately. Check the detection time (same day of release):

Windows Defender AV detected malware ToString: DefenderDetection: File: /Users/User***/Projects/dara-api-manager-ui/node_modules/mbt/File***.js, Sha256: *** [Trojan:JS/SPchnStlr.BB], BlockingStatus: Prevented, BlockingStatusPriority: 900 DetectionTime: 2026-04-29 11:52:11Z DetectorName: Microsoft.Cyber.ObservationDetectors.DefenderConcreteDetector Observations (2): DefenderObservation Description: Defender detected and quarantined 'Trojan:JS/SPchnStlr.BB' in file 'File***.js' ThreatCategory = Trojan, ThreatFamily = SPchnStlr,

How the Threat Actors Operationalized the Stolen Data

The compromise allowed harvesting GitHub tokens, AWS/Azure/GCP secrets, npm credentials, Kubernetes config, SSH keys, .npmrc and .git-credentials files, and CI/CD environment variables.

The hackers created a public GitHub repository on the victim’s own account, tagged with the description “A Mini Shai-Hulud has Appeared“ to exfiltrate their reaping. Within hours, more than a thousand such repositories were visible in public GitHub search.

For additional views on the topic check out the blogs of our Sentinel for SAP partners: Onapsis, Pathlock, and SecurityBridge.

Containment and Impact Reduction

If you were not as lucky as the developer using Defender for Endpoint and VS Code, you need end to end monitoring of your landscape in and around SAP. Once the worm is loose with cloud tokens it may appear in various unexpected places.

Microsoft Sentinel Solution for SAP covers your ERP crown jewels, your SAP BTP landscape and allows informed correlation with the rest of your IT estate. Microsoft’s correlation engine:

ensures traceability
automatic attack disruption and
just-in-time hardening of potential attack paths.

Developers using the cloud-based IDE SAP Business Application Studio are out of reach by Defender for Endpoint but profit from threat monitoring through Sentinel for SAP BTP integrating SAP BTP’s malware scanner the same way.

See this in action in this click-video and in below screenshot.

SOC analysts get actionable insights and tailored guidance from Security Copilot once SAP BTP signals are added to the Microsoft incident graph - no matter where the threat involving SAP originates from.

Getting Started with Sentinel Solution for SAP

Rollout of Sentinel for SAP BTP can happen immediately. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections.

Sentinel for SAP which covers your ERP solutions and more, requires configuration of SAP Integration Suite as intermediary step. Learn more from our deployment guide. Check out the security content reference for more info out-of-the-box detections

Final Words

This incident illustrates how far the SAP BTP attack surface now extends and why patching alone is insufficient once malicious code reaches developer tooling and build infrastructure. Effective defense also requires telemetry, correlation, and response coverage across SAP and non-SAP environments.

See you out there folks!

#Kudos to Mahesh Mandva and Cameron Gardiner on riding shai-holud with me.

Feel free to reach out to talk more about SAP Cyber Security.

Cheers, Martin

Useful Links

MSSP migration to Unified portal: how are you sequencing your customer portfolio?

AnthonyPorter — Mon, 08 Jun 2026 01:13:15 GMT

Following the automation and SOAR discussion, I wanted to open a conversation specifically focused on the MSSP and multi-tenant side of the migration, because this is where the coordination challenges are an order of magnitude higher than the technical ones.

A few things I am working through before writing this up as Part 5 of the migration series.

On Workspace Manager: Microsoft's own documentation now points you away from Workspace Manager at the point of onboarding to the Defender portal, directing you to Microsoft Defender multitenant management instead. For MSSPs who built their operating model around Workspace Manager, this is a significant structural change. For those implementing now, the recommendation is to go straight to the multitenant portal. I am interested in what the transition has looked like in practice for teams who were mid-flight on Workspace Manager when this became clear.

On access delegation: one of the more honest framings I want to include in the article is around the GDAP plus Unified RBAC gap. A Microsoft employee confirmed in the RSAC 2026 thread that Unified RBAC support for GDAP in the Defender portal is on the roadmap with no firm date. MSSPs choosing between Entra B2B and the governance relationships model today are making an architectural call that is difficult to reverse. I want to present this accurately, and real experience from practitioners will sharpen that framing.

On the connector deployment constraint: you cannot deploy connectors from a managed workspace configured with Azure Lighthouse alone, you also need GDAP. This makes a layered delegation architecture, Lighthouse plus GDAP plus B2B or governance relationships, necessary rather than optional. I am curious whether MSSPs are already running this layered model or whether most are still trying to make Lighthouse work as a single mechanism.

On migration sequencing: the question I want to ask specifically is how teams are structuring their customer portfolio migration. Are you running waves based on customer complexity, based on contract renewal timing, based on customer risk appetite, or some other factor? And when something goes wrong in one tenant's migration, how are you containing the impact on the rest of the programme?

Sharing the full article once it is written. Happy to discuss anything above in more detail in the thread.

SentinelHealth: Scheduled Rule Retry Logging Does Not Match Docs

SomeZnimav — Wed, 03 Jun 2026 09:41:53 GMT

## Objective

I am working on a health checks architecture for Microsoft Sentinel analytic rules. The goal is to build a set of monitoring queries/approaches that cover rule execution failures, configuration issues (entity mapping, partial success), rule audit tracking, and auto-disabled rule detection.

## My Current Approach

So far I have built monitoring for the following areas using the SentinelHealth and SentinelAudit tables:

- Scheduled rule window failures (retry exhaustion)

- NRT rule execution delays (cumulative delay over 25 minutes)

- Partial success and configuration issues (entity mapping drops, alert size limits, semantic errors) with transient error codes filtered out

- Auto-disabled rules detection

- Rule disable/delete audit tracking via SentinelAudit + AzActivity

## The Issue: Scheduled Rule Retry Logging

The documentation at https://learn.microsoft.com/en-us/azure/sentinel/monitor-analytics-rule-integrity#scheduled-rules states that when a scheduled rule fails, it is retried 5 more times on the same window (6 total attempts). It also provides this query to detect completely skipped windows:

```kql

_SentinelHealth()

| where SentinelResourceType == @"Analytics Rule"

| where SentinelResourceKind == "Scheduled"

| where Status != "Success"

| extend startTime = tostring(ExtendedProperties["QueryStartTimeUTC"])

| summarize failuresByStartTime = count() by startTime, SentinelResourceId

| where failuresByStartTime == 6

| summarize count() by SentinelResourceId

```

This query assumes that each retry attempt is logged as a separate event in SentinelHealth, all sharing the same QueryStartTimeUTC. You would then count 6 failure records per startTime to identify a fully skipped window.

However, in practice I am seeing different behavior. I ran a diagnostic query with a 90-day lookback (480 non-success events total, 73 unique rules). Every single event had a count of 1 per unique (SentinelResourceName, startTime) combination. No grouping of retries was observed at all.

I then found an actual failed-window event that confirms this. Here is the record:

- Rule: Port scan detected (ASIM Network Session schema)

- Status: Failure

- Description: "Rule's scheduled run at 06/01/2026 10:43:55 failed after numerous attempts. It will be re-executed over the next scheduled time."

- Issue Code: SemanticErrorInQuery

- Only 1 SentinelHealth record exists for this failed window

The Description field says "failed after numerous attempts" which indicates the retries happened internally, but only one consolidated Failure event was written to SentinelHealth after all retries were exhausted. The individual retry attempts do not appear as separate records.

This means the failuresByStartTime == 6 query from the documentation would never match this pattern, because there is only 1 record per failed window, not 6.

## Why This Matters

Yes, completely skipped windows are rare. In my 90-day dataset most failures were permanent types (SemanticErrorInQuery, QueryGeneralError) that would not benefit from retries anyway. But they still happen, and if a tenant experiences a transient issue that causes a higher rate of failed windows, the documented query would silently return nothing.

For my health checks I have rewritten the detection to simply look for Status == "Failure" with Description containing "failed after numerous attempts" which matches the actual consolidated event Sentinel writes.

## Questions

Is the documented failuresByStartTime == 6 query still accurate? Or has the retry logging behavior changed to write a single consolidated event per failed window?
Are there specific failure types or conditions where individual retries are logged as separate events? Perhaps transient failures behave differently from permanent ones in this regard?
For anyone else building health monitoring on SentinelHealth - am I missing any important use cases beyond what I described above?

Any clarification would be appreciated.

What’s new in Microsoft Sentinel: May 2026

Sowmys — Thu, 04 Jun 2026 10:07:32 GMT

Welcome to the May edition of What's new in Microsoft Sentinel. This month’s updates focus on unified role-based access control (RBAC), ecosystem breadth, AI-agent security, and high-assurance identity.

RBAC and row-level scoping are now generally available, giving security teams a single, granular permissions model across Sentinel and the Microsoft Defender portal and enabling multi-team SOC collaboration. The Sentinel connector catalog has passed 400 connectors, expanding coverage across Microsoft and third-party data sources and helping customers and partners onboard new data faster with the Codeless Connector Framework (CCF). The Agent 365 connector, now in public preview, brings AI agent telemetry into Sentinel data lake as first-class standardized signals so you can monitor agent behavior alongside identity, endpoint, and cloud activity. Finally, Entra Verified ID partner integrations in Microsoft Security Store are now generally available, delivering high‑assurance identity verification that makes account recovery after compromise far safer and significantly reduces the risk of re‑compromise.

Read on for the full list of updates across Sentinel in May.

Sentinel innovations:

Sentinel SIEM
Sentinel data lake
Microsoft Security Store

Sentinel SIEM

Unified role-based access controls and row level scoping [Generally available]

Sentinel now delivers general availability of two powerful access management capabilities: Unified RBAC and row-level data scoping. Together, these innovations provide a consistent, end-to-end model for controlling who can access data and what actions they can take — extending unified permissions management across the Defender portal while enabling granular, row-level visibility within a single Sentinel workspace.

With Unified RBAC, organizations can simplify and centralize permissions across security workloads, reducing operational overhead, while row-level scoping enables secure collaboration across multiple teams by ensuring users only see data aligned to their role or scope. This milestone unlocks more scalable, multi-team SOC operations without the need for workspace segmentation, helping us to advance toward fully unified, granular access control across Microsoft Security.

Tenant groups [Public preview]

Managing security across multiple tenants just got simpler. Tenant Groups in the Microsoft Defender multi-tenant portal (MTO) give managed security service providers (MSSPs), cloud service partners (CSPs), and multi-tenant security teams a flexible way to organize tenants into logical groupings such as customer segment, geography, or operational priority, and instantly switch views with a single click. This streamlined experience reduces noise, improves investigation focus, and aligns to how teams actually work, all while respecting existing permissions and access controls. Learn more.

Out-of-the-box integrations for Sentinel automation [Public preview]

Out-of-the-box (OOTB) integrations for Sentinel automation brings a centralized catalog to easily discover, configure, and manage both Microsoft and third-party integrations. With simple, authentication-based setup, users can quickly add integrations and seamlessly incorporate them into playbooks. The experience places OOTB and custom integrations side by side, with enhanced with smart search, recommendations, and duplicate prevention to streamline automation workflows end to end. Learn more.

UEBA enhancements [Public preview]

Microsoft Sentinel UEBA continues to evolve with improvements that simplify management and expand detection coverage.

A dedicated UEBA tab view in the Sentinel settings page consolidates UEBA and behaviors settings, making configuration easier to find and manage. Learn more.
UEBA insights and anomalies now support the OktaV2_CL table alongside the existing Okta_CL table, extending anomalous activity and anomalous MFA failures detections to customers using the newer Okta connector format, without requiring new anomaly types. Learn more.
UEBA extends GCP Audit Logs coverage with five anomaly detections for login activity, privileged actions, resource deployments, secret/KMS key access, and infrastructure usage. Learn more.

Together, these updates make UEBA easier to operate while extending its visibility into identity and behavior signals from additional cloud and identity providers.

⁠Read the latest blog from the Microsoft Defender Research Team to learn more about Microsoft Sentinel UEBA and binary feature stacking, which uses clear binary signals to help establish behavioral context and inform investigation and detection decisions.

Threat Intelligence – TAXII Export connector [Generally available]

Sentinel supports threat intelligence export through the built-in Threat Intelligence – Trusted Automated Exchange of Intelligence Information (TAXII) Export connector, giving customers a standards-based way to share curated Structured Threat Information Expression (STIX) objects with supported TAXII 2.1 platforms. Configured from the Defender portal, the connector handles destination setup and intelligence delivery to external platforms. The capability supports cross-organization intelligence sharing for collective defense and centralized management in multi-tenant environments, with use cases across government, critical infrastructure, and large distributed organizations. Additional enhancements are planned, including more export options and expanded destination support. Learn more.

Decision-stage resources for SIEM migration to Sentinel

The AI-powered SIEM migration experience helps teams analyze detections, identify required data sources and connectors, and plan a phased move to Sentinel. But, customers still need help turning that analysis into a clear decision. To support that step, we’re introducing two new customer-facing resources: the Sentinel SIEM Migration Decision and Planning Guide, which explains the migration journey, outputs, and decision checkpoints before execution, and the Decision-Stage Customer FAQ, which answers common questions around disruption, cost, dual running, detection coverage, and delivery support. Together, these resources help make migration conversations more concrete and move teams more quickly from evaluation to a clearer, lower-risk next step.

Learn more:

Read the blog: AI-powered SIEM migration experience announcement
Download the guide: Decision and planning guide
Download the FAQ: Decision-stage customer FAQ
Learn more: SIEM migration experience documentation
Register for live AMA (Jun 23 at 9am PT): Live Microsoft Tech Community AMA on SIEM migration

Sentinel data lake

400+ Sentinel data connectors

The Sentinel connector catalog now includes 400+ connectors, providing broad, ready-to-deploy coverage across Microsoft and third-party data sources. Customers can flexibly ingest security data into Microsoft Sentinel analytics tier or the data lake tier. The Codeless Connector Framework (CCF) and VS code-based connector builder agent enables partners and customers to onboard new data sources faster and scale the catalog. Discover connectors in the Sentinel Content hub within the Defender portal or build custom connectors when needed. Learn more.

Agent 365 connector [Public preview]

Agent 365 connector streams AI agent telemetry from Agent 365 into Sentinel data lake, giving SOC teams visibility into agent behavior alongside identity, endpoint, and cloud signals. With the Agent 365 connector in place, Sentinel data lake becomes the system of record for agent security, turning activity such as data exposure or access drift into first-class security signals that analysts can correlate, hunt across, and investigate. Telemetry is normalized and to mapped to standard Advanced Security Information Model (ASIM) schemas, ready for analytics and detections, and end-to-end investigations can run through KQL, graph, and MCP-powered workflows. Install the connector with a single click from Sentinel Content Hub in the Defender portal. Learn more.

CCF support for Azure Blob Storage [Public preview]

Sentinel Codeless Connector Framework (CCF) supports Azure Blob Storage as a data source, providing an ingestion pattern designed for high-volume security data. Partners and customers can build CCF connectors that read from Blob Storage through a durable architecture that buffers spikes, handles backpressure, and reduces data loss risk during outages or throttling, making ingestion more reliable for variable or distributed pipelines. The pattern broadens compatibility with partners already streaming logs to Azure as part of their audit data delivery, with Cloudflare and Netskope as early adopters. App Assure further provides engineering-backed support for designing, validating, and remediating the Azure Blob Storage CCF connector integration. Learn more.

Data filtering and splitting [Generally available]

At RSAC, we announced built‑in filtering and splitting capabilities in Microsoft Sentinel, which is now generally available. As security teams ingest more data, it is important to optimize security data pipeline by controlling what data is ingested and in which tier. With filtering and splitting natively integrated into the Defender portal, security teams can shape data before it reaches Sentinel, without switching tools or managing custom JSON files. Using simple KQL‑based transformations directly in the UI, you can filter low‑value events and intelligently route data, making ingestion optimization faster, more intuitive, and easier to manage at scale.

Filtering at ingest time allows you to remove low‑value or benign events to reduce noise, lower unnecessary processing, and ensure high‑signal data drives detections and investigations.
Splitting enables intelligent routing of data between the analytics tier and the data lake tier based on relevance and usage.

Together, these capabilities help you balance cost and performance while scaling data ingestion sustainably as your digital estate grows. Learn more.

Transition your Sentinel connectors to the Codeless Connector Framework (CCF) [Action required]

Azure has announced that the legacy Azure Data Collection API will be deprecated on September 14, 2026. Sentinel recommends customers review existing connectors and upgrade to the latest Codeless Connector Framework (CCF) versions to ensure continued access to the newest Sentinel capabilities. CCF delivers a fully managed SaaS experience with built-in health monitoring, centralized credential management, and improved performance. This enables partners and customers to onboard new data sources faster and at scale.

Microsoft Security Store

Entra Verified ID partner integrations via Security Store [Generally available]

Security Store helps organizations secure one of the most critical steps in incident response: safe account recovery after compromise. Once a SOC team detects and contains a potential account takeover (ATO), restoring access requires high confidence that the user is legitimate. Through partner integrations with IDEMIA, AU10TIX, CLEAR, 1Kosmos, and WhoAmI, customers can extend Entra Verified ID with high-assurance identity verification (such as document and biometric checks) to validate users during recovery, onboarding, or helpdesk workflows. This helps replace weaker fallback methods that attackers often exploit, enabling SOC and IT teams to safely restore access while reducing risk of re-compromise. Learn more.

Purview Data Security Triage Agent in Defender [Public preview]

Security Store powers how customers discover and activate data security agents across Defender and Microsoft Purview, starting with the Data Security Triage Agent. This capability delivers AI-generated summaries and prioritization of Data Loss Prevention (DLP) alerts directly into Defender XDR, helping security teams reduce noise and focus on the incidents that matter most. By unifying discovery and activation through Security Store, customers can deploy data security agents in fewer steps and enable more integrated workflows across threat and data protection surfaces. Learn more.

Additional resources

Blogs and documentation:

From idea to production: Building Security Store Advisor with an agentic SDLC

Upcoming webinars:

June 4: End-to-End Security in the Age of Agentic AI
June 10: Deploy, optimize, and implement threat protection with Sentinel
June 10: Security Foundations for AI Adoption
June 24: Modern Security Made Simple: Stay Ahead of Threats with Sentinel

Upcoming events:

June 2–3: Microsoft Build, San Francisco (and free online)
- CEO Satya Nadella Day 1 keynote
- 90+ sessions, Microsoft Security experts onsite
- Register: build.microsoft.com

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!

Agent 365 connector: Monitor, hunt, and investigate AI agent activity in Microsoft Sentinel

RGupta — Mon, 18 May 2026 16:05:15 GMT

As enterprises scale the use of AI agents, SOC teams need visibility into AI agent behavior. The Agent 365 connector, now in public preview, streams rich agent telemetry from Agent 365 into Microsoft Sentinel data lake. Agent activity, such as agent data exposure or access drift, is surfaced alongside other security data, giving SOC teams a unified view across digital environments. AI Agent actions are correlated with agent identity, endpoint, and cloud signals, enabling analysts to run end‑to‑end investigations using KQL, graph, and MCP-powered workflows.

Why this matters for organizations

By centralizing security and AI agent telemetry in Sentinel data lake, organizations establish a unified control plane for securing AI agents. This enables security teams to analyze agent activity in context with broader signals and investigate using familiar Sentinel tools. This unlocks the ability for SOCs to detect risky or anomalous agent behavior early, understand impact quickly, and respond with speed and confidence. As AI agents take on real operational responsibility, this level of visibility is critical to prevent blind spots, reduce risk, and ensure agents operate safely at enterprise scale.

End‑to‑end visibility into AI agent behavior: A centralized view of AI agent behavior allows AI agents to be treated as first-class entities alongside users, identities, endpoints, and workloads.
Advanced hunting with KQL: Hunt using KQL to proactively uncover unusual AI agent execution patterns, sensitive actions, or activity without clear human context. These hunts help surface potential risk early using the same workflows already used for other security data.
Analyzing blast radius and impact with Sentinel graph: Security teams can correlate AI agent activity with identities, endpoints, and cloud resources to understand blast radius and potential impact during an investigation. By pivoting across related entities in Sentinel, analysts can assess how agent actions connect to the broader environment and support deeper, end‑to‑end investigations.
Querying agent data through MCP: Use MCP to surface agent observability data through AI assistants, letting analysts pull agent telemetry into investigation workflows alongside other Sentinel data.

Agent 365 connector key capabilities

Install the Agent 365 connector with a single click using Sentinel Content Hub in the Defender portal. Once enabled, two capabilities come online automatically:

Unified agent telemetry across Agent 365 agent experiences: Rich Agent 365 agent telemetry streams into Sentinel data lake, ready to analyze alongside identity, endpoint, and cloud signals using familiar SOC workflows.
ASIM unified schema for AI agent observability: Agent 365 agent observability data is normalized into an ASIM-aligned schema so it is consistent, queryable, and ready for analytics and detections.

With the connector in place, Sentinel data lake becomes the system of record and the control plane for Agent 365 agent security—turning agent behavior into first-class security signals across SecOps workflows like hunting, investigation, detection engineering, and response.

Use cases

Prevent sensitive data exposure from misconfigured agents
When an AI agent is granted broader access than intended, a crafted prompt could override safeguards and expose confidential data. With agent telemetry, security teams can trace the full execution path—from prompt to tools to data access—to quickly identify the root cause and contain the exposure.

Detect and control agent access drift over time
As agents take on new tasks, their permissions can expand beyond the original scope, often without clear visibility. Agent telemetry enables continuous behavioral baselining, making it easier to spot abnormal access patterns early and prevent privilege misuse before it escalates.

Uncover hidden lateral movement across agent workflows
Agents often collaborate and delegate tasks across systems, creating complex chains of execution that are difficult to track. Agent telemetry provides visibility into these interactions, mapping delegation paths and helping teams understand and limit the potential blast radius.

Defend against prompt injection and manipulation attacks
Attackers can craft prompts to override agent instructions and manipulate behavior. By capturing prompts and reasoning flows, agent telemetry enables detection of these attacks and provides the context needed to investigate and remediate quickly.

Accelerate SOC investigations with end-to-end visibility
When an agent is involved in a security alert, understanding its actions can be challenging. Agent telemetry correlates prompts, identities, tools, and data access into a unified timeline, giving SOC teams the clarity needed to investigate faster and respond with confidence.

Strengthen governance and compliance for AI agents
Organizations need visibility into what agents exist and what data they can access. Agent telemetry provides a comprehensive audit trail of agent activity and access patterns, supporting compliance reporting and policy enforcement.

Enable proactive threat hunting on agent behavior
Security teams need to stay ahead of emerging risks as agent usage grows. Agent telemetry enables advanced hunting across agent activity, helping detect anomalies, uncover patterns, and identify threats before they impact the organization.

Get started with Agent 365 connector

Getting started is straightforward.

In the Microsoft Defender portal, navigate to Microsoft Sentinel
Open Content hub and search for Agent 365
Install the Agent 365 Connector (if not already installed)
Open the connector page and select Connect to begin ingestion

Once connected, AI agent telemetry starts flowing into Sentinel, ready for hunting, investigation, and response. Data ingestion and analytics are billed using existing Sentinel meters.

Learn more

Sentinel SOAR migration to Unified portal: what broke? anyone evaluated the AI playbook generator?

AnthonyPorter — Thu, 14 May 2026 23:42:29 GMT

I want to open a conversation specifically focused on the automation and SOAR side of the migration, because this is the area where problems most commonly surface after onboarding rather than during it.

A quick orientation: the Unified portal introduces a specific constraint that catches teams by surprise. Alert-triggered automation for alerts created by Microsoft Defender XDR is not available in the Defender portal. The main use case for alert-triggered automation in this context is responding to alerts from analytics rules where incident creation is disabled. If you had alert-triggered playbooks firing on Defender XDR signals, those need to be re-evaluated against the incident trigger model. This is documented by Microsoft, but it is easy to miss in the volume of migration guidance.

The automation failure mode I have seen most consistently: automation rules built around incident title conditions. The Defender XDR correlation engine assigns its own incident names, so any condition keyed to "if incident title contains X" stops matching without throwing an error. The rule is still active, the automation is still enabled, and everything looks fine until someone notices a class of enrichment or response has gone quiet. Microsoft's recommendation is to use Analytic rule name as the condition instead.

There is also a firm near-term deadline separate from the March 2027 portal retirement: queries and automation need to be updated by July 1, 2026 for standardised account entity naming. The Name field will consistently hold only the UPN prefix from that date. Any automation comparing AccountName against a full UPN will break.

A few specific questions for practitioners:

When you onboarded or reviewed your automation post-onboarding, what broke silently versus what produced a visible error? Silent failures are the dangerous ones and sharing specific patterns would be genuinely useful for the community.
Has anyone evaluated the new AI playbook generator in the Defender portal? It requires Security Copilot with SCUs available and generates Python-based automation coauthored with Cline in an embedded VS Code environment. Interested in real-world comparisons against existing Logic Apps workflows for the same use case.
For those who have migrated alert-triggered playbooks to automation rule invocation: did you find edge cases in the migration, particularly around playbooks used by multiple analytics rules simultaneously?

Writing this up as Part 4 of the migration series. Sharing the article link once it is live for anyone who wants the full detail.