Microsoft Sentinel Blog articles

Introducing the Microsoft Sentinel Training Lab. Hands-On Security Operations in Minutes

AndreasKapetaniou — Thu, 23 Apr 2026 08:50:24 GMT

A huge thanks to Paul Kew - this lab wouldn't have been possible without his contributions.

Security operations is one of those things that’s hard to learn from slides alone. You need to feel what it’s like to triage a multi-stage incident, tune a noisy detection rule, or trace an attacker pivoting from an endpoint to the cloud. That’s exactly why we built the Microsoft Sentinel Training Lab.

What Is It?

The Sentinel Training Lab is an open-source, deploy-in-minutes training environment that gives you a fully functional Microsoft Sentinel workspace loaded with realistic attack telemetry. One click deploys everything - pre-recorded data from six different security products, custom detection rules that fire real incidents, workbooks, watchlists, and playbooks.

No need to set up agents, configure connectors, or simulate attacks yourself. The lab does all of that for you so you can focus on what matters: learning how to detect, investigate, and respond.

What’s Inside?

The lab simulates a multi-stage attack that spans six data sources — just like what a real SOC analyst would encounter:

CrowdStrike — endpoint detections (malware execution, credential dumping)
Palo Alto Networks — firewall logs (port scans, data exfiltration, C2 traffic)
Okta — identity events (account takeover, MFA manipulation)
AWS CloudTrail — cloud activity (IAM escalation, backdoor accounts)
GCP Audit Logs — cloud infrastructure abuse (service account creation, firewall changes)
MailGuard365 — email security (phishing campaigns bypassing filters)

All of this data feeds into 22 custom detection rules that automatically generate a unified, multi-stage incident in Microsoft Defender XDR - with correlated alerts, entity graphs, and a full kill chain mapped to MITRE ATT&CK.

The Exercises

The lab comes with 16 guided exercises covering the full spectrum of security operations:

Getting Started

Onboarding — Set up your workspace and deploy the lab in under 30 minutes
Exercise 1 — Explore your data with Advanced Hunting and create your first detection rule
Exercise 2 — Enable Microsoft Defender Threat Intelligence and query IOCs
Exercise 3 — Visualise your detection coverage on the MITRE ATT&CK matrix
Exercise 4 — Automate incident enrichment with automation rules

Detection Engineering

Exercise 5 — Cross-platform device isolation (CrowdStrike alert → MDE response)
Exercise 6 — Tune port scan detection thresholds
Exercise 7 — Detect Okta MFA factor manipulation
Exercise 8 — Enrich detections with watchlists

Operations & Cost Management

Exercise 9 — Monitor ingestion costs and configure threshold policies
Exercise 10 — Manage table tiers and retention settings

Data Lake

Exercise 11 — Create KQL jobs to aggregate data lake telemetry
Exercise 12 — Compare real-time vs data lake detection approaches
Exercise 13 — Interactive Jupyter notebook investigations

Advanced

Exercise 14 — 10 AI-powered prompts demonstrating the Sentinel MCP Server
Exercise 15 — Federate external data from ADLS Gen2
Exercise 16 — Split transformation to route data between Analytics and data Lake tiers

What Makes This Different?

Feature	What it means for you
One-click deployment	Deploy to Azure button — no manual configuration
Realistic multi-source data	Six security products generating correlated incidents
22 detection rules	Pre-built rules that fire real XDR incidents with entity mapping
MITRE ATT&CK coverage	10 tactics covered across the attack chain
Data lake exercises	KQL jobs, notebooks, federation, and split transformations
MCP Server prompts	AI-powered investigation with GitHub Copilot
Cost management	Threshold policies and tier optimisation guidance

Getting Started

Ready to try it? Here’s all you need:

An Azure subscription (free trial works)
Owner or Contributor role on the subscription
A Microsoft Sentinel workspace onboarded to Defender XDR

Then head to the repo, follow the Onboarding guide and click Deploy to Azure:

The deployment takes about 30 minutes. After that, your workspace will have ingested data, detection rules firing incidents, and all 16 exercises ready to go.

Open Source & Community

The entire lab is open source under the Azure/Azure-Sentinel repository. Contributions, feedback, and ideas are welcome. If you find something that could be better, open an issue or submit a PR.

We built this lab because we believe the best way to learn security operations is by doing. We hope it helps you — whether you’re defending your first tenant or your hundredth.

Get started now - Azure-Sentinel/Tools/Microsoft-Sentinel-Training-Lab/README.md at master · Azure/Azure-Sentinel

Enforce Cost Limits on KQL Queries and Notebooks in the Microsoft Sentinel Data Lake

shubh_khandhadia — Wed, 15 Apr 2026 20:26:56 GMT

Security teams face a constant tension: run the advanced analytics you need to stay ahead of threats, or hold back to keep costs predictable. Until now, Microsoft Sentinel let you set alerts to get notified when data lake usage approached a threshold — useful for awareness, but not enough to prevent budget overruns.

Today, we're excited to announce threshold enforcement for KQL queries and notebooks in the Microsoft Sentinel data lake. With this release, you can go beyond notifications and automatically block new queries and jobs when your configured usage limits are exceeded. Your analysts keep working confidently, and your budgets stay protected.

What's new

Previously, the Configure Policies experience in Microsoft Sentinel let you set threshold-based alerts for data lake usage. You'd receive an email notification when consumption approached a limit — but nothing stopped usage from continuing past that point.

Now, you can enable enforcement on those same policies. When enforcement is turned on and a threshold is exceeded, Microsoft Sentinel blocks new queries, jobs, and notebook sessions with a clear "Limit exceeded" error. No more surprise cost spikes from runaway queries or analysts who mistakenly run heavy workloads against data lake data.

Enforcement is supported for two data lake capability categories:

Data Lake Query — interactive KQL queries and KQL jobs (scheduled and ad hoc)
Advanced Data Insights — notebook runs and notebook jobs

How it works

Consistent controls across KQL queries and notebooks

Cost controls are enforced consistently across Sentinel data lake workloads, regardless of how analysts access the data. The same policy applies whether someone is running a quick investigation or executing a long-running job.

Controls apply to:

Interactive KQL queries in the data lake explorer in the Defender portal
KQL jobs, including scheduled and ad-hoc jobs
Notebook queries run through the Microsoft Sentinel VS Code extension
Notebook jobs running as background or scheduled workloads

This ensures advanced analytics remain powerful — but predictable and governed.

Clear enforcement without disruption

Enforcement is applied at execution and validation boundaries — not retroactively. This means:

Queries or jobs already running are not interrupted. In-flight work completes normally.
New queries, jobs, or notebook sessions are blocked once limits are exceeded.
Failures occur early (for example, during validation), avoiding wasted compute.

From an analyst's perspective, enforcement is explicit and consistent. Clear messaging appears in query editors, job validation responses, and notebooks when limits are reached — so your team always understands what happened and what to do next.

How to set it up

Prerequisites

To configure enforcement policies, ensure you have the necessary permissions that are outlined here: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn.

Where to access

Navigate to Microsoft Sentinel > Cost management > Configure Policies in the Microsoft Defender portal (https://security.microsoft.com).

Step-by-step configuration

In Microsoft Sentinel > Cost management, select Configure Policies.
Select the policy you want to edit (Data Lake Query or Advanced Data Insights).
Enter the total threshold value for the policy.
Enter an alert percentage to receive email notifications before the threshold is reached.
Enable the Enforcement toggle to block usage after the threshold is exceeded.
Review your settings and select Submit.

Once enforcement is active, administrators receive advance notifications as usage approaches the threshold. If circumstances change — for example, during an active breach — you can adjust the threshold, disable enforcement temporarily, or modify the policy to give your SOC the room it needs to respond without being blocked.

Real-world scenario: Preventing unexpected cost spikes

Consider a large SOC that ingests roughly 6 TB of data per day, with 1 TB going to the Sentinel Analytics tier and the remaining 5 TB going to the Sentinel data lake. Analysts are proactively hunting for threats, performing investigations, and running automation. Tier 3 analysts are also running Jupyter Notebooks against the Sentinel data lake to build graphs, execute queries, and automate incident investigation and remediation with code.

Last month, the SOC experienced a cost spike after a newly hired analyst ran large, frequent queries against data lake data — mistakenly thinking it was Analytics tier. The SOC manager needs to prevent this from happening again.

With enforcement now available, the SOC manager can navigate to Microsoft Sentinel > Cost management > Configure Policies in the Defender portal and set up two policies:

A Data Lake Query policy to cap data processing for KQL queries

An Advanced Data Insights policy to cap notebook compute consumption

With these policies in place, the SOC manager gets notified in advance when consumption approaches the threshold while having confidence that the thresholds set will be enforced to prevent unexpected consumption and cost. Analysts can continue their day-to-day work without worrying about accidental overages. Should a breach scenario demand more capacity, the SOC manager can quickly adjust or temporarily disable the policies — keeping the team unblocked while maintaining overall budget governance. Outside of a breach scenario, should the same SOC analyst generate large amounts of data scanned, the threshold will take action and prevent queries from being performed.

Learn more

With enforceable KQL and notebook guardrails, Microsoft Sentinel data lake helps security teams scale advanced analytics with confidence. You can control usage in production and keep investigations moving — without tradeoffs between visibility, analytics, and budget.

To get started, visit the documentation: Manage and monitor costs for Microsoft Sentinel | Microsoft Learn

We'd love to hear your feedback. Share your thoughts in the comments below or reach out through your usual Microsoft support channels.

Running KQL queries on Microsoft Sentinel data lake using API

Zeinab Mokhtarian Koorabbasloo — Tue, 14 Apr 2026 17:15:33 GMT

Co-Authors: Zeinab Mokhtarian Koorabbasloo and Matthew Lowe

As security data lakes become the backbone of modern analytics platforms, organizations need new ways to operationalize their data. While interactive tools and portals support data exploration, many real-world workflows increasingly require flexible programmatic access that enables automation, scale, and seamless integration.

By running KQL (Kusto Query Language) queries on Microsoft Sentinel data lake through APIs, you can embed analytics directly into automation workflows, background services, and intelligent agents, without relying on manual query execution.

In this post, we explore API based KQL query execution, review some of the scenarios where it delivers the most value, and what you need to get started.

Why run KQL queries on Sentinel data lake via API?

Traditional query experiences, such as dashboards and query editors, are optimized for human interaction. APIs, on the other hand, are optimized for systems.

Running KQL through an API enables:

Automation-first analytics
Repeatable and scheduled insights
Integration with external systems and agents
Consistent query execution at scale

Instead of asking “How do I run this query?”, our customers are asking “How do I embed analytics into my workflow?”

Scenarios where API-based KQL queries add value

Automated monitoring and alerting

SOC teams often want to continuously analyze data in their lake to detect anomalies, trends, or policy violations.

With API-based KQL execution, they can:

Run queries as part of automated workflows and playbooks
Evaluate query results programmatically
Trigger downstream actions such as alerts, tickets, or notifications

This turns KQL into a signal engine, not just an exploration tool.

Powering intelligent agents

AI agents require programmatic access to data lakes to retrieve timely, relevant context for decision making. Using KQL over an API allows agents to:

Dynamically query data lake based on user intent or system context
Retrieve aggregated or filtered results on demand
Combine analytical results with reasoning and decision logic

In this model, KQL acts as the analytical retrieval layer, while the agent focuses on orchestration, reasoning, and action.

Embedding analytics into business workflows

Many organizations want analytics embedded directly into CI/CD and operational pipelines. Instead of exporting data or duplicating logic, they can:

Run KQL queries inline via API
Use results as inputs to other systems
Keep analytics logic centralized and consistent

This reduces drift between “analytics code” and “application code.”

High-level flow: What happens when you run KQL via API

At a conceptual level, the flow looks like this:

A client authenticates to Microsoft Sentinel data lake platform.
The client submits a KQL query via an API.
The query executes against data stored in the data lake.
Results are returned in a structured, machine-readable format.
The client processes or acts on the results.

Prerequisites

To run KQL queries against the Sentinel data lake using APIs, you will need:

A user token or a service principal
Appropriate permissions to execute queries on the Sentinel data lake. Azure RBAC roles such as Log Analytics reader or Log Analytics contributor on the workspace are needed.
Familiarity with KQL and API based query execution patterns

Scenario 1: Execute a KQL query via API within a Playbook

The following Sentinel SOAR playbook example demonstrates how data within Sentinel data lake can be used within automation. This example leverages a service principal that will be used to query the DeviceNetworkEvent logs that are within Sentinel data lake to enrich an incident involving a device before taking action on it.

Within this playbook, the entities involved within the incident are retrieved, then queries are executed against the Sentinel data lake to gain insights on each host involved. For this example, the API call to the Sentinel data lake to retrieve events from the DeviceNetworkEvents table to find relevant information that shows network connections with the host where the IP originated from outside of the United States.

As this action does not have a gallery artifacts within Azure Logic Apps, the action must be built out by using the HTTP action that is offered within Logic Apps. This action requires the API details for the API call as well as the authentication details that will be used to run the API. The step that executes the query leverages the Sentinel data lake API by performing the following call: POST https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query. The service principal being used has read permissions on the Sentinel data lake that contains the relevant details and is authenticating to Entra ID OAuth when running the API call.

NOTE: When using API calls to query Sentinel data lake, use 4500ebfb-89b6-4b14-a480-7f749797bfcd/.default as the scope/audience when retrieving a token for the service principal. This GUID is associated with the query service for Sentinel data lake.

The body of the query is the following:

{ "csl": "DeviceNetworkEvents | where TimeGenerated >= ago(30d) | where DeviceName has '' | where ActionType in (\"ConnectionSuccess\", \"ConnectionAttempted\", \"InboundConnectionAccepted\") | extend GeoInfo = geo_info_from_ip_address(RemoteIP) | extend Country = tostring(GeoInfo.country), State = tostring(GeoInfo.state), City = tostring(GeoInfo.city) | where Country != 'United States' and RemoteIP !has '127.0.0.1' | project TimeGenerated, DeviceName, ActionType, RemoteIP, RemotePort, RemoteUrl, City, State, Country, InitiatingProcessFileName | order by TimeGenerated desc | top 2 by DeviceName", “db”: “WORKSPACENAMEHERE – WORKSPACEIDHERE” }

Within this body, the query and workspace are defined. “csl” represents the query to run against the Sentinel data lake and “db” represents the Sentinel workspace/lake. This value is a combination of the workspace name – workspace ID. Both of these values can be found on the workspace overview blade within Azure.

NOTE: The query must be one line in the JSON. Multi-line items will not be seen as valid JSON.

With this, initial investigative querying via Sentinel data lake has been done the moment that the incident is triggered, allowing the SOC analyst responding to expediate their investigation and validating that the automated action of disabling the account was justified. For this Playbook, the results gathered from Sentinel data lake were placed into a comment and added to the incident within Defender, allowing SOC analysts to quickly review relevant details when beginning their work:

Scenario 2: Execute a KQL query via API in code

The following Python example demonstrates how to use a service principal to execute a KQL query on the Sentinel data lake via API. This example is provided for illustration purposes, but you can also call the API directly via common API tools. Within the code, the query and workspace are defined. “csl” represents the query to run against the Sentinel data lake and “db” represents the Sentinel workspace/lake. This value is a combination of the workspace name – workspace ID. Both of these values can be found on the workspace overview blade within Azure.

You also need to use a token or a service principal.

import requests import msal # ====== SPN / Entra app settings ====== TENANT_ID = "" CLIENT_ID = "" CLIENT_SECRET = "" # Token authority AUTHORITY = f"https://login.microsoftonline.com/{TENANT_ID}" # ---- IMPORTANT ---- # Most APIs use the resource + "/.default" pattern for client-credentials. # Try this first: SCOPE = ["4500ebfb-89b6-4b14-a480-7f749797bfcd/.default"] # ====== KQL query payload ====== KQL_QUERY = { "csl": "SigninLogs| take 10", "db": " workspace1-12345678-abcd-abcd-1234-1234567890ab ", "properties": { "Options": { "servertimeout": "00:04:00", "queryconsistency": "strongconsistency", "query_language": "kql", "request_readonly": False, "request_readonly_hardline": False } } } # ====== Acquire token using client credentials ====== app = msal.ConfidentialClientApplication( client_id=CLIENT_ID, authority=AUTHORITY, client_credential=CLIENT_SECRET ) result = app.acquire_token_for_client(scopes=SCOPE) if "access_token" not in result: raise RuntimeError( f"Token acquisition failed: {result.get('error')} - {result.get('error_description')}" ) access_token = result["access_token"] # ====== Call the KQL API ====== headers = { "Authorization": f"Bearer {access_token}", "Content-Type": "application/json" } url = "https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query" # same endpoint response = requests.post(url, headers=headers, json=KQL_QUERY) if response.status_code == 200: print("Query Results:") print(response.json()) else: print(f"Error {response.status_code}: {response.text}")

In summary, you need the following parameters in your API call:

Request URI: https://api.securityplatform.microsoft.com/lake/kql/v2/rest/query

Method: POST

Sample payload:

{ "csl": " SigninLogs | take 10", "db": "workspace1-12345678-abcd-abcd-1234-1234567890ab", }

Limitations and considerations

The following considerations should be considered when planning to execute KQL queries on a data lake:

Service principal permissions

When using a service principal, Azure RBAC roles can be assigned at the Sentinel workspace level. Entra ID roles or XDR unified RBAC role are not supported for this scenario. Alternatively, user tokens with Entra ID roles can be used.

Result size limits
Queries are subject to limits on execution time and response size. Review Microsoft Sentinel data lake query service limits when designing your workflows.

Summary

Running KQL queries on Sentinel data lake via APIs unlocks a new class of scenarios, from intelligent agents to fully automated analytics pipelines. By decoupling query execution from user interfaces, customers gain flexibility, scalability, and control over how insights are generated and consumed.

If you’re already using KQL for interactive analysis, API access is the natural next step toward production grade analytics.

Happy hunting!

Resources

Run KQL queries on Sentinel data lake: Run KQL queries against the Microsoft Sentinel data lake - Microsoft Security | Microsoft Learn
Service parameters and limits: Microsoft Sentinel data lake service limits - Microsoft Security | Microsoft Learn

Microsoft Sentinel data federation: Expand visibility while preserving governance

chaitra_satish — Tue, 14 Apr 2026 16:11:29 GMT

Security data volumes are growing faster than ever, but visibility across the entire digital estate hasn’t kept pace. As organizations expand across cloud, hybrid, and SaaS environments, critical security-relevant data is increasingly stored across multiple data stores due to governance and compliance requirements.

Microsoft understands this reality. Microsoft Sentinel data federation now in public preview, is designed to meet customers where their data already lives, while preserving governance. Powered by Microsoft Fabric, customers can federate data from Microsoft Fabric, Azure Data Lake Storage (ADLS) Gen 2, and Azure Databricks into Sentinel data lake—without copying or duplicating the data. Security teams can analyze data in place, unifying detections, investigations, and hunting across a broader digital estate, while data owners retain full ownership and policies remain intact.

Sentinel data federation benefit

Data federation ensures security data remains at its source while appearing seamlessly alongside native Sentinel data in the Sentinel data lake.

This allows security teams to work with governed data confidently—without duplicating data or disrupting existing data ownership and compliance models.
Using familiar Sentinel tools such as KQL hunting, notebooks, and custom graphs, teams can correlate signals, investigate incidents, and hunt across federated and ingested data in a unified experience. Analysts can seamlessly connect signals across domains and accelerate investigations.
By running analytics on federated data first, customers can evaluate which datasets consistently deliver security value. Over time, high‑value data can be ingested into Sentinel data lake to unlock deeper detections, automation, and AI‑driven insights.

Sentinel data federation allows security teams to start broad, stay governed, and scale security analytics with clarity.

Customer use cases enabled by Sentinel data federation

Cross-domain threat hunting across the enterprise

With Sentinel data federation, Sentinel becomes the orchestration layer for advanced security analytics, not just a repository for ingested data.

By querying external data sources in place, security teams can:

Run single KQL threat hunts that span Sentinel-native tables and federated data sources.
Correlate security signals with business, identity, fraud, and application telemetry that may never be ingested into Sentinel.
Perform investigations across years of historical data without migrating or reshaping it.

This enables SOC teams to move beyond siloed investigations and uncover patterns that only emerge when data is analyzed across the full digital estate.

“Microsoft leads the market in cloud‑native SIEM. Now with support for data federation, Sentinel is enabling security teams to analyze security data wherever it lives, preserving governance. For customers and managed security providers alike, this marks a pivotal shift in what a modern cloud SIEM can enable."

— Micah Heaton | Strategy Leader at BlueVoyant

AI-ready tooling for advanced security analytics

By extending Sentinel’s security knowledge layer across federated data, customers can:

Leverage Sentinel custom graphs and AI/MCP tools to run analytics across federated and ingested data together.
Deliver immediate investigative value to SOC teams by enriching incidents with broader context.
Enable data scientists and advanced analysts to perform iterative threat discovery without copying or staging massive datasets into the Sentinel data lake.

This approach allows customers to apply advanced analytics and AI techniques to security problems at scale, while preserving governance and avoiding unnecessary data movement.

Data federation as a path to deeper Sentinel value

Data federation is not a replacement for ingestion, it’s a governance-first approach.

Many customers follow a natural progression:

Federate data to explore and investigate
Identify high-value signals through real investigations
Ingest valuable security data into Sentinel data lake overtime
Unlock detections, automation, and AI-powered insights at scale

This approach helps customers realize Sentinel value earlier while setting them up for long-term success.

Learn more

How to Ingest Microsoft Intune Logs into Microsoft Sentinel

PaulineMbabu — Fri, 10 Apr 2026 16:00:00 GMT

For many organizations using Microsoft Intune to manage devices, integrating Intune logs into Microsoft Sentinel is an essential for security operations (Incorporate the device into the SEIM). By routing Intune’s device management and compliance data into your central SIEM, you gain a unified view of endpoint events and can set up alerts on critical Intune activities e.g. devices falling out of compliance or policy changes. This unified monitoring helps security and IT teams detect issues faster, correlate Intune events with other security logs for threat hunting and improve compliance reporting. We’re publishing these best practices to help unblock common customer challenges in configuring Intune log ingestion. In this step-by-step guide, you’ll learn how to successfully send Intune logs to Microsoft Sentinel, so you can fully leverage Intune data for enhanced security and compliance visibility.

Prerequisites and Overview

Before configuring log ingestion, ensure the following prerequisites are in place:

Microsoft Sentinel Enabled Workspace: A Log Analytics Workspace with Microsoft Sentinel enabled; For information regarding setting up a workspace and onboarding Microsoft Sentinel, see: Onboard Microsoft Sentinel - Log Analytics workspace overview. Microsoft Sentinel is now available in the Defender Portal, connect your Microsoft Sentinel Workspace to the Defender Portal: Connect Microsoft Sentinel to the Microsoft Defender portal - Unified security operations.
Intune Administrator permissions: You need appropriate rights to configure Intune Diagnostic Settings. For information, see: Microsoft Entra built-in roles - Intune Administrator.
Log Analytics Contributor role: The account configuring diagnostics should have permission to write to the Log Analytics workspace. For more information on the different roles, and what they can do, go to Manage access to log data and workspaces in Azure Monitor.

Intune diagnostic logging enabled: Ensure that Intune diagnostic settings are configured to send logs to Azure Monitor / Log Analytics, and that devices and users are enrolled in Intune so that relevant management and compliance events are generated. For more information, see: Send Intune log data to Azure Storage, Event Hubs, or Log Analytics.

Configure Intune to Send Logs to Microsoft Sentinel

Sign in to the Microsoft Intune admin center.
Select Reports > Diagnostics settings. If it’s the first time here, you may be prompted to “Turn on” diagnostic settings for Intune; enable it if so. Then click “+ Add diagnostic setting” to create a new setting:
Microsoft Intune Diagnostics settings page – Add diagnostic settings.
- Select Intune Log Categories. In the “Diagnostic setting” configuration page, give the setting a name (e.g. “Microsoft Sentinel Intune Logs Demo”). Under Logs to send, you’ll see checkboxes for each Intune log category. Select the categories you want to forward. For comprehensive monitoring, check AuditLogs, OperationalLogs, DeviceComplianceOrg, and Devices. The selected log categories will be sent to a table in the Microsoft Sentinel Workspace.
  Microsoft Intune Diagnostics settings page – Log categories.
Configure Destination Details – Microsoft Sentinel Workspace. Under Destination details on the same page, select your Azure Subscription then select the Microsoft Sentinel workspace.

Microsoft Intune Diagnostics settings page - Destination details.
Save the Diagnostic Setting. After you click save, the Microsoft Intune Logs will will be streamed to 4 tables which are in the Analytics Tier. For pricing on the analytic tier check here: Plan costs and understand pricing and billing.

Microsoft Intune Diagnostics settings page – Saved Diagnostic settings.

Verify Data in Microsoft Sentinel.

After configuring Intune to send diagnostic data to a Microsoft Sentinel Workspace, it’s crucial to verify that the Intune logs are successfully flowing into Microsoft Sentinel. You can do this by checking specific Intune log tables both in the Microsoft 365 Defender portal and in the Azure Portal. The key tables to verify are:

IntuneAuditLogs
IntuneOperationalLogs
IntuneDeviceComplianceOrg
IntuneDevices

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

1. Open Advanced Hunting: Sign in to the https://security.microsoft.com (the unified portal). Navigate to Advanced Hunting.
– This opens the unified query editor where you can search across Microsoft Defender data and any connected Sentinel data.

2. Find Intune Tables: In the Advanced hunting Schema pane (on the left side of the query editor), scroll down past the Microsoft Sentinel Tables. Under the LogManagement Section Look for IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices in the list.

Microsoft Sentinel in Defender Portal – Tables

1. Navigate to Logs: Sign in to the https://portal.azure.com and open Microsoft Sentinel. Select your Sentinel workspace, then click Logs (under General).

2. Find Intune Tables: In the Logs query editor that opens, you’ll see a Schema or tables list on the left. If it’s collapsed, click >> to expand it. Scroll down to find LogManagement and expand it; look for these Intune-related tables: IntuneAuditLogs, IntuneOperationalLogs, IntuneDeviceComplianceOrg, and IntuneDevices

Microsoft Sentinel in Azure Portal – Tables

Querying Intune Log Tables in Sentinel – Once the tables are present, use Kusto Query Language (KQL) in either portal to view and analyze Intune data:

Microsoft 365 Defender Portal (Unified)

Azure Portal (Microsoft Sentinel)

In the Advanced Hunting page, ensure the query editor is visible (select New query if needed). Run a simple KQL query such as:

IntuneDevice | take 5

Click Run query to display sample Intune device records. If results are returned, it confirms that Intune data is being ingested successfully. Note that querying across Microsoft Sentinel data in the unified Advanced Hunting view requires at least the Microsoft Sentinel Reader role.

Microsoft Sentinel in the Microsoft Defender Portal - Advanced hunting query.

In the Azure Logs blade, use the query editor to run a simple KQL query such as:

IntuneDevice | take 5

Select Run to view the results in a table showing sample Intune device data. If results appear, it confirms that your Intune logs are being collected successfully. You can select any record to view full event details and use KQL to further explore or filter the data - for example, by querying IntuneDeviceComplianceOrg to identify devices that are not compliant and adjust the query as needed.

Microsoft Sentinel in the Azure Portal - Sentinel logs query.

Once Microsoft Intune logs are flowing into Microsoft Sentinel, the real value comes from transforming that raw device and audit data into actionable security signals.
To achieve this, you should set up detection rules that continuously analyze the Intune logs and automatically flag any risky or suspicious behavior. In practice, this means creating custom detection rules in the Microsoft Defender portal (part of the unified XDR experience) see [https://learn.microsoft.com/en-us/defender-xdr/custom-detection-rules] and scheduled analytics rules in Microsoft Sentinel (in either the Azure Portal or the unified Defender portal interface) see:[Create scheduled analytics rules in Microsoft Sentinel | Microsoft Learn].

These detection rules will continuously monitor your Intune telemetry – tracking device compliance status, enrollment activity, and administrative actions – and will raise alerts whenever they detect suspicious or out-of-policy events. For example, you can be alerted if a large number of devices fall out of compliance, if an unusual spike in enrollment failures occurs, or if an Intune policy is modified by an unexpected account. Each alert generated by these rules becomes an incident in Microsoft Sentinel (and in the XDR Defender portal’s unified incident queue), enabling your security team to investigate and respond through the standard SOC workflow. In turn, this converts raw Intune log data into high-value security insights: you’ll achieve proactive detection of potential issues, faster investigation by pivoting on the enriched Intune data in each incident, and even automated response across your endpoints (for instance, by triggering playbooks or other automated remediation actions when an alert fires).

Use this Detection Logic to Create a detection Rule
IntuneDeviceComplianceOrg | where TimeGenerated > ago(24h) | where ComplianceState != "Compliant" | summarize NonCompliantCount = count() by DeviceName, TimeGenerated | where NonCompliantCount > 3

Additional Tips: After confirming data ingestion and setting up alerts, you can leverage other Microsoft Sentinel features to get more value from your Intune logs. For example:
- Workbooks for Visualization: Create custom workbooks to build dashboards for Intune data (or check if community-contributed Intune workbooks are available). This can help you monitor device compliance trends and Intune activities visually.
- Hunting and Queries: Use advanced hunting (KQL queries) to proactively search through Intune logs for suspicious activities or trends. The unified Defender portal’s Advanced Hunting page can query both Sentinel (Intune logs) and Defender data together, enabling correlation across Intune and other security data. For instance, you might join IntuneDevices data with Azure AD sign-in logs to investigate a device associated with risky sign-ins.
- Incident Management: Leverage Sentinel’s Incidents view (in Azure portal) or the unified Incidents queue in Defender to investigate alerts triggered by your new rules. Incidents in Sentinel (whether created in Azure or Defender portal) will appear in the connected portal, allowing your security operations team to manage Intune-related alerts just like any other security incident.
- Built-in Rules & Content: Remember that Microsoft Sentinel provides many built-in Analytics Rule templates and Content Hub solutions. While there isn’t a native pre-built Intune content pack as of now, you can use general Sentinel features to monitor Intune data.

Frequently Asked Questions

If you’ve set everything up but don’t see logs in Sentinel, run through these checks:
1. Check Diagnostic Settings
  1. Go to the Microsoft Intune admin center → Reports → Diagnostic settings.
  2. Make sure the setting is turned ON and sending the right log categories to the correct Microsoft Sentinel workspace.
2. Confirm the Right Workspace
  1. Double-check that the Azure subscription and Microsoft Sentinel workspace are selected.
  2. If you have multiple tenants/directories, make sure you’re in the right one.
3. Verify Permissions
4. Make Sure Logs Are Being Generated
  1. If no devices are enrolled or no actions have been taken, there may be nothing to log yet.
  2. Try enrolling a device or changing a policy to trigger logs.
5. Check Your Queries
  1. Make sure you’re querying the correct workspace and time range in Microsoft Sentinel.
  2. Try a direct query like:
    IntuneAuditLogs | take 5
6. Still Nothing?
  1. Try deleting and re-adding the diagnostic setting.
  2. Most issues come down to permissions or selecting the wrong workspace.
How long are Intune logs retained, and how can I keep them longer?
1. The analytics tier keeps data in the interactive retention state for 90 days by default, extensible for up to two years. This interactive state, while expensive, allows you to query your data in unlimited fashion, with high performance, at no charge per query: Log retention tiers in Microsoft Sentinel.

We hope this helps you to successfully connect your resources and end-to-end ingest Intune logs into Microsoft Sentinel. If you have any questions, leave a comment below or reach out to us on X @MSFTSecSuppTeam!

Estimate Microsoft Sentinel Costs with Confidence Using the New Sentinel Cost Estimator

shubh_khandhadia — Thu, 09 Apr 2026 22:26:18 GMT

One of the first questions teams ask when evaluating Microsoft Sentinel is simple: what will this actually cost? Today, many customers and partners estimate Sentinel costs using the Azure Pricing Calculator, but it doesn’t provide the Sentinel-specific usage guidance needed to understand how each Sentinel meter contributes to overall spend. As a result, it can be hard to produce accurate, trustworthy estimates, especially early on, when you may not know every input upfront. To make these conversations easier and budgets more predictable, Microsoft is introducing the new Sentinel Cost Estimator (public preview) for Microsoft customers and partners.

The Sentinel Cost Estimator gives organizations better visibility into spend and more confidence in budgeting as they operate at scale.

You can access the Microsoft Sentinel Cost Estimator here: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator

What the Sentinel Cost Estimator does

The new Sentinel Cost Estimator makes pricing transparent and predictable for Microsoft customers and partners. The Sentinel Cost Estimator helps you understand what drives costs at a meter level and ensures your estimates are accurate with step-by-step guidance.

You can model multi-year estimates with built-in projections for up to three years, making it easy to anticipate data growth, plan for future spend, and avoid budget surprises as your security operations mature. Estimates can be easily shared with finance and security teams to support better budgeting and planning.

When to Use the Sentinel Cost Estimator

Use the Sentinel Cost Estimator to:

Model ingestion growth over time as new data sources are onboarded
Explore tradeoffs between Analytics and Data Lake storage tiers
Understand the impact of retention requirements on total spend
Estimate compute usage for notebooks and advanced queries
Project costs across a multi‑year deployment timeline

For broader Azure infrastructure cost planning, the Azure Pricing Calculator can still be used alongside the Sentinel Cost Estimator.

Cost Estimator Example

Let’s walk through a practical example using the Cost Estimator. A medium-sized company that is new to Microsoft Sentinel wants a high-level estimate of expected costs. In their previous SIEM, they performed proactive threat hunting across identity, endpoint, and network logs; ran detections on high-security-value data sources from multiple vendors; built a small set of dashboards; and required three years of retention for compliance and audit purposes. Based on their prior SIEM, they estimate they currently ingest about 2 TB per day.

In the Cost Estimator, they select their region and enter their daily ingestion volume. As they are not currently using Sentinel data lake, they can explore different ways of splitting ingestion between tiers to understand the potential cost benefit of using the data lake.

Their retention requirement is three years. If they choose to use Sentinel data lake, they can plan to retain 90 days in the Analytics tier (included with Microsoft Sentinel) and keep the remaining data in Sentinel data lake for the full three years.

As notebooks are new to them, they plan to evaluate notebooks for SOC workflows and graph building. They expect to start in the light usage tier and may move to medium as they mature. Since they occasionally query data older than 90 days to build trends—and anticipate using the Sentinel MCP server for SOC workflows on Sentinel lake data—they expect to start in the medium query volume tier.

Note: These tiers are for estimation purposes only; they do not lock in pricing when using the Microsoft Sentinel platform.

Because this customer is upgrading from Microsoft 365 E3 to E5, they may be eligible for free ingestion based on their user count. Combined with their eligible server data from Defender for Servers, this can reduce their billable ingestion.

In the review step, the Cost Estimator projects costs across a three-year window and breaks down drivers such as data tiers, commitment tiers, and comparisons with alternative storage options. From there, the customer can go back to earlier steps to adjust inputs and explore different scenarios. Once done, the estimate report can be exported for reference with Microsoft representatives and internal leadership when discussing the deployment of Microsoft Sentinel and Sentinel Platform.

Finalize Your Estimate with Microsoft

The Microsoft Sentinel Cost Estimator is designed to provide directional guidance and help organizations understand how architectural decisions may influence cost. Final pricing may vary based on factors such as deployment architecture, commitment tiers, and applicable discounts. We recommend working with your Microsoft account team or a Security sales specialist to develop a formal proposal tailored to your organization’s requirements.

Try the Microsoft Sentinel Cost Estimator

Start building your Microsoft Sentinel cost estimate today: https://microsoft.com/en-us/security/pricing/microsoft-sentinel/cost-estimator.

Introducing the New Microsoft Sentinel Logstash Output Plugin (Public Preview!)

JamesAde — Mon, 06 Apr 2026 22:28:06 GMT

Many organizations rely on Logstash as a flexible, trusted data pipeline for collecting, transforming, and forwarding logs from on-premises and hybrid environments. Microsoft Sentinel has long supported a Logstash output plugin, enabling customers to send data directly into Sentinel as part of their existing pipelines. The original plugin was implemented in Ruby, and while it has served its purpose, it no longer meets Microsoft’s Secure Future Initiative (SFI) standards and has limited engineering support. To address both security and sustainability, we have rebuilt the plugin from the ground up in Java, a language that is more secure, better supported across Microsoft, and aligned with long-term platform investments.

To ensure a seamless transition, the new implementation is still packaged and distributed as a standard Logstash Ruby gem. This means the installation and usage experience remains unchanged for customers, while benefiting from a more secure and maintainable foundation.

What's New in This Version

Java‑based and SFI‑compliant

Same Logstash plugin experience, now rebuilt on a stronger foundation. The new implementation is fully Java‑based, aligning with Microsoft’s Secure Future Initiative (SFI) and providing improved security, supportability, and long-term maintainability.

Modern, DCR‑based ingestion
The plugin now uses the Azure Monitor Logs Ingestion API with Data Collection Rules (DCRs), replacing the legacy HTTP Data Collection API (For more info, see Migrate from the HTTP Data Collector API to the Log Ingestion API - Azure Monitor | Microsoft Learn). This gives customers full schema control, enables custom log tables, and supports ingestion into standard Microsoft Sentinel tables as well as Microsoft Sentinel data lake.

Flexible authentication options
Authentication is automatically determined based on your configuration, with support for:

Client secret (App registration / service principal)

Managed identity, eliminating the need to store credentials in configuration files

Sovereign cloud support: The plugin supports Azure sovereign clouds, including Azure US Government, Azure China, and Azure Germany.

Standard Logstash distribution model
The plugin is published on RubyGems.org, the standard distribution channel for Logstash plugins, and can be installed directly using the Logstash plugin manager, no change to your existing installation workflow.

What the Plugin Does

Logstash plugin operates as a three-stage data pipeline: Input → Filter → Output.

Input: You control how data enters the pipeline, using sources such as syslog, filebeat, Kafka, Event Hubs, databases (via JDBC), files, and more.

Filter: You enrich and transform events using Logstash’s powerful filtering ecosystem, including plugins like grok, mutate, and Json, shaping data to match your security and operational needs.

Output: This is where Microsoft comes in. The Microsoft Sentinel Logstash Output Plugin securely sends your processed events to an Azure Monitor Data Collection Endpoint, where they are ingested into Sentinel via a Data Collection Rule (DCR).

With this model, you retain full control over your Logstash pipeline and data processing logic, while the Sentinel plugin provides a secure, reliable path to ingest data into Microsoft Sentinel.

Getting Started

Prerequisites

Logstash installed and running

An Azure Monitor Data Collection Endpoint (DCE) and Data Collection Rule (DCR) in your subscription

Contributor role on your Log Analytics workspace

Who Is This For?

Organizations that already have Logstash pipelines, need to collect from on-premises or legacy systems, and operate in distributed/hybrid environments including air-gapped networks.

To learn more, see: microsoft-sentinel-log-analytics-logstash-output-plugin | RubyGems.org | your community gem host

Accelerate Agent Development: Hacks for Building with Microsoft Sentinel data lake

MitchellGulledge — Thu, 02 Apr 2026 21:37:47 GMT

As a Senior Product Manager | Developer Architect on the App Assure team working to bring Microsoft Sentinel and Security Copilot solutions to market, I interact with many ISVs building agents on Microsoft Sentinel data lake for the first time. I’ve written this article to walk you through one possible approach for agent development – the process I use when building sample agents internally at Microsoft. If you have questions about this, or other methods for building your agent, App Assure offers guidance through our Sentinel Advisory Service.

Throughout this post, I include screenshots and examples from Gigamon’s Security Posture Insight Agent.

This article assumes you have:

An existing SaaS or security product with accessible telemetry.
A small ISV team (2–3 engineers + 1 PM).
Focus on a single high value scenario for the first agent.

The Composite Application Model (What You Are Building)

When I begin designing an agent, I think end-to-end, from data ingestion requirements through agentic logic, following the Composite application model.

The Composite Application Model consists of five layers:

Data Sources – Your product’s raw security, audit, or operational data.
Ingestion – Getting that data into Microsoft Sentinel.
Sentinel data lake & Microsoft Graph – Normalization, storage, and correlation.
Agent – Reasoning logic that queries data and produces outcomes.
End User – Security Copilot or SaaS experiences that invoke the agent.

This separation allows for evolving data ingestion and agent logic simultaneously. It also helps avoid downstream surprises that require going back and rearchitecting the entire solution.

Optional Prerequisite

You are enrolled in the ISV Success Program, so you can earn Azure Credits to provision Security Compute Units (SCUs) for Security Copilot Agents.

Phase 1: Data Ingestion Design & Implementation

Choose Your Ingestion Strategy

The first choice I face when designing an agent is how the data is going to flow into my Sentinel workspace. Below I document two primary methods for ingestion.

Option A: Codeless Connector Framework (CCF)
- This is the best option for ISVs with REST APIs. To build a CCF solution, reference our documentation for getting started.
Option B: CCF Push (Public Preview)
- In this instance, an ISV pushes events directly to Sentinel via a CCF Push connector. Our MS Learn documentation is a great place to get started using this method.

Additional Note:

In the event you find that CCF does not support your needs, reach out to App Assure so we can capture your requirements for future consideration. Azure Functions remains an option if you’ve documented your CCF feature needs.

Phase 2: Onboard to Microsoft Sentinel data lake

Once my data is flowing into Sentinel, I onboard a single Sentinel workspace to data lake. This is a one-time action and cannot be repeated for additional workspaces.

Onboarding Steps

Go to the Defender portal.
Follow the Sentinel Data lake onboarding instructions.
Validate that tables are visible in the lake.
See Running KQL Queries in data lake for additional information.

Phase 3: Build and Test the Agent in Microsoft Foundry

Once my data is successfully ingested into data lake, I begin the agent development process. There are multiple ways to build agents depending on your needs and tooling preferences. For this example, I chose Microsoft Foundry because it fit my needs for real-time logging, cost efficiency, and greater control.

1. Create a Microsoft Foundry Instance

Foundry is used as a tool for your development environment. Reference our QuickStart guide for setting up your Foundry instance.

Required Permissions:

Security Reader (Entra or Subscription)
Azure AI Developer at the resource group

After setup, click Create Agent.

2. Design the Agent

A strong first agent:

Solves one narrow security problem.
Has deterministic outputs.
Uses explicit instructions, not vague prompts.

Example agent responsibilities:

To query Sentinel data lake (Sentinel data exploration tool).
To summarize recent incidents.
To correlate ISVs specific signals with Sentinel alerts and other ISV tables (Sentinel data exploration tool).

3. Implement Agent Instructions

Well-designed agent instructions should include:

Role definition ("You are a security investigation agent…").
Data sources it can access.
Step by step reasoning rules.
Output format expectations.

Sample Instructions can be found here: Agent Instructions

4. Configure the Microsoft Model Context Protocol (MCP) tooling for your agent

For your agent to query, summarize and correlate all the data your connector has sent to data lake, take the following steps:

Select Tools, and under Catalog, type Sentinel, and then select Microsoft Sentinel Data Exploration. For more information about the data exploration tool collection in MCP server, see our documentation.

I always test repeatedly with real data until outputs are consistent. For more information on testing and validating the agent, please reference our documentation.

Phase 4: Migrate the Agent to Security Copilot

Once the agent works in Foundry, I migrate it to Security Copilot. To do this:

Copy the full instruction set from Foundry
Provision a SCU for your Security Copilot workspace. For instructions, please reference this documentation.
- Make note of this process as you will be charged per hour per SCU
- Once you are done testing you will need to deprovision the capacity to prevent additional charges
Open Security Copilot and use Create From Scratch Agent Builder as outlined here.
Add Sentinel data exploration MCP tools (these are the same instructions from the Foundry agent in the previous step).
- For more information on linking the Sentinel MCP tools, please refer to this article.
Paste and adapt instructions.

At this stage, I always validate the following:

Agent Permissions – I have confirmed the agent has the necessary permissions to interact with the MCP tool and read data from your data lake instance.
Agent Performance – I have confirmed a successful interaction with measured latency and benchmark results.

This step intentionally avoids reimplementation. I am reusing proven logic.

Phase 5: Execute, Validate, and Publish

After setting up my agent, I navigate to the Agents tab to manually trigger the agent. For more information on testing an agent you can refer to this article.

Now that the agent has been executed successfully, I download the agent Manifest file from the environment so that it can be packaged.

Click View code on the Agent under the Build tab as outlined in this documentation.

Publishing to the Microsoft Security Store

If I were publishing my agent to the Microsoft Security Store, these are the steps I would follow:

Finalize ingestion reliability.
Document required permissions.
Define supported scenarios clearly.
Package agent instructions and guidance (by following these instructions).

Summary

Based on my experience developing Security Copilot agents on Microsoft Sentinel data lake, this playbook provides a practical, repeatable framework for ISVs to accelerate their agent development and delivery while maintaining high standards of quality. This foundation enables rapid iteration—future agents can often be built in days, not weeks, by reusing the same ingestion and data lake setup.

When starting on your own agent development journey, keep the following in mind:

To limit initial scope.
To reuse Microsoft managed infrastructure.
To separate ingestion from intelligence.

What Success Looks Like

At the end of this development process, you will have the following:

A Microsoft Sentinel data connector live in Content Hub (or in process) that provides a data ingestion path. 
Data visible in data lake. 
A tested agent running in Security Copilot.
Clear documentation for customers.

A key success factor I look for is clarity over completeness. A focused agent is far more likely to be adopted.

Need help?

If you have any issues as you work to develop your agent, please reach out to the App Assure team for support via our Sentinel Advisory Service . Or if you have any other tips, please comment below, I’d love to hear your feedback.

Microsoft Sentinel MCP Server with external AI models (Claude) for natural language investigations

mcasgrain — Wed, 22 Apr 2026 21:35:29 GMT

Security teams are increasingly exploring how AI assistants support them in investigating incidents, asking questions, and exploring their data. At the same time, controlling how data is accessed remains critical. Today, we’re sharing how Sentinel can support a third-party AI assistant like Claude through a new integration approach using Sentinel’s Model Context Protocol (MCP) server, while continuing to rely on Microsoft Entra ID for enterprise grade authentication and access control. This approach uses Microsoft Sentinel with Entra ID to let third-party AI tools access Sentinel data.

Why this matters

Sentinel customers can explore security data using natural language to assist investigations, while preserving strict tenant isolation and access controls, without managing app registrations or shared secrets. AI third-party assistants like Claude can access Sentinel through Microsoft’s existing security infrastructure. When a query is made, the assistant calls the Sentinel MCP server, which enforces authentication via Entra ID before returning data. This Claude third-party connector is now available. Click here for detailed guidance.

Resources

Use the Microsoft Sentinel MCP connector in ChatGPT or Claude Code
Use the Microsoft Sentinel MCP connector in ChatGPT or Claude - Microsoft Security | Microsoft Learn

Sentinel MCP overview
What is Microsoft Sentinel MCP server's tool collection? - Microsoft Security | Microsoft Learn
Get started with Sentinel MCP
Get started with Microsoft Sentinel MCP server - Microsoft Security | Microsoft Learn

How Granular Delegated Admin Privileges (GDAP) allows Sentinel customers to delegate access

Yossi Basha — Thu, 16 Apr 2026 14:40:52 GMT

Simplifying Defender SIEM and XDR delegated access

As Microsoft Sentinel and Defender converge into a unified experience, organizations face a fundamental challenge: the lack of a scalable, comprehensive, delegated access model that works seamlessly across Entra ID and Sentinel’s Azure Resource Manage creating a significant barrier for Managed Security Service Providers (MSSPs) and large enterprises with complex multi-tenant structures.

Extending GDAP beyond CSPs: a strategic solution

In response to these challenges, we have developed an extension to GDAP that makes it available to all Sentinel and Defender customers, including non-CSP organizations. This expansion enables both MSSPs and customers with multi-tenant organizational structures to establish secure, granular delegated access relationships directly through the Microsoft Defender portal. This is now available in public preview.

The GDAP extension aligns with zero-trust security principles through a three-way handshake model requiring explicit mutual consent between governing and governed tenants before any relationship is established. This consent-based approach enhances transparency and accountability, reducing risks associated with broad, uncontrolled permissions. By integrating with Microsoft Defender, GDAP enables advanced threat detection and response capabilities across tenant boundaries while maintaining granular permission management through Entra ID roles and Unified RBAC custom permissions.

Delivering unified management of delegated access across SIEM and XDR

With GDAP, customers gain a truly unified way to manage access across both Microsoft Sentinel and Defender—using a single, consistent delegated access model for SIEM and XDR. For Sentinel customers, this brings parity with the Azure portal experience: where delegated access was previously managed through Azure Lighthouse, it can now be handled directly in the Defender portal using GDAP. More importantly, for organizations running SIEM and XDR together, GDAP eliminates the need to switch between portals—allowing teams to view, manage, and govern security access from one centralized experience. The result is simpler administration, reduced operational friction, and a more cohesive way to secure multi-tenant environments at scale.

How GDAP for non-CSPs works: the three-step handshake

The GDAP handshake model implements a security-first approach through three distinct steps, each requiring explicit approval to prevent unauthorized access.

Step 1 begins with the governed tenant initiating the relationship, allowing the governing tenant to request GDAP access.

Step 2 shifts control to the governing tenant, which creates and sends a delegated access request with specific requested permissions through the multi-tenant organization (MTO) portal.

Step 3 returns to the governed tenant for final approval.

The approach provides customers with complete visibility and control over who can access their security data and with what permissions, while giving MSSPs a streamlined, Microsoft-supported mechanism for managing delegated relationships at scale.

Step 4 assigns Sentinel permissions.

In Azure resource management, assign governing tenant’s groups with Sentinel workspaces permissions (in the governed tenant), selecting the governing tenant’s security groups used in the created relationship.

Learn more here: Configure delegated access with governance relationships for multitenant organizations - Unified se…

Agentic Use Cases for Developers on the Microsoft Sentinel Platform

Sai_Marapareddy — Fri, 20 Mar 2026 20:46:02 GMT

Interested in building an agent with Sentinel platform solutions but not sure where to start? This blog will help you understand some common use cases for agent development that we’ve seen across our partner ecosystem.

SOC teams don’t need more alerts - they need fast, repeatable investigation and response workflows. Security Copilot agents can help orchestrate the steps analysts perform by correlating across the Sentinel data lake, executing targeted KQL queries, fetching related entities, enriching with context, and producing an evidence-backed decision without forcing analysts to switch tools.

Microsoft Sentinel platform is a strong foundation for agentic experiences because it exposes a normalized security data layer, an investigation surface based on incidents and entities, and extensive automation capabilities. An agent can use these primitives to correlate identity, endpoint, cloud, and network telemetry; traverse entity relationships; and recommend remediation actions.

In this blog, I will break down common agentic use cases that developers can implement on Sentinel platform, framed in buildable and repeatable patterns:

Identify the investigation scenario
Understand the required Sentinel data connectors and KQL queries
Build enrichment and correlation logic
Summarize findings with supporting evidence and recommended remediation steps

Use Case 1: Identity & Access Intelligence

Investigation Scenario: Is this risky sign-in part of an attack path?

Signals Correlated:

Identity access telemetry: Source user, IPs, target resources, MFA logs
Authentication outcomes and diversity: Success vs. failure, Geographic spread
Identity risk posture: User risk level/state
Post-auth endpoint execution: Suspicious LOLBins

Correlation Logic:

An analyst receives a risky sign-in signal for a user and needs to determine whether the activity reflects expected behavior - such as travel, remote access, or MFA friction - or if it signals the early stage of an identity compromise that could escalate into privileged access and downstream workload impact.

Practical Example:

Silverfort Identity Threat Triage Agent, which is built on a similar framework, takes the user’s UPN as input and builds a bounded, last-24-hour investigation across authentication activity, MFA logs, user risk posture, and post-authentication endpoint behavior.

Outcome:

By correlating identity risk signals, MFA logs, sign-in success and failure patterns, and suspicious execution activity following authentication, the agent connects the initial risky sign-in to endpoint behavior, enabling the analyst to quickly assess compromise likelihood, identify escalation indicators, and determine appropriate remediation actions.

“Our collaboration with Microsoft Sentinel and Security Copilot underscores the central role identity plays across every stage of attack path triage. By integrating Silverfort’s identity risk signals with Microsoft Entra ID and Defender for Endpoint, and sharing rich telemetry across platforms, we enable Security Copilot Agent to distinguish isolated anomalies from true identity-driven intrusions - while dramatically reducing the manual effort traditionally required for incident response and threat hunting.

AI-driven agents accelerate analysis, enrich investigative context, reduce dwell time, and speed detection. Instead of relying on complex queries or deep familiarity with underlying data structures, security teams can now perform seamless, identity-centric reasoning within a single interaction.”

- Frank Gasparovic, Director of Solution Architecture, Technology Alliances, Silverfort

Use Case 2: Cyber Resilience, Backup & Recovery

Investigation Scenario: Are the threats detected on a backup indicative of production impact and recovery risk?

Signals Correlated:

Backup threat telemetry: Backup threat scan alerts, risk analysis events, affected host/workload, detection timestamps
Cross-vendor security alerts: Endpoint, network, and cloud security alerts for the same host/workload in the same time window

Correlation Logic:

The agent correlates threat signals originating from the backup environment with security telemetry associated with same host/workload to validate whether there is corroborating evidence in the production environment and whether activity aligns in time.

Practical Example:

Commvault Security Investigation Agent, which is built on a similar framework, takes a hostname as input and builds an investigation across Commvault Threat Scan / Risk Analysis events and third-party security telemetry. By correlating backup-originating detections with production security activity for the same host, the agent determines whether the backup threat signal aligns with observable production impact.

Outcome:

By correlating backup threat detections with endpoint, network, and cloud security telemetry while validating timing alignment, event spikes, and data coverage, the agent connects a backup originating threat signal to production evidence, enabling the analyst to quickly assess impact likelihood and determine appropriate actions such as containment or recovery-point validation.

Use Case 3: Network, Exposure & Connectivity

Investigation Scenario: Is this activity indicative of legitimate remote access, or does it demonstrate suspicious connectivity and access attempts that increase risk to private applications and internal resources.

Signals Correlated:

User access telemetry: Source user, source IPs/geo, device/context, destinations
Auth and enforcement outcomes: Success vs. failure, MFA allow/block
Behavior drift: new/rare IPs/locations, unusual destination/app diversity.
Suspicious activity indicators: Risky URLs/categories, known-bad indicators, automated/bot-like patterns, repeated denied private app access attempts

Correlation Logic:

An analyst receives an alert for a specific user and needs to determine whether the activity reflects expected behavior such as travel, remote work, or VPN usage, or whether it signals the early stages of a compromise that could later extend into private application access.

Practical Example:

Zscaler ZIA ZPA Correlation Agent starts with a username and builds a bounded, last-24-hour investigation across Zscaler Internet Access and Zscaler Private Access activity. By correlating user internet behavior, access context, and private application interactions, the agent connects the initial Zscaler alert to any downstream access attempts or authentication anomalies, enabling the analyst to quickly assess risk, identify suspicious patterns, and determine whether Zscaler policy adjustments are required.

Outcome:

Provides a last‑24‑hour verdict on whether the activity reflects expected access patterns or escalation toward private application access, and recommends next actions—such as closing as benign drift, escalating for containment, or tuning access policy—based on correlated evidence.

Use Case 4: Endpoint & Runtime Intelligence

Investigation Scenario: Is this process malicious or a legitimate admin action?

Signals Correlated:

Execution context: Process chain, full command line, signer, unusual path
Account & logon: Initiating user, logon type (RDP/service), recent risky sign-ins
Tooling & TTPs: LOLBins, credential access hints, lateral movement tooling
Network behavior: Suspicious connections, repeated callbacks/beaconing

Correlation Logic:

A PowerShell alert triggers on a production server. The agent ties the process to its parent (e.g., spawned by a web worker vs. an admin shell), validates the command-line indicators, correlates outbound connections from the same PID to a first-seen destination, and checks for immediate follow-on persistence and any adjacent runtime alerts in the same time window.

Outcome:

Classifies the activity as malicious vs. admin and produces an evidence pack (process tree, key command indicators, destinations, persistence/tamper artifacts) as well as the recommended containment step (isolate host and revoke/reset initiating credentials).

Use Case 5: Exposure & Exploitability

Investigation Scenario: What is the likelihood of exploitation and blast radius?

Signals Correlated:

Asset exposure: Internet-facing status, exposed services/ports, and identity or network paths required to reach the workload
Exploit activity: Defender alerts on the resource, IDS/WAF hits, IOC matches, and first seen exploit or probing attempts
Risk amplification signals: Internet communication, high privilege access paths, and indicators that the workload processes PII or sensitive data
Blast radius: Downstream reachability to crown jewel systems (e.g., databases, key vaults) and trust relationships that could enable escalation

Correlation Logic:

An analyst receives a Medium/High Microsoft Defender for Cloud alert on a workload and needs to determine whether it’s a standalone detection or an exploitable exposure that can quickly progress into privilege abuse and data impact. The agent correlates exposure evidence signals such as internet reachability, high-privilege paths, and indicators that workload handles sensitive data by analyzing suspicious network connections in the same bounded time window.

Outcome:

Produces a resource-specific risk analysis that explains why the Defender for Cloud alert is likely to be exploited, based on asset attack surface and effective privileges, plus any supporting activity in the same 24-hour window.

Use Case 6: Threat Intelligence & Adversary Context

Investigation Scenario: Is this activity aligned with known attacker behavior?

Signals Correlated:

Behavior sequence: ordered events identity → execution → network.
Technique mapping: MITRE ATT&CK technique IDs, typical progression, and required prerequisites.
Threat intel match: campaign/adversary, TTPs, IOCs

Correlation Logic:

A chain of identity compromise, PowerShell obfuscation, and periodic outbound HTTPS is observed. The agent maps the sequence to ATT&CK techniques and correlates it with threat intel that matches a known adversary campaign.

Outcome:

Surfaces adversary-aligned behavioral insights and TTP context to help analysts assess intrusion likelihood and guide the next investigation steps.

Summary

This blog is intended to help developers better understand the key use cases for building agents with Microsoft Sentinel platform along with practical patterns to apply when designing and implementing agent scenarios.

Need help? If you have any issues as you work to develop your agent, the App Assure team is available to assist via our Sentinel Advisory Service. Reach out via our intake form.

Resources

Learn more: For a practical overview of how ISVs can move from Sentinel data lake onboarding to building agents, see the Accelerate Agent Development blog - https://aka.ms/AppAssure_AccelerateAgentDev.
Get hands-on: Explore the end-to-end journey from Sentinel data lake onboarding to a working Security Copilot agent through the accompanying lab modules available on GitHub Repo: https://github.com/suchandanreddy/Microsoft-Sentinel-Labs.

RSAC 2026: New Microsoft Sentinel Connectors Announcement

JesseKopavi — Tue, 07 Apr 2026 18:41:22 GMT

Microsoft Sentinel helps organizations detect, investigate, and respond to security threats across increasingly complex environments. With the rollout of the Microsoft Sentinel data lake in the fall, and the App Assure-backed Sentinel promise that supports it, customers now have access to long-term, cost-effective storage for security telemetry, creating a solid foundation for emerging Agentic AI experiences.

Since our last announcement at Ignite 2025, the Microsoft Sentinel connector ecosystem has expanded rapidly, reflecting continued investment from software development partners building for our shared customers. These connectors bring diverse security signals together, enabling correlation at scale and delivering richer investigation context across the Sentinel platform.

Below is a snapshot of Microsoft Sentinel connectors newly available or recently enhanced since our last announcement, highlighting the breadth of partner solutions contributing data into, and extending the value of, the Microsoft Sentinel ecosystem.

New and notable integrations

	Acronis Cyber Protect Cloud Acronis Cyber Protect Cloud integrates with Microsoft Sentinel to bring data protection and security telemetry into a centralized SOC view. The connector streams alerts, events, and activity data - spanning backup, endpoint protection, and workload security - into Microsoft Sentinel for correlation with other signals. This integration helps security teams investigate ransomware and data-centric threats more effectively, leverage built-in hunting queries and detection rules, and improve visibility across managed environments without adding operational complexity.
	Anvilogic Anvilogic integrates with Microsoft Sentinel to help security teams operationalize detection engineering at scale. The connector streams Anvilogic alerts into Microsoft Sentinel, giving SOC analysts centralized visibility into high-fidelity detections and faster context for investigation and triage. By unifying detection workflows, reducing alert noise, and improving prioritization, this integration supports more efficient threat detection and response while helping teams extend coverage across evolving attack techniques.
	BigID BigID integrates with Microsoft Sentinel to extend data security posture management (DSPM) insights into security operations workflows. The solution brings visibility into sensitive, regulated, and critical data across cloud, SaaS, and on‑premises environments, helping security teams understand where high‑risk data resides and how it may be exposed. By incorporating data‑centric risk context into Sentinel, this integration supports more informed investigation and prioritization, enabling organizations to reduce data‑related risk and align security operations with data protection and compliance objectives.
	Commvault Cloud Commvault Cloud integrates with Microsoft Sentinel to bring data protection and cyber‑resilience telemetry into security operations workflows. The connector ingests security‑relevant signals from Commvault Cloud—such as backup anomalies, malware and ransomware indicators, and other threat‑related events—into Sentinel, enabling centralized detection, investigation, and automated response. By correlating backup intelligence with broader Sentinel telemetry, this integration helps security teams reduce blind spots, validate the scope of incidents, and improve coordination between security and recovery operations.
	CyberArk Audit CyberArk Audit integrates with Microsoft Sentinel to centralize visibility into privileged identity and access activity. By streaming detailed audit logs - covering system events, user actions, and administrative activity - into Microsoft Sentinel, security teams can correlate identity-driven risks with broader security telemetry. This integration supports faster investigations, improved monitoring of privileged access, and more effective incident response through automated workflows and enriched context for SOC analysts.
	Cyera Cyera integrates with Microsoft Sentinel to extend AI-native data security posture management into security operations. The connector brings Cyera’s data context and actionable intelligence across multi-cloud, on-premises, and SaaS environments into Microsoft Sentinel, helping teams understand where sensitive data resides and how it is accessed, exposed, and used. Built on Sentinel’s modern framework, the integration feeds context-rich data risk signals into the Sentinel data lake, enabling more informed threat hunting, automation, and decision-making around data, user, and AI-related risk.
	TacitRed CrowdStrike IOC Automation Data443 TacitRed CS IOC Automation integrates with Microsoft Sentinel to streamline the operationalization of compromised credential intelligence. The solution uses Sentinel playbooks to automatically push TacitRed indicators of compromise into CrowdStrike via Sentinel playbooks, helping security teams turn identity-based threat intelligence into action. By automating IOC handling and reducing manual effort, this integration supports faster response to credential exposure and strengthens protection against account-driven attacks across the environment.
	TacitRed SentinelOne IOC Automation Data443 TacitRed SentinelOne IOC Automation integrates with Microsoft Sentinel to help operationalize identity-focused threat intelligence at the endpoint layer. The solution uses Sentinel playbooks to automatically consume TacitRed indicators and push curated indicators into SentinelOne via Sentinel playbooks and API-based enforcement, enabling faster enforcement of high-risk IOCs without manual handling. By automating the flow of compromised credential intelligence from Sentinel into EDR, this integration supports quicker response to identity-driven attacks and improves coordination between threat intelligence and endpoint protection workflows.
	TacitRed Threat Intelligence Data443 TacitRed Threat Intelligence integrates with Microsoft Sentinel to provide enhanced visibility into identity-based risks, including compromised credentials and high-risk user exposure. The solution ingests curated TacitRed intelligence directly into Sentinel, enriching incidents with context that helps SOC teams identify credential-driven threats earlier in the attack lifecycle. With built-in analytics, workbooks, and hunting queries, this integration supports proactive identity threat detection, faster triage, and more informed response across the SOC.
	Cyren Threat Intelligence Cyren Threat Intelligence integrates with Microsoft Sentinel to enhance detection of network-based threats using curated IP reputation and malware URL intelligence. The connector ingests Cyren threat feeds into Sentinel using the Codeless Connector Framework (CCF), transforming raw indicators into actionable insights, dashboards, and enriched investigations. By adding context to suspicious traffic and phishing infrastructure, this integration helps SOC teams improve alert accuracy, accelerate triage, and make more confident response decisions across their environments.
	TacitRed Defender Threat Intelligence Data443 TacitRed Defender Threat Intelligence integrates with Microsoft Sentinel to surface early indicators of credential exposure and identity-driven risk. The solution automatically ingests compromised credential intelligence from TacitRed into Sentinel and can support synchronization of validated indicators with Microsoft Defender Threat Intelligence through Sentinel workflows, helping SOC teams detect account compromise before abuse occurs. By enriching Sentinel incidents with actionable identity context, this integration supports faster triage, proactive remediation, and stronger protection against credential-based attacks.
	Datawiza Access Proxy (DAP) Datawiza Access Proxy integrates with Microsoft Sentinel to provide centralized visibility into application access and authentication activity. By streaming access and MFA logs from Datawiza into Sentinel, security teams can correlate identity and session-level events with broader security telemetry. This integration supports detection of anomalous access patterns, faster investigation through session traceability, and more effective response using Sentinel automation, helping organizations strengthen Zero Trust controls and meet auditing and compliance requirements.
	Endace Endace integrates with Microsoft Sentinel to provide deep network visibility by providing always-on, packet-level evidence. The connector enables one-click pivoting from Sentinel alerts directly to recorded packet data captured by EndaceProbes. This helps SOC and NetOps teams reconstruct events and validate threats with confidence. By combining Sentinel’s AI-driven analytics with Endace’s always-on, full-packet capture across on-premises, hybrid, and cloud environments, this integration supports faster investigations, improved forensic accuracy, and more decisive incident response.
	Feedly Feedly integrates with Microsoft Sentinel to ingest curated threat intelligence directly into security operations workflows. The connector automatically imports Indicators of Compromise (IoCs) from Feedly Team Boards and folders into Sentinel, enriching detections and investigations with context from the original intelligence articles. By bringing analyst‑curated threat intelligence into Sentinel in a structured, automated way, this integration helps security teams stay current on emerging threats and reduce the manual effort required to operationalize external intelligence.
	Gigamon Gigamon integrates with Microsoft Sentinel through a new connector that provides access to Gigamon Application Metadata Intelligence (AMI), delivering high-fidelity network-derived telemetry with rich application metadata from inspected traffic directly into Sentinel. This added context helps security teams detect suspicious activity, encrypted threats, and lateral movement faster and with greater precision. By enriching analytics without requiring full packet ingestion, organizations can reduce noise, manage SIEM costs, and extend visibility across hybrid cloud infrastructure.
	Halcyon Halcyon integrates with Microsoft Sentinel to provide purpose-built ransomware detection and automated containment across the Microsoft security ecosystem. The connector surfaces Halcyon ransomware alerts directly within Sentinel, enabling SOC teams to correlate ransomware behavior with Microsoft Defender and broader Microsoft telemetry. By supporting Sentinel analytics and automation workflows, this integration helps organizations detect ransomware earlier, investigate faster using native Sentinel tools, and isolate affected endpoints to prevent lateral spread and reinfection.
	Illumio The Illumio platform identifies and contains threats across hybrid multi-cloud environments. By integrating AI-driven insights with Microsoft Sentinel and Microsoft Graph, Illumio Insights enables SOC analysts to visualize attack paths, prioritize high-risk activity, and investigate threats with greater precision. Illumio Segmentation secures critical assets, workloads, and devices and then publishes segmentation policy back into Microsoft Sentinel to ensure compliance monitoring.
	Joe Sandbox Joe Sandbox integrates with Microsoft Sentinel to enrich incidents with dynamic malware and URL analysis. The connector ingests Joe Sandbox threat intelligence and automatically detonates suspicious files and URLs associated with Sentinel incidents, returning behavioral and contextual analysis results directly into investigation workflows. By adding sandbox-driven insights to indicators, alerts, and incident comments, this integration helps SOC teams validate threats faster, reduce false positives, and improve response decisions using deeper visibility into malicious behavior.
	Keeper Security The Keeper Security integration with Microsoft Sentinel brings advanced password and secrets management telemetry into your SIEM environment. By streaming audit logs and privileged access events from Keeper into Sentinel, security teams gain centralized visibility into credential usage and potential misuse. The connector supports custom queries and automated playbooks, helping organizations accelerate investigations, enforce Zero Trust principles, and strengthen identity security across hybrid environments.
	Lookout Mobile Threat Defense (MTD) Lookout Mobile Threat Defense integrates with Microsoft Sentinel to extend SOC visibility to mobile endpoints across Android, iOS, and Chrome OS. The connector streams device, threat, and audit telemetry from Lookout into Sentinel, enabling security teams to correlate mobile risk signals such as phishing, malicious apps, and device compromise, with broader enterprise security data. By incorporating mobile threat intelligence into Sentinel analytics, dashboards, and alerts, this integration helps organizations detect mobile driven attacks earlier and strengthen protection for an increasingly mobile workforce.
	Miro Miro integrates with Microsoft Sentinel to provide centralized visibility into collaboration activity across Miro workspaces. The connector ingests organization-wide audit logs and content activity logs into Sentinel, enabling security teams to monitor authentication events, administrative actions, and content changes alongside other enterprise signals. By bringing Miro collaboration telemetry into Sentinel analytics and dashboards, this integration helps organizations detect suspicious access patterns, support compliance and eDiscovery needs, and maintain stronger oversight of collaborative environments without disrupting productivity.
	Obsidian Activity Threat The Obsidian Threat and Activity Feed for Microsoft Sentinel delivers deep visibility into SaaS and AI applications, helping security teams detect account compromise and insider threats. By streaming user behavior and configuration data into Sentinel, organizations can correlate application risks with enterprise telemetry for faster investigations. Prebuilt analytics and dashboards enable proactive monitoring, while automated playbooks simplify response workflows, strengthening security posture across critical cloud apps.
	OneTrust for Purview DSPM OneTrust integrates with Microsoft Sentinel to bring privacy, compliance, and data governance signals into security operations workflows. The connector enriches Sentinel with privacy relevant events and risk indicators from OneTrust, helping organizations detect sensitive data exposure, oversharing, and compliance risks across cloud and non-Microsoft data sources. By unifying privacy intelligence with Sentinel analytics and automation, this integration enables security and privacy teams to respond more quickly to data risk events and support responsible data use and AI-ready governance.
	Pathlock Pathlock integrates with Microsoft Sentinel to bring SAP-specific threat detection and response signals into centralized security operations. The connector forwards security-relevant SAP events into Sentinel, enabling SOC teams to correlate SAP activity with broader enterprise telemetry and investigate threats using familiar SIEM workflows. By enriching Sentinel with SAP security context and focused detection logic, this integration helps organizations improve visibility into SAP landscapes, reduce noise, and accelerate detection and response for risks affecting critical business systems.
	Quokka Q-scout Quokka Q-scout integrates with Microsoft Sentinel to centralize mobile application risk intelligence across Microsoft Intune-managed devices. The connector automatically ingests app inventories from Intune, analyzes them using Quokka’s mobile app vetting engines, and streams security, privacy, and compliance risk findings into Sentinel. By surfacing app-level risks through Sentinel analytics and alerts, this integration helps security teams identify malicious or high-risk mobile apps, prioritize remediation, and strengthen mobile security posture without deploying agents or disrupting users.
	Semperis Lightning Semperis Lightning integrates with Microsoft Sentinel to deliver deep visibility into identity‑centric risk across Active Directory and Microsoft Entra environments. The connector ingests identity security telemetry such as indicators of exposure, Tier 0 assets, and attack path insights into Sentinel, enabling security teams to correlate identity risks with broader security signals. By bringing rich identity context into Sentinel analytics, hunting, and investigations, this integration helps organizations detect, prioritize, and respond to identity‑driven attacks more effectively across hybrid identity infrastructures.
	Synqly Synqly integrates with Microsoft Sentinel to simplify and scale security integrations through a unified API approach. The connector enables organizations and security vendors to establish a bi‑directional connection with Sentinel without relying on brittle, point‑to‑point integrations. By abstracting common integration challenges such as authentication handling, retries, and schema changes, Synqly helps teams orchestrate security data flows into and out of Sentinel more reliably, supporting faster onboarding of new data sources and more maintainable integrations at scale.
	Versasec vSEC:CMS Versasec vSEC:CMS integrates with Microsoft Sentinel to provide centralized visibility into credential lifecycle and system health events. The connector securely streams vSEC:CMS and vSEC:CLOUD alerts and status data into Sentinel using the Codeless Connector Framework (CCF), transforming credential management activity into correlation-ready security signals. By bringing smart card, token, and passkey management telemetry into Sentinel, this integration helps security teams monitor authentication infrastructure health, investigate credential-related incidents, and unify identity security operations within their SIEM workflows.
	VirtualMetric DataStream VirtualMetric DataStream integrates with Microsoft Sentinel to optimize how security telemetry is collected, normalized, and routed across the Microsoft security ecosystem. Acting as a high-performance telemetry pipeline, DataStream intelligently filters and enriches logs, sending high-value security data to Sentinel while routing less-critical data to Sentinel data lake or Azure Blob Storage for cost-effective retention. By reducing noise upstream and standardizing logs to Sentinel ready schemas, this integration helps organizations control ingestion costs, improve detection quality, and streamline threat hunting and compliance workflows.
	VMRay VMRay integrates with Microsoft Sentinel to enrich SIEM and SOAR workflows with automated sandbox analysis and high-fidelity, behavior-based threat intelligence. The connector enables suspicious files and phishing URLs to be submitted directly from Sentinel to VMRay for dynamic analysis, while validated, high-confidence indicators of compromise (IOCs) are streamed back into Sentinel’s Threat Intelligence repository for correlation and detection. By adding detailed attack-chain visibility and enriched incident context, this integration helps SOC teams reduce investigation time, improve detection accuracy, and strengthen automated response workflows across Sentinel environments.
	XBOW XBOW integrates with Microsoft Sentinel to bring autonomous penetration testing insights directly into security operations workflows. The connector ingests automated penetration test findings from the XBOW platform into Sentinel, enabling security teams to analyze validated exploit activity alongside alerts, incidents, and other security telemetry. By correlating offensive testing results with Sentinel detections, this integration helps organizations identify monitoring gaps, validate detection coverage, and strengthen defensive controls using real‑world, continuously generated attack evidence.
	Zero Networks Segment Audit Zero Networks Segment integrates with Microsoft Sentinel to provide visibility into micro-segmentation and access-control activity across the network. The connector can collect audit logs or activities from Zero Networks Segment, enabling security teams to monitor policy changes, administrative actions, and access events related to MFA-based network segmentation. By bringing segmentation audit telemetry into Sentinel, this integration supports compliance monitoring, investigation of suspicious changes, and faster detection of attempts to bypass lateral-movement controls within enterprise environments.
	Zscaler Internet Access (ZIA) Zscaler Internet Access integrates with Microsoft Sentinel to centralize cloud security telemetry from web and firewall traffic. The connector enables ZIA logs to be ingested into Sentinel, allowing security teams to correlate Zscaler Internet Access signals with other enterprise data for improved threat detection, investigation, and response. By bringing ZIA web, firewall, and security events into Sentinel analytics and hunting workflows, this integration helps organizations gain broader visibility into internet-based threats and strengthen Zero Trust security operations.

In addition to these solutions from our third-party partners, we are also excited to announce the following connector published by the Microsoft Sentinel team:

GitHub Enterprise Audit Logs

Microsoft’s Sentinel Promise

For Customers

Every connector in the Microsoft Sentinel ecosystem is built to work out of the box. In the unlikely event a customer encounters any issue with a connector, the App Assure team stands ready to assist.

For Software Developers

Software partners in need of assistance in creating or updating a Sentinel solution can also leverage Microsoft’s Sentinel Promise to support our shared customers. For developers seeking to build agentic experiences utilizing Sentinel data lake, we are excited to announce the launch of our Sentinel Advisory Service to guide developers across their Sentinel journey.

Customers and developers alike can reach out to us via our intake form.

Learn More

Microsoft Sentinel data lake

Microsoft Sentinel data lake: Unify signals, cut costs, and power agentic AI

Introducing Microsoft Sentinel data lake

What is Microsoft Sentinel data lake

Unlocking Developer Innovation with Microsoft Sentinel data lake

Microsoft Sentinel Codeless Connector Framework (CCF)

Create a codeless connector for Microsoft Sentinel

Public Preview Announcement: Microsoft Sentinel CCF Push

What’s New in Microsoft Sentinel Monthly Blog

Microsoft App Assure

App Assure home page

App Assure services

App Assure blog

App Assure Request Assistance Form

App Assure Sentinel Advisory Services announcement

App Assure’s promise: Migrate to Sentinel with confidence

App Assure’s Sentinel promise now extends to Microsoft Sentinel data lake

Ignite 2025 new Microsoft Sentinel connectors announcement

Microsoft Security

Microsoft’s Secure Future Initiative

Microsoft Unified SecOps

Editor's Note - April 7th, 2026: This blog was updated to include connector descriptions for BigID, Commvault, Semperis, and XBOW.

Extending App Assure’s Sentinel Promise through the Sentinel Advisory Service

MikeAdams — Fri, 20 Mar 2026 20:23:18 GMT

At RSAC last year, we introduced the Microsoft Sentinel Promise with a straightforward commitment to our customers: that third-party data ingestion for Sentinel is reliable, predictable, and scalable without the need for complex custom coding and architecting. In other words, your connectors for Sentinel will just work. That promise has guided App Assure’s work ever since, enabling customers to bring data from across their various security solutions into Sentinel to drive clearer insights and stronger protection.

Over the past year, that foundation has proven critical. As organizations move from legacy SIEM platforms to Sentinel, consistent access to high-quality third-party data remains essential, not only for detection and response, but increasingly for advanced analytics and AI-driven security experiences. With the introduction of Microsoft Sentinel data lake, customers and partners can now reason over security data cost-effectively and at greater scale. But as many teams are discovering, unlocking those outcomes requires more than simply getting data in the door.

At App Assure, we’ve seen a clear pattern emerge. Software companies often revisit connector design and data modeling multiple times as they help our mutual customers move from ingestion to analytics, and then again as they begin building agentic AI solutions, whether through Security Copilot, MCP server integrations, or custom workflows. Each iteration brings new requirements and new questions, often upstream of where teams initially started.

That’s why, as an extension of our Sentinel Promise, we’re excited to announce the Sentinel Advisory Service from App Assure.

A Natural Evolution

The Sentinel Advisory Service builds directly on the work we’ve been doing through the Sentinel Promise and our support for Sentinel data lake. Our commitment to helping customers bring third-party data into the platform remains unchanged. What this new service adds is an expert-guided approach focused on helping software companies design customer solutions and data strategies with downstream outcomes in mind.

Rather than addressing ingestion challenges in isolation, the Sentinel Advisory Service is designed to help teams think end-to-end across the Sentinel platform: aligning connector design, data structure, and platform capabilities to support advanced scenarios such as AI agents, analytics jobs, and marketplace-ready solutions. The goal is fewer rebuild cycles, faster progress, and greater confidence as teams move from data ingestion to meaningful security outcomes.

What Sentinel Advisory Service Offers

The Sentinel Advisory Service is a no-cost program delivered by App Assure in close collaboration with Sentinel engineering to continually make it easier to build and maintain connectors that utilize data lake and facilitate building agentic AI solutions on top of it.

Key areas of support include:

Technical workshops covering best practices for Sentinel integrations, data lake usage, and agent development

Advisory guidance on leveraging Sentinel platform features to support AI-driven security scenarios

Code samples and design reviews to unblock development and improve solution quality

Break/fix assistance and escalation paths to Microsoft engineers to assist with software development and provide product feedback

Early Partner Momentum

We’re already seeing strong momentum from software companies participating in early advisory engagements. Partners are working with App Assure to refine Sentinel integrations and explore new agentic AI scenarios built on a solid data foundation. Their work reflects a broader shift across the ecosystem: moving beyond connectivity alone, toward building differentiated, outcome-driven security solutions on Sentinel.

Below are some of the partners we’ve already worked with and what they have to say about the experience:

Srinivas Chakravarty, VP of Cloud & AI Ecosystem, Gigamon	“Through active collaboration with Microsoft Security Engineering and the App Assure team, we quickly created and published our CCF-Push connector to deliver enriched network-derived telemetry from the Gigamon Deep Observability Pipeline into Sentinel data lake. In a parallel sprint, with the introduction of our initial Security Copilot Agent, security teams can apply AI to this network intelligence within Sentinel to uncover threats hidden in encrypted and lateral traffic that might otherwise go undetected.”
Mario Espinoza, Chief Product Officer, Illumio	"Illumio is proud to partner with Microsoft, proving together that cybersecurity can scale. Microsoft's product management teams collaborated closely with Illumio on several integrations, most recently Illumio Insights Agent for Security Copilot and Illumio for Microsoft Sentinel Data Lake Connector. Together, Illumio and Sentinel solutions empower customers to correlate joint security threat findings and ensure breaches don't become disasters."
Duncan Barnes, Director Global Alliances, RSA	"The partnership between RSA and Microsoft, exemplified by the RSA Advisor for Admin Threats agent, underscores the value of the Sentinel Advisory Service. It highlights how collaborative innovation drives differentiated, outcome-driven security solutions, ensuring customers can migrate with confidence and harness the full potential of agentic AI to find, prioritize, and resolve threats faster and more efficiently."
Vlad Sushitsky, Research Engineer, Semperis	“We developed a Security Copilot agent that correlates Tier-0 classifications, identity attack paths, and Indicators of Exposure for any given identity. The correlation is powered by Semperis Lightning telemetry, streamed into the Data Lake through our new data connector. What used to take analysts hours of manually pivoting across multiple tables to piece together an identity's risk profile now happens instantly in a single conversation. This gives our joint customers significantly better visibility into identity threats, faster investigations, and substantial cost savings. Developing the agent on Security Copilot was smooth and fast — thanks to great collaboration with the Microsoft team, we had it up and running in a matter of days.”
Harman Kaur, SVP Technology Strategy and AI, Tanium	"This partnership with Microsoft represents a new level of AI and security integration. Through the Microsoft Sentinel Advisory Service, Tanium integrated AI agents into Microsoft Security Copilot, including the recently launched Tanium Security Triage Agent with Identity Insights. By unifying Tanium’s real-time endpoint intelligence with identity information from the Microsoft Sentinel data lake and Entra ID, security analysts gain the speed, precision and confidence needed to stop threats before they escalate."
Ariel Negrin, Worldwide Head of Partnerships and Alliances, Upwind	"Through the Sentinel Advisory Service and the broader App Assure engineering teams, Microsoft has been side‑by‑side with us, from connector and data model design to advanced AI scenarios, helping us architect for high‑quality ingestion, graph‑aware context, and AI security use cases. That level of hands‑on guidance and roadmap alignment means our joint customers get faster time to value, fewer integration rebuilds, and a more intelligent security experience built on top of the Microsoft security stack they already trust."
Matthew Payne, Field Engineer, XBOW	"The team worked alongside us from the start, not just on ingestion, but on designing how XBOW's penetration testing data should flow into Sentinel to actually drive downstream outcomes. Their engineering guidance helped us build agents for Security Copilot and a Sentinel data connector that turns validated exploit paths into actionable security telemetry. The result is that joint customers can trigger a pentest, see real findings in Sentinel alongside their existing alerts, and investigate and remediate without leaving the Microsoft security console."
Paul Lopez, Principal Solutions Architect, Zscaler	"Organizations looking to improve visibility across internet and private access activities benefit from integrating these signals. Through collaboration with Microsoft’s App Assure team, Zscaler’s ZIA–ZPA Correlation Agent for Security Copilot leverages data from the Sentinel Data Lake to deliver a single, cohesive view, simplifying investigations and enabling faster response times."

Getting Started

The Sentinel Advisory Service is available today for developers building on Microsoft Sentinel and Sentinel data lake. If you’re enhancing an existing connector, designing an AI-driven security solution, or planning how to translate data into action on the Sentinel platform, App Assure is here to help.

As always, our focus remains on customer confidence, ensuring that as Sentinel evolves, the ecosystem around it can evolve just as reliably. The Sentinel Advisory Service is the next step in delivering on that promise. Reach out to us here.

What’s new in Microsoft Sentinel: RSAC 2026

spalani — Fri, 03 Apr 2026 17:54:06 GMT

Security is entering a new era, one defined by explosive data growth, increasingly sophisticated threats, and the rise of AI-enabled operations. To keep pace, security teams need an AI-powered approach to collect, reason over, and act on security data at scale. At RSA Conference 2026 (RSAC), we’re unveiling the next wave of Sentinel innovations designed to help organizations move faster, see deeper, and defend smarter with AI-ready tools. These updates include AI-driven playbooks that accelerate SOC automation, Granular Delegated Admin Privileges (GDAP) and granular role-based access controls (RBAC) that let you scale your SOC, accelerated data onboarding through new connectors, and data federation that enables analysis in place without duplication. Together, they give teams greater clarity, control, and speed.

Come see us at RSAC to view these innovations in action. Hear from Sentinel leaders during our exclusive Microsoft Pre-Day, then visit Microsoft booth #5744 for demos, theater sessions, and conversations with Sentinel experts.

Read on to explore what’s new. See you at RSAC!

Sentinel feature innovations:

Sentinel SIEM
Sentinel data lake
Sentinel graph
Sentinel MCP
Threat Intelligence
Microsoft Security Store
Sentinel promotions

Sentinel SIEM

Playbook generator [Now in public preview]

The Sentinel playbook generator delivers a new era of automation capabilities. You can vibe code complex automations, integrate with different tools to ensure timely and compliant workflows throughout your SOC and feel confident in the results with built in testing and documentation. Customers and partners are already seeing benefit from this innovation.

“The playbook generator gives security engineers the flexibility and speed of AI-assisted coding while delivering the deterministic outcomes that enterprise security operations require. It's the best of both worlds, and it lives natively in Defender where the engineers already work.”

– Jaime Guimera Coll | Security and AI Architect | BlueVoyant

Learn more about playbook generator.

SIEM migration experience [General availability now]

The Sentinel SIEM migration experience helps you plan and execute SIEM migrations through a guided, in-product workflow. You can upload Splunk or QRadar exports to generate recommendations for best‑fit Sentinel analytics rules and required data connectors, then assess migration scope, validate detection coverage, and migrate from Splunk or QRadar to Sentinel in phases while tracking progress.

“The tool helps turn a Splunk to Sentinel migration into a practical decision process. It gives clear visibility into which detections are relevant, how they align to real security use cases, and where it makes sense to enable or prioritize coverage—especially with cost and data sources in mind.”

– Deniz Mutlu | Director | Swiss Post Cybersecurity Ltd

Learn more about SIEM migration experience.

GDAP, unified RBAC, and row-level RBAC for Sentinel [Public preview, April 1]

As Sentinel environments grow for enterprises, MSSPs, hyperscalers, and partners operating across shared or multiple environments, the challenge becomes managing access control efficiently and consistently at scale. Sentinel’s expanded permissions and access capabilities are designed to meet these needs.

Granular Delegated Admin Privileges (GDAP) lets you streamline management across multiple governed tenants using your primary account, based on existing GDAP relationships.
Unified RBAC allows you to opt in to managing permissions for Sentinel workspaces through a single pane of glass, configuring and enforcing access across Sentinel experiences in the analytics tier and data lake in the Defender portal. This simplifies administration and improves operational efficiency by reducing the number of permission models you need to manage.
Row-level RBAC scoping within tables enables precise, scoped access to data in the Sentinel data lake. Multiple SOC teams can operate independently within a shared Sentinel environment, querying only the data they are authorized to see, without separating workspaces or introducing complex data flow changes. Consistent, reusable scope definitions ensure permissions are applied uniformly across tables and experiences, while maintaining strong security boundaries.

To learn more, read our technical deep dives on RBAC and GDAP.

Sentinel data lake

Sentinel data federation [Public preview, April 1]

Sentinel data federation lets you analyze security data in place without copying or duplicating your data. Powered by Microsoft Fabric, you can now federate data from Fabric, Azure Data Lake Storage (ADLS), and Azure Databricks into Sentinel data lake. Federated data appears alongside native Sentinel data, so you can use familiar tools like KQL hunting, notebooks, and custom graphs to correlate signals and investigate across your entire digital estate, all while preserving governance and compliance. You can start analyzing data in place and progressively ingest data into Sentinel for deeper security insights, advanced automation, and AI-powered defense at scale. You are billed only when you run analytics on federated data using existing Sentinel data lake query and advanced insights meters.

Figure 1: Federated data appears alongside native Sentinel tables for unified investigation and hunting

Sentinel cost estimation tool [Public Preview, April 9]

The new Sentinel cost estimation tool offers all Microsoft customers and partners a guided, meter-level cost estimation experience that makes pricing transparent and predictable. A built-in three-year cost projection lets you model data growth and ramp-up over time, anticipate spend, and avoid surprises. Get transparent estimates into spend as you scale your security operations. All other customers can continue to use the Azure calculator for Sentinel pricing estimates. See the Sentinel pricing page for more information.

Figure 2: Plan your Sentinel investment with guided, meter-level cost breakdowns and three-year projections

Sentinel data connectors

A365 Observability connector [Public preview, April 15]

Bring AI agent telemetry into the Sentinel data lake to investigate agent behavior, tool usage, prompts, reasoning and execution using hunting, graph, and MCP workflows.

GitHub audit log connector using API polling [General availability, March 6]

Ingest GitHub enterprise audit logs into Sentinel to monitor user and administrator activity, detect risky changes, and investigate security events across your development environment.

Google Kubernetes Engine (GKE) connector [General availability, March 6]

Collect Google Kubernetes Engine (GKE) audit and workload logs in Sentinel to monitor cluster activity, analyze workload behavior, and detect security threats across Kubernetes environments.

Microsoft Entra and Azure Resource Graph (ARG) connector enhancements [Public preview, April 15]

Enable new Entra assets (EntraDevices, EntraOrgContacts) and ARG assets (ARGRoleDefinitions) in existing asset connectors, expanding inventory coverage and powering richer, built‑in graph experiences for greater visibility.

With over 350 Sentinel data connectors, customers achieve broad visibility into complex digital environments and can expand their security operations effectively.

“Microsoft Sentinel data lake forms the core of our agentic SOC. By unifying large volumes of Microsoft and third-party data, enabling graph-based analysis, and supporting MCP-driven workflows, it allows us to investigate faster, at lower cost, and with greater confidence.”

– Øyvind Bergerud | Head of Security Operations | Storebrand

Learn more about Sentinel data connectors.

Sentinel connector builder agent using Sentinel Visual Studio Code extension [Public preview, March 31]

Build Sentinel data connectors in minutes instead of weeks using the AI‑assisted Connector Builder agent in Visual Studio Code. This low‑code experience guides developers and ISVs end-to-end, automatically generating schemas, deployment assets, connector UI, secure secret handling, and polling logic. Built‑in validation surfaces issues early, so you can validate event logs before deployment and ingestion.

Example prompt in GitHub Copilot Chat:

@sentinel-connector-builder Create a new connector for OpenAI audit logs using https://api.openai.com/v1/organization/audit_logs

Figure 3: The Sentinel Connector Builder agent in VS Code guides you through building a data connector end-to-end, from API documentation to deployment-ready assets

Get started with custom connectors and learn more in our blog.

Data filtering and splitting [Public preview, March 30]

As security teams ingest more data, the challenge shifts from scale to relevance. With filtering and splitting now built into the Defender portal, teams can shape data before it lands in Sentinel, without switching tools or managing custom JSON files. Define simple KQL‑based transformations directly in the UI to 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, cut unnecessary processing, and ensure that 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 two capabilities help you balance cost and performance while scaling data ingestion sustainably as your digital estate grows.

Create workbook reports directly from the data lake [Public preview, April 1]

Sentinel workbooks can now directly run on the data lake using KQL, enabling you to visualize and monitor security data straight from the data lake. By selecting the data lake as the workbook data source, you can now create trend analysis and executive reporting.

Sentinel graph

Custom graphs [Public preview, April 1]

Custom graphs let you build tailored security graphs tuned to your unique security scenarios using data from Sentinel data lake as well as non-Microsoft sources. With custom graph, powered by Fabric, you can build, query, and visualize connected data, uncover hidden patterns and attack paths, and help surface risks that are hard to detect when data is analyzed in isolation. These graphs provide the knowledge context that enables AI-powered agent experiences to work more effectively, speeding investigations, revealing blast radius, and helping you move from noisy, disconnected alerts to confident decisions at scale. In the words of our preview customers:

“We ingested our Databricks management-plane telemetry into the Sentinel data lake and built a custom security graph. Without writing a single detection rule, the graph surfaced unusual patterns of activity and overprivileged access that we escalated for investigation. We didn't know what we were looking for, the graph surfaced the risk for us by revealing anomalous activity patterns and unusual access combinations driven by relationships, not alerts.”

– SVP, Security Solutions | Financial Services organization

Custom graph API usage for creating graph and querying graph will be billed starting April 1, 2026, according to the Sentinel graph meter.

Creating custom graph

Using the Sentinel VS Code extension, you can generate graphs to validate hunting hypotheses, such as understanding attack paths and blast radius of a phishing campaign, reconstructing multi‑step attack chains, and identifying structurally unusual or high‑risk behavior, making it accessible to your team and AI agents. Once persisted via a schedule job, you can access these custom graphs from the ready-to-use section in the graph experience in the Defender portal.

Figure 4: Use AI-assisted vibe coding in Visual Studio Code to create tailored security graphs powered by Sentinel data lake and Fabric

Graphs experience in the Microsoft Defender portal

After creating your custom graphs, you can access them in the graphs section of the Defender portal under Sentinel. From there, you’ll be able to perform interactive graph-based investigations, such as using a graph built for phishing analysis to help you quickly evaluate the impact of a recent incident, profile the attacker, and trace its paths across Microsoft telemetry and third-party data. The new graph experience lets you run Graph Query Language (GQL) queries, view the graph schema, visualize the graph, view graph results in tabular format, and interactively travers the graph to the next hop with a simple click.

Figure 5: Query, visualize, and traverse custom graphs with the new graph experience in Sentinel

Sentinel MCP

Sentinel MCP entity analyzer [General availability, April 1]

Entity analyzer provides reasoned, out-of-the-box risk assessments that help you quickly understand whether a URL or user identity represents potential malicious activity. The capability analyzes data across modalities including threat intelligence, prevalence, and organizational context to generate clear, explainable verdicts you can trust. Entity analyzer integrates easily with your agents through Sentinel MCP server connections to first-party and third-party AI runtime platforms, or with your SOAR workflows through Logic Apps. The entity analyzer is also a trusted foundation for the Defender Triage Agent and delivers more accurate alert classifications and deeper investigative reasoning. This removes the need to manually engineer evaluation logic and creates trust for analysts and AI agents to act with higher accuracy and confidence. Learn more about entity analyzer and in our blog here. Entity analyzer will be billed starting April 1, 2026, based on Security Compute Units (SCU) consumption. Learn more about MCP billing.

Figure 6: Entity analyzer delivers explainable, multi-signal risk assessments for URLs and user identities directly within your investigation workflow

Sentinel MCP graph tool collection [Public preview, April 20]

Graph tool collection helps you visualize and explore relationships between identities and device assets, threats and activities signals ingested by data connectors and alerted by analytic rules. The tool provides a clear graph view that highlights dependencies and configuration gaps, which 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, all from a single, interactive workspace. Executing graph queries via the MCP tools will trigger the graph meter.

Claude MCP connector [Public preview, April 1]

Anthropic Claude can connect to Sentinel through a custom MCP connector, giving you AI-assisted analysis across your Sentinel environment. Microsoft provides step-by-step guidance for configuring a custom connector in Claude that securely connects to a Sentinel MCP server. With this connection you can summarize incidents, investigate alerts, and reason over security signals while keeping data inside Microsoft's security boundary. Access to large language models (LLMs) is managed through Microsoft authentication and role-based controls, supporting faster triage and investigation workflows while maintaining compliance and visibility.

Threat Intelligence

CVEs of interest in the Threat Intelligence Briefing Agent [Public preview in April]

The Threat Intelligence Briefing Agent delivers curated intelligence based on your organization’s configuration, preferences, and unique industry and geographic needs. CVEs of interest which highlights vulnerabilities actively discussed across the security landscape and assesses their potential impact on your environment, delivering more timely threat intelligence insights. The agent automatically incorporates internet exposure data powered by the Sentinel platform to surface threats targeting technologies exposed in your organization. Together, these enhancements help you focus faster on the threats that matter most, without manual investigation.

Microsoft Security Store

Security Store embedded in Entra [General availability, March 23]

As identity environments grow more complex, teams need to move faster and extend Entra with trusted third‑party capabilities that address operational, compliance, and risk challenges. The Security Store embedded directly into Entra lets you discover and adopt Entra‑ready agents and solutions in your workflow. You can extend Entra with identity‑focused agents that surface privileged access risk, identity posture gaps, network access insights, and overall identity health, turning identity data into clear recommendations and reports teams can use immediately. You can also enhance Entra with Verified ID and External ID integrations that strengthen identity verification, streamline account recovery, and reduce fraud across workforce, consumer, and external identities.

Security Store embedded in Microsoft Purview [General availability, March 31]

Extending data security across the digital estate requires visibility and enforcement into new data sources and risk surfaces, often requiring a partnered approach. The Security Store embedded directly into Purview lets you discover and evaluate integrated solutions inside your data security workflows. Relevant partner capabilities surface alongside context, making it easier to strengthen data protection, address regulatory requirements, and respond to risk without disrupting existing processes. You can quickly assess which solutions align to data security scenarios, especially with respect to securing AI use, and how they can leverage established classifiers, policies, and investigation workflows in Purview. Keeping integration discovery in‑flow and purchases centralized through the Security Store means you move faster from evaluation to deployment, reducing friction and maintaining a secure, consistent transaction experience.

Security Store Advisor [General availability, March 23]

Security teams today face growing complexity and choice. Teams often know the security outcome they need, whether that's strengthening identity protection, improving ransomware resilience, or reducing insider risk, but lack a clear, efficient way to determine which solutions will help them get there. Security Store Advisor provides a guided, natural-language discovery experience that shifts security evaluation from product‑centric browsing to outcome‑driven decision‑making. You can describe your goal in plain language, and the Advisor surfaces the most relevant Microsoft and partner agents, solutions, and services available in the Security Store, without requiring deep product knowledge. This approach simplifies discovery, reduces time spent navigating catalogs and documentation, and helps you understand how individual capabilities fit together to deliver meaningful security outcomes.

Sentinel promotions

Extending signups for promotional 50 GB commitment tier [Through June 2026]

The Sentinel promotional 50 GB commitment tier offers small and mid-sized organizations a cost-effective entry point into Sentinel. Sign up for the 50 GB commitment tier until June 30, 2026, and maintain the promotional rate until March 31, 2027. This promotion is available globally with regional variations in pricing and accessible through EA, CSP, and Direct channels. Visit the Sentinel pricing page for details and to get started.

Sentinel RSAC 2026 sessions

All week – Sentinel product demos, Microsoft Booth #5744

Mon Mar 23, 3:55 PM – RSAC 2026 main stage Keynote with CVP Vasu Jakkal
[KEY-M10W] Ambient and autonomous security: Building trust in the agentic AI era
Tue Mar 24, 10:30 AM – Live Q&A session, Microsoft booth #5744 and online
Ask me anything with Microsoft Security SMEs and real practitioners
Tue Mar 24, 11 AM – Sentinel data lake theater session, Microsoft booth #5744
From signals to insights: How Microsoft Sentinel data lake powers modern security operations
Tue Mar 24, 2 PM – Sentinel SIEM theater session, Microsoft booth #5744
Vibe-coding SecOps automations with the Sentinel playbook generator
Wed Mar 25, 12 PM – Executive event at Palace Hotel with Threat Protection GM Scott Woodgate
The AI risk equation: Visibility, control, and threat acceleration
Wed Mar 25, 1:30 PM – Sentinel graph theater session, Microsoft booth #5744
Bringing knowledge-driven context to security with Microsoft Sentinel graph
Wed Mar 25, 5 PM – MISA theater session, Microsoft booth #5744
Cut SIEM costs without reducing protection: A Sentinel data lake case study
Thu Mar 26, 1 PM – Security Store theater session, Microsoft booth #5744
What's next for Security Store: Expanding in portal and smarter discovery
All week – 1:1 meetings with Microsoft security experts
Meet with Microsoft Defender and Sentinel SIEM and Defender Security Operations

Additional resources

Sentinel data lake video playlist
Explore the full capabilities of Sentinel data lake as a unified, AI-ready security platform that is deeply integrated into the Defender portal

Sentinel data lake FAQ blog
Get answers to many of the questions we’ve heard from our customers and partners on Sentinel data lake and billing
AI‑powered SIEM migration experience ninja training
Walk through the SIEM migration experience, see how it maps detections, surfaces connector requirements, and supports phased migration decisions
SIEM migration experience documentation
Learn how the SIEM migration experience analyzes your exports, maps detections and connectors, and recommends prioritized coverage
Accenture collaborates with Microsoft to bring agentic security and business resilience to the front lines of cyber defense

Stay connected

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

Microsoft Sentinel is now supported in Unified RBAC with row-level access

tomasbeerthuis — Tue, 31 Mar 2026 20:25:27 GMT

Enabling streamlined, granular, and scalable permissions

We’re excited to announce the Public Preview of Unified Role Based Access Control (URBAC) for Microsoft Sentinel, together with row-level access. This new capability, available in April, extends the Microsoft Defender Unified RBAC model to Sentinel, enabling streamlined, granular, and scalable permissions management across your security workloads. With the addition of row-level scoping, multiple teams can operate securely within a shared Sentinel environment while using consistent and reusable scope definitions across tables and experiences.

What’s new?

Unified RBAC for Sentinel

Manage in Defender portal: Sentinel permissions can now be managed directly in the Microsoft Defender portal. Assignments can automatically include future data sources and workspaces as they’re added.
Unified permissions model: Manage user privileges for Sentinel and other Defender workloads in a single, consistent system.
Easy role migration: Import existing roles and assignments from Azure Sentinel for easy migration.

Sentinel Scoping

Create and assign scope: Scope can now be created from the permissions page and assigned to users or user groups across workspaces.
Tag data: Scope tags can be applied to rows in tables, using ‘Table Management’, allowing you to create rules that tag newly ingested data automatically with the scope.
Access data: Scoped users can manage alerts, incidents, and hunt over scoped data (including the lake), allowing them to see only the data within their own scope.

Common use-cases include accommodating multiple SOC teams within a shared environment (for example segregated by business unit, geography or discipline), providing access to teams outside of the SOC, or restricting sensitive data.

How does it work?

Sentinel in Unified RBAC

1) Create a custom role

Go to the Permissions page in Defender, and select Defender XDR -> Roles

You can also click Import roles to re-create existing roles in URBAC automatically.
In the Roles page, click Create a custom role.
Enter a role name and description, and select the required permissions using this mapping:

Sentinel Role	Unified RBAC Permissions
Microsoft Sentinel Reader	· Security operations \ Security data basic (read)
Microsoft Sentinel Responder	· Security operations \ Security data basic (read) · Security operations \ Alerts (manage) · Security operations \ Response (manage)
Microsoft Sentinel Contributor	· Security operations \ Security data basic (read) · Security operations \ Alerts (manage) · Security operations \ Response (manage) · Authorization and settings \ Detection tuning (manage)

Click Add assignment and name the assignment.
Select users and/or groups.

Choose the Sentinel workspaces for the assignment.
(Optional) Enable Include future data sources automatically.
Click Submit.

2) Activate Unified RBAC for Sentinel

Go back to the Roles page.
Click on Activate workloads button in the top.

Click on Manage workspaces.
Select the desired workspaces to enable URBAC on.
Click Activate workspaces.

3) Edit, Delete, or Export Roles

To edit: Select the role, click Edit, and update as needed.
To delete: Select the role and click Delete.
To export: Click Export to download a CSV of roles, permissions, and assignments.

Prerequisites

Access to the Microsoft Defender portal: Ensure you can sign in at https://security.microsoft.com.
Global administrator, combined with being a subscription owner OR combined with having user access administrator + Sentinel contributor role on the workspace.
Sentinel workspaces onboarded to Defender portal: Sentinel workspaces must be available in the Defender portal before roles and permissions can be assigned.

Learn more

For more information, see Microsoft Defender XDR Unified role-based access control (RBAC) - Microsoft Defender XDR | Microsoft Learn

Sentinel Scoping

1) Create & assign scope

First, we are going to create a scope tag that we will use to assign to users
Navigate to the Permissions page in the Defender portal
Click Microsoft Defender XDR, and then the Scopes tab

Click on Add Sentinel scope
On this screen, fill out a name for your scope, and optionally a description
That’s it! Scope is created. You can create more scope tags if you like.

Next, we are going to assign this scope tag to users:

Go back to the Permissions page, this time to the Roles tab.
Click on Create custom role.
Fill out the basics (role name, description).
Next, assign permissions as appropriate.
In the assignments screen, select the right users or user groups, the data. sources and data collections (Sentinel workspaces) as appropriate.
Now, select the Sentinel scope Edit button.

Select the scopes (one or more) that you want to assign to this role.
Once you are happy with all the settings, go ahead and submit to save the role.

2) Tag tables with scope

Now that we have created scope and assigned it to users, we are going to tag the tables from which these users should be allowed to see data.
Navigate to the Tables page under Microsoft Sentinel.
Select the table you would like to assign scope to.
Click the Scope tag rule button.

Enable scoping by clicking the toggle on Allow use of scope tags for RBAC.
Then, click the toggle under Scope tag rule to enable your first rule.
Add a KQL rule/expression which will specify which rows in this table should be tagged to the scope that you will attach. This will create a Data Collection Rule, and supports transformKQL supported operators and limits. Be aware of how to write expressions here: for example, to scope by location you can write: Location == 'Spain'.
Then, select the scope tag that should be assigned to those rows.
Once you are done, go ahead and click Save. From now on, all data/each row that gets ingested into this table that meets the KQL rule/expression will be tagged with the scope tag that you’ve selected.

3) Access data

a) Now that we’ve created scope, assigned it to users, and tagged the right data, we are ready to start using the scope.

b) From now on, newly ingested data automatically gets tagged with scope. Historic (previously ingested) data is not included.

c) You can add this scope to your detection rules by referencing the ‘SentinelScope_CF’ field.

d) Alerts generated based on scoped data are now automatically tagged with the associated scope.

e) Your scoped users can now access the different experiences where scoped data is visible, for example:

f) View alerts that have resulted from data tagged with scope.

g) View incidents that contain alerts with data tagged with scope.

h) Run advanced hunting queries over the rows in the tables that the user is allowed to see.

i) Run KQL queries over the Sentinel lake.

Prerequisites

Access to the Microsoft Defender portal: https://security.microsoft.com.
Sentinel workspaces onboarded to Defender portal: Sentinel workspaces must be available in the Defender portal before roles and permissions can be assigned.
Sentinel in URBAC: You must have enabled Sentinel in URBAC before using this feature.
Permissions (for the person creating/assigning scope and tagging tables).
Security Authorization (Manage) permission (URBAC): Allowing you to create scope and assignments.
Data Operations (Manage) permission (URBAC): for Table Management.
Subscription owner or assigned with the “Microsoft.Insights/DataCollectionRules/Write” permission.

FAQ

What happens to legacy Sentinel roles after activating Unified RBAC?

URBAC becomes the primary source of your permissions for Sentinel instead of Azure RBAC, so ensure the right permissions are set up on URBAC. Once URBAC is activated for a Sentinel workspace, continue to manage your permissions in URBAC.

What about roles that are not yet supported?

For example, the Automation Contributor role. You can assign these on Azure RBAC and they will continue to be respected.

Can I revert to managing Sentinel roles in Azure after enabling Unified RBAC?

Yes, you can deactivate Unified RBAC for Sentinel in the Defender portal’s workload settings. This will revert to legacy Sentinel roles and their associated access controls.

Does Unified RBAC support both Sentinel Analytics and Lake workspaces?

Yes, Unified RBAC supports both Sentinel Analytics and lake workspaces for consistent access management.

What happens if an alert contains data outside of the user’s scope?

The scoped user can only see the data associated with their scope. If the alert contains entities/evidence that the user has no access to, they will not be able to see those. If the user has access to at least one of the associated entities, they can see the alert itself.

What happens to incidents that contain multiple alerts?

The scoped user can see an incident if they have access to at least one of the underlying alerts. A scoped user can manage the incident if they have access to all of the underlying alerts and if they have the required permission. Unscoped users can see all alerts and incidents.

What about other experiences; detection rules, playbooks, etc.?

A scoped user can only have read access to other resources/experiences for the moment, unless you create a separate assignment where you grant them elevated permissions. In the next few months, we will be introducing scoping for resources such as detection rules, automation rules, playbooks, etc.

Is Sentinel Scoping also applicable to the Sentinel lake?

Yes, to any tables that support transformations (data collection rules).

Can I apply scope to a full table? What about previously ingested data?

You can create a KQL query that captures all fields in the table, which essentially creates ‘table level’ scope. Currently, it is not possible to grant access at full-table level (meaning, scoping previously ingested data).

Can I scope XDR tables?

Not currently. This includes XDR tables which received extended retention in the lake.

If I ingest Defender data into Sentinel, is their scope (e.g. Device Groups, Cloud Scopes) maintained in Sentinel tables?

No, if you ingest Defender data into Sentinel, that scoping is not propagated. Please keep this in mind when deciding how to apply scope to Sentinel tables.

Interested in learning more? Stay tuned for a webinar coming in April.

Turning historical patterns into actionable detection pipelines with Microsoft Sentinel data lake

Ashwin_Patil — Wed, 18 Mar 2026 16:00:00 GMT

This article is part of the Sentinel data lake practitioner series. In part 1, we introduced the Operationalization Framework — a structured way to turn exploratory notebooks into reliable, scheduled Spark jobs within the Microsoft Sentinel data lake.

Now in Part 2, we go from framework to function — showing how defenders can turn historical data into fresh, actionable insights using modular pipelines built around one of the most persistent threats today: Password Spray attacks.

Why Password Spray Still Matters

Unlike brute-force attacks that hammer one account, password spray campaigns try a few passwords across many accounts, often over days or weeks, to avoid lockouts.
Most detections look at short-term bursts — missing these low-and-slow campaigns that quietly persist. As organizations scale billions of sign-in events per day, detection teams face an operational dilemma: how to retain long-term behavioral visibility without re-querying terabytes of raw telemetry.

Attackers rotate IPs, leverage shared ASNs (Autonomous System Number), and reuse proxy networks. To detect such behavior, analysts need historical memory — visibility into repeated patterns and attacker infrastructure.

Sentinel data lake notebooks for password spray

The new Password Spray pipeline is a suite of Spark notebooks that implements a modular, cost-efficient pipeline for detecting password spray attacks.
It transforms noisy authentication logs into structured behavioral features through three modular notebooks:

Quick summary of what each notebook does and what it produces:

Notebook	Description	Output Table
data_backfill_setup (optional)	Sets parameters and (optionally) backfills historical days for long-term context.	signin_summary_daily_SPRK_CL signin_stats_daily_SPRK
signinlogs_summaryandstats_daily	Aggregates raw sign-in logs into daily rollups and statistics.	signin_summary_daily_SPRK_CL signin_stats_daily_SPRK
password_spray_features	Computes behavioral features every 4 hours by comparing recent activity to historical days of history with lookback.	password_spray_features_SPRK_CL

Together, these notebooks separate daily summaries (data lake layer) from feature computation (analytics layer) minimizing cost while keeping analytics fresh.

High Level Architecture

Below is a high-level architecture for the Password Spray Detection Pipeline through a modular, scalable approach.

Key Components:

Raw Data Ingestion

The pipeline starts with the ingestion of raw sign-in logs from the Sentinel data lake. Historical data is seeded using the data_backfill_setup module, ensuring long-term behavioral visibility for detection. This is an optional step if you want to backfill historical days on the first run to compare with the fresh feature calculation.

Daily Summarization

The signinlogs_summaryandstats_daily notebook processes daily authentication events, creating summary tables and rollups. This separates the “data lake” layer (historical summaries) from the “analytics” layer (real-time analytics), optimizing cost and performance.

Feature Engineering

The password_spray_features notebook runs every 4 hours, merging recent raw data (last 4 hours) with 30–90 days of pre-aggregated historical context generated from either daily summaries or ad-hoc backfill of historical day. It computes behavioral metrics such as total attempts, distinct users, success rate, entropy normalization, and a weighted spray score, labeling each run as LOW, MEDIUM, or HIGH risk. This table can also be written to analytics tier if you want to create alerting workflow on top of this. If you continue to hunt based on notebooks, then you can keep it in the data lake tier.

Feature Outputs

Lastly results are written to feature tables that power downstream security operations:

Alerts: High-confidence incidents for risky IPs. This will require elevating results to analytics tier, so they are accessible via Advanced Hunting.
Threat Hunts: Investigations into recurring ASNs or geographic patterns.
Dashboards: Identity-attack KPIs, heatmaps, and trends run against summary table, so you are not querying raw log table. For dashboarding, relevant summary tables need to be in analytics tier.

Analyst Views

The architecture supports advanced analyst views, including investigations by ASN, IP, country, and city. Entropy metrics help correlate related IPs under shared cloud or proxy providers, enabling defenders to identify persistent attacker infrastructure and feed high-risk ASNs into blocklists or enrichment systems.

Inside the Feature Notebook – Detailed Breakdown

The password_spray_features notebook transforms aggregated sign-in data into behavioral indicators that quantify the likelihood of password spray activity.
Rather than relying on simple thresholds (e.g., “X failed logons per minute”), it computes multi-dimensional features capturing attacker behavior over time.

Key Glossary Terms

Below is key glossary terms used throughout the section to describe the process.

ASN: Network Autonomous System Number; helps identify ISP or network owner.
Username entropy: The Shannon entropy quantifies how evenly usernames are distributed within an IP’s attempt. E.g. High entropy – attacker spreading attempts broadly, low entropy – focused attempts (potential internal automations)
Normalization: To ensure feature compatibility across scales, the values were normalized against max values derived globally. E.g. distinct_users_norm = distinct_users/max(distinct_users)
Spray score: Composite weighted score combining distinct user count, entropy, and success rate.

Notes for Practitioners

Entropy helps reduce false positives — differentiating focused logon failures (legitimate user typos) from broad credential sprays.
Normalization keeps scores stable — enabling comparisons across time ranges and environments.
Spray score risk label tiers support alerting and downstream triage automation, allowing SOC teams to prioritize IPs with high potential impact.
The daily summary and feature tables are reusable artifacts — can feed dashboards, threat hunts, UEBA models, or scheduled detections in Sentinel Analytics tier.

Data Input and Time Window

Each execution processes:

Recent activity (e.g., last 4 hours)
Combined with a historical lookback window (e.g., 30-90 days)

This creates a hybrid snapshot balancing recency with historical persistence, allowing slow-moving campaigns to stand out.

Feature Computation

Each IP address grouped by ASN, City, and Country is analyzed to extract behavioral metrics.

Below is high level schema transformation diagram showing from raw logs to summary calculation and finally computing the features from recent time window- scheduled to run at defined frequency.

Spray Score Formula

The spray_score combines normalized metrics and inverse success ratio to produce a single behavioral likelihood score.

Explanation:

distinct_users_norm (50%) emphasizes spread of attack.
(1 - success_rate) (20%) penalizes benign IPs with legitimate logons.
entropy_norm (30%) captures randomness typical of distributed attacks.

Each component is rounded to two decimals for readability and consistent scoring.

Risk Labelling

Since the score is normalized to 0-1, it can be bucketed into qualitative risk tiers.

Range	Label	Meaning
< 0.3	LOW	Likely benign / low spread
0.3–0.6	MEDIUM	Possible automated scanning or early spray
≥ 0.6	HIGH	High-confidence password spray behavior

Output Schema

Each row in the resulting password_spray_features_SPRK table represents a unique IP and its behavioral fingerprint for a given analysis

Column	Description
IPAddress	Source IP address
ASN, City, Country	Enrichment context
attempts_total, success_count, distinct_users, days_active	Base metrics
username_entropy, distinct_users_norm, entropy_norm, success_rate	Derived features
spray_score, spray_score_label	Final behavioral score and label
detection_window_start, detection_window_end, run_date	Window boundaries for reproducibility

Here is a visual depicting the flow of feature calculations for the password spray detection notebook — from raw metrics → normalization → scoring → labeling — in a clean horizontal layout.

Tracking Adversary Infrastructure

Including ASN, City, Country, and entropy metrics allows defenders to:

Correlate related IPs under shared cloud or proxy providers
Identify persistent attacker infrastructure across days or weeks
Feed high-risk ASNs into TI blocklists or Defender XDR enrichment

Call to Action: Operationalize in 30 minutes

Deploy the three notebooks (backfill, daily summary, features) into your Sentinel data lake workspace using VSCode extension once you clone the repo locally.
Run data_backfill_setup once (optional) to seed 30–90 days of history.
Schedule signinlogs_summaryandstats_daily to run daily and write summary tables.
Schedule password_spray_features every 4 hours to produce password_spray_features_SPRK_CL.
Operationalize outputs: hunt in the feature table, dashboard on summaries, and (optionally) write high-risk results to Analytics tier for alert rules. Notebook has Recommended monitoring queries for hunting and analytics.

Daily Spray Activity Summary

password_spray_features_SPRK_CL| where run_date >= ago(7d)| summarize TotalSprayIPs = dcount(IPAddress), HighRiskIPs = dcountif(IPAddress, spray_score_label == "HIGH"), TopCountries = make_set(Country, 5)by bin(run_date, 1d)

Persistent Threat Actors

password_spray_features_SPRK_CL| where spray_score_label in ("HIGH", "MEDIUM")| where days_active >= 3 // Active for multiple days| top 20 by spray_score desc

Conclusion

Rather than focusing solely on short-lived spikes in telemetry, detections should incorporate historical context to identify persistent adversary behavior. For example, an attacker may attempt a small set of common passwords across many accounts each night while rotating IP addresses, thereby avoiding suspicion within any single 15‑minute window. By correlating low-volume activity over a 30–90 day lookback period, detections can attribute recurring infrastructure to a slow, sustained password-spray campaign and surface persistence—not just isolated activity.

By turning Spark notebooks into modular, operational pipelines within Microsoft Sentinel data lake, we create a repeatable detection architecture — one that scales analytics, reduces costs, and integrates seamlessly into your broader SIEM ecosystem.

As organizations shift from reactive to proactive detection engineering, the Sentinel data lake emerges as the foundation for next-generation behavioral analytics — where every authentication log record has a second life as a feature, a score, or an insight.

Resources

For more resources, see:

Notebook Jobs in Sentinel - Learn to schedule and automate your notebooks
Sentinel Provider Class Reference - Complete API documentation for MicrosoftSentinelProvider
Sentinel data lake GitHub - Out-of-the Box Notebooks and KQL queries for data lake.
Operationalizing the Sentinel data lake: A Practitioner’s Guide

Microsoft partners with DataBahn to accelerate enterprise deployments for Microsoft Sentinel

JamesAde — Wed, 18 Mar 2026 16:40:17 GMT

Enterprise security teams are collecting more telemetry than ever across cloud platforms, endpoints, SaaS applications, and on-premises infrastructure. Security teams want broader data coverage and longer retention without losing control of cost and data quality.

This post explains the new DataBahn integration with Microsoft Sentinel, why it matters for SIEM operations, and how to think about using a security data pipeline alongside Sentinel for onboarding, normalization, routing, and governance.

DataBahn joins Microsoft Sentinel partner ecosystem

This integration reflects Microsoft Sentinel’s open partner ecosystem, giving customers choice in the partners they use alongside Microsoft Sentinel to manage their security data pipelines. DataBahn joins a broader set of complementary partners, enabling customers to tailor solutions for their unique security data needs. DataBahn is available through Microsoft Marketplace and is eligible for customers to apply existing Azure Consumption Commitments toward the purchase of DataBahn.

Why this matters for security operations teams

Security teams are under relentless pressure to ingest more data, move faster through SIEM migrations, and preserve data fidelity for detections and investigations, all while managing costs effectively. The challenge isn’t just ingesting data, but ensuring the right telemetry arrives in a consistent, governed format that analysts and detections can trust.

This is where a security data pipeline, alongside Microsoft Sentinel’s native connectors and DCRs, can add value. It helps streamline onboarding of third-party and custom sources, improve normalization consistency, and provide operational visibility across diverse environments as deployments scale.

What DataBahn integration is positioned to do with Microsoft Sentinel

Security teams want broader coverage and need to ensure third-party data is consistently shaped, routed, and governed at scale. This is where a security data pipeline like DataBahn complements Microsoft Sentinel. Sitting upstream of ingestion, the pipeline layer standardizes onboarding and shaping across sources while providing operational visibility into data flow and pipeline health. Together, the collaboration focuses on reducing onboarding friction, improving normalization consistency, enabling intentional routing, and strengthening governance signals so teams can quickly detect source changes, parser breaks, or data gaps—while staying aligned with Sentinel analytics and detection workflows.

This model gives Sentinel customers more choice to move faster, onboard data at scale, and retain control over data routing.

Key capabilities

Bidirectional data integration

The integration enables seamless delivery of telemetry into Sentinel while aligning with Sentinel detection logic and schema expectations.

This helps ensure telemetry pipelines remain consistent with:

Sentinel detection formats

Custom analytics rules

Sentinel data models and schemas

Automated table and DCR management

As detections evolve, pipeline configurations can adapt to maintain detection fidelity and data consistency.

Advanced management API

DataBahn provides an advanced management API that allows organizations to programmatically configure and manage pipeline integrations with Sentinel.

This enables teams to:

Automate pipeline configuration

Manage operational workflows

Integrate pipeline management into broader security or DevOps automation processes

Automatic identification of configuration conflicts

In complex environments with multiple telemetry sources and routing rules, configuration conflicts can arise across filtering logic, enrichment pipelines, and detection dependencies.

The integration helps automatically:

Detect conflicts in filtering rules and pipeline logic

Identify clashes with detection dependencies

Highlight missing configurations or coverage gaps

Automated detection of configuration conflicts and pipeline rule dependencies

This visibility allows SOC teams to quickly identify issues that could impact detection reliability.

Centralized pipeline management

The integration enables centralized management of data collection and transformation workflows associated with Sentinel telemetry pipelines.

This provides unified visibility and control across telemetry sources while maintaining compatibility with Sentinel analytics and detections.

Centralized management simplifies operations across large environments where multiple telemetry pipelines must be maintained.

Centralized pipeline management for telemetry sources across the environment

Flexible data transformation and customization

Security telemetry often arrives in inconsistent formats across vendors and platforms.

The platform supports flexible transformation capabilities that allow organizations to:

Normalize logs into standard or custom Sentinel table formats

Add or derive fields required by Sentinel detections

Apply filtering or enrichment rules before ingestion

Configuration can be performed through a single-screen workflow, enabling teams to modify schemas and define filtering logic without disrupting downstream analytics.

Flexible data transformation to align telemetry with Microsoft Sentinel ASIM schemas

The platform also provides schema drift detection and source health monitoring, helping teams maintain reliable telemetry pipelines as environments evolve.

Closing

Effective security operations depend on how quickly a SOC can onboard new data, scale effectively, and maintain high‑quality investigations. Sentinel provides a cloud‑native, AI-ready foundation to ingest security data from first- and third‑party data sources—while enabling economical, large‑scale retention and deep analytics using open data formats and multiple analytics engines. DataBahn’s partnership with Sentinel is positioned as a pipeline layer that can help teams onboard third-party sources, shape and normalize data, and apply routing and governance patterns before data lands in Sentinel.

Learn more

DataBahn for Microsoft Sentinel

DataBahn Press Release - Databahn Deepens Partnership with Microsoft Sentinel

Microsoft Sentinel data lake overview - Microsoft Security | Microsoft Learn

Microsoft Sentinel—AI-Ready Platform | Microsoft Security

Connect Microsoft Sentinel to the Microsoft Defender portal - Unified security operations | Microsoft Learn

Microsoft Sentinel data lake is now generally available | Microsoft Community Hub

What’s New in Microsoft Sentinel: March 2026

NogaRonen — Wed, 04 Mar 2026 20:21:05 GMT

March brings a set of updates to Microsoft Sentinel focused on helping your SOC automate faster, onboard data with less friction, and detect threats across more of your environment.

This month's updates include natural-language playbook generation for more flexible SOAR workflows, streamlined real-time data ingestion with CCF Push, and expanded Kubernetes visibility with a dedicated GKE connector. Together, these innovations help security teams simplify operations, move faster, and strengthen coverage without added complexity. And if you're heading to RSAC 2026, check out how to join us for Microsoft Pre-Day below.

What’s new

Microsoft Sentinel playbook generator brings natural-language automation to SOC workflows

The Microsoft Sentinel playbook generator lets you design and generate fully functional, code-based playbooks by describing what you need in natural language. Instead of relying on rigid templates and limited action libraries, you describe the workflow you want, and the generator produces a Python playbook with documentation and a visual flowchart. This has been a top ask from enterprise customers looking for more flexible automation in their SIEM workflows.

The playbook generator works across Microsoft and third-party tools. By defining an Integration Profile with a base URL, authentication method, and credentials, it can create dynamic API calls without predefined connectors. That means you can automate tasks like team notifications, ticket updates, data enrichment, or incident response across your environment, then validate playbooks against real alerts and refine through chat or manual edits. You keep full transparency into the generated code and full control to customize it.

Watch a demo and learn more.

CCF Push delivers seamless, real-time security data to Microsoft Sentinel (public preview)

The Codeless Connector Framework (CCF) Push feature allows you to send security data directly to a Sentinel workspace in real time. Instead of configuring Data Collection Endpoints (DCE), Data Collection Rules (DCR), Entra app registrations, and RBAC assignments, you press "Deploy" and Sentinel sets up all the resources for you.

Built on the Log Ingestion API, CCF Push supports high-throughput ingestion, data transformation before ingestion, and direct delivery to system tables to speed up SOC detection and response and to enable more flexible access to critical security telemetry. This opens pathways to advanced scenarios, including data lake integrations and agentic AI use cases.

Sentinel solution developers can begin leveraging CCF Push immediately. Partners like Keeper Security, Obsidian Security, and Varonis are already using CCF Push to stream security data into Sentinel. Learn more and check out the getting started guide.

Detect threats across GKE clusters in Microsoft Sentinel with a dedicated CCF connector (general availability)

A dedicated data connector for Google Kubernetes Engine (GKE) is available in the Microsoft Sentinel content hub, built on the Codeless Connector Framework (CCF). The connector ingests GKE cluster activity, workload behavior, and security events into the GKEAudit Log Analytics table, bringing GKE monitoring in line with how Azure Kubernetes Service (AKS) clusters are monitored in Sentinel today. It includes Data Collection Rule (DCR) support, data lake-only ingestion, and workspace transformation support so you can filter or modify incoming data before it reaches its destination.

For security teams running workloads on GKE, this means you can apply Sentinel analytics, workbooks, and hunting queries across your GKE signals alongside the rest of your environment, giving you consistent visibility into Kubernetes threats whether your clusters run on Azure or Google Cloud. Get the GKE data connector

Solve hybrid identity challenges with an RSA agent on Microsoft Sentinel data lake and Security Copilot

RSA has built an agentic solution that combines RSA ID Plus telemetry with Microsoft Sentinel's data lake and Security Copilot agents. The integration ingests administrative identity telemetry from RSA ID Plus into the Sentinel data lake for cost-effective, long-term retention, then uses Security Copilot agents to assess that data and surface anomalous or risky admin behavior automatically.

For security teams managing complex hybrid identity environments, this means identity risk signals from RSA are analyzed alongside your broader Sentinel telemetry without manual correlation. Admin accounts remain one of the highest-value targets for attackers, and having agentic AI continuously assessing identity patterns helps your SOC detect compromised credentials earlier and reduce investigation time. Learn more

Join Microsoft Security at RSAC 2026 Pre-Day

If you are heading to RSAC™ 2026 in San Francisco, join Microsoft Security for Pre-Day on Sunday, March 22 at the Palace Hotel. Hear from Vasu Jakkal, CVP of Microsoft Security Business, and other Microsoft Security leaders on how AI and autonomous agents are reshaping defense strategy. Product leaders will share what they are focused on for security operations, threat intelligence experts will discuss emerging trends, and Microsoft researchers will highlight the newest areas of security R&D.

Evaluate your SIEM platform for the agentic era with our strategic buyer's guide

Our buyer’s guide from Microsoft Security helps security leaders evaluate what a modern SIEM platform should deliver. The Strategic SIEM Buyer's Guide walks through three essentials: building a unified foundation that is future-proof, accelerating detection and response with AI, and maximizing ROI with faster time to value. Whether you are assessing migration from a legacy on-premises SIEM or benchmarking your current platform, the guide offers practical buyer's tips and capability checklists grounded in real outcomes, including how organizations using Sentinel have achieved a 44% reduction in total cost of ownership and 93% faster deployment times. Learn more

Additional resources

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!

Top 5 Microsoft Sentinel Queries for Threat Hunting

SonjaEd — Fri, 27 Feb 2026 16:00:00 GMT

Threat hunting in Microsoft Sentinel goes beyond relying on scheduled analytics rules. It’s about proactively asking better questions of your data to uncover stealthy or emerging attacker behavior before it turns into an incident. Effective hunting helps security teams spot activity that may never trigger an alert but still represents meaningful risk. Over time, these proactive hunts strengthen overall detection coverage and improve SOC maturity.

In this post, I’ll walk through five high‑value Sentinel hunting queries that security teams can use to uncover suspicious activity across identity, endpoints, and cloud resources. Each example focuses on why the hunt matters and what attacker behavior it can reveal. To make these hunts actionable and measurable, each query is explicitly mapped to MITRE ATT&CK tactics and techniques. This alignment helps teams communicate coverage, prioritize investigations, and evolve successful hunts into repeatable detections.

1. Rare Sign‑In Locations for Privileged Accounts

Why it matters

Privileged identities are prime targets. A successful sign‑in from an unusual geography may indicate compromised credentials or token theft.

What to hunt

Look for successful sign‑ins by privileged users from locations they rarely use.

// MITRE ATT&CK: T1078 (Valid Accounts), T1078.004 (Cloud Accounts) | Tactic: Initial Access SigninLogs | where ResultType == 0 | where UserPrincipalName has_any ("admin", "svc") | summarize count() by UserPrincipalName, Location | join kind=leftanti ( SigninLogs | where TimeGenerated < ago(30d) | summarize count() by UserPrincipalName, Location ) on UserPrincipalName, Location

What to investigate next

Conditional Access policies applied
MFA enforcement status
Correlation with device compliance or impossible travel alerts

2. Multiple Failed Logons Followed by Success

Why it matters

This pattern often indicates password spraying, brute force activity, or attackers testing credential validity before gaining access.

What to hunt

// MITRE ATT&CK: T1110 (Brute Force), T1110.003 (Password Spraying), T1110.001 (Password Guessing) | Tactic: Credential Access // Related: T1078 (Valid Accounts) once authentication succeeds SigninLogs | summarize Failed=countif(ResultType != 0), Success=countif(ResultType == 0) by UserPrincipalName, bin(TimeGenerated, 1h) | where Failed > 5 and Success > 0

What to investigate next

IP reputation and ASN
Whether failures span multiple users (spray behavior)
Subsequent mailbox, SharePoint, or Azure activity

3. Unusual Process Execution on Endpoints

Why it matters

Attackers often use “living off the land” binaries (LOLBins) such as powershell.exe, wmic.exe, or rundll32.exe to evade detection.

What to hunt

// MITRE ATT&CK: T1059 (Command and Scripting Interpreter), // T1059.001 (PowerShell), T1059.003 (Windows Command Shell) | Tactic: Execution // Related: T1218 (Signed Binary Proxy Execution) when rundll32 and other signed binaries are abused DeviceProcessEvents | where FileName in~ ("powershell.exe", "wmic.exe", "rundll32.exe") | where InitiatingProcessFileName !in~ ("explorer.exe", "services.exe") | project TimeGenerated, DeviceName, FileName, ProcessCommandLine, InitiatingProcessFileName, InitiatingProcessCommandLine

What to investigate next

Encoded or obfuscated command lines
Parent process legitimacy
User context and device risk score

4. Newly Created or Modified Service Principals

Why it matters

Service principals are often abused for persistence or privilege escalation in Azure environments.

What to hunt

// MITRE ATT&CK: T1098 (Account Manipulation), T1098.001 (Additional Cloud Credentials) | Tactic: Persistence AuditLogs | where OperationName in ("Add service principal", "Update service principal") | project TimeGenerated, InitiatedBy, TargetResources, OperationName

What to investigate next

Assigned API permissions or directory roles
Token usage after creation
Correlation with unfamiliar IP addresses

5. Rare Azure Resource Access Patterns

Why it matters

Attackers exploring your environment often access subscriptions or resource groups they’ve never touched before.

What to hunt

// MITRE ATT&CK: T1526 (Cloud Service Discovery), T1069.003 (Permission Groups Discovery: Cloud) | Tactic: Discovery AzureActivity | summarize count() by Caller, ResourceGroup | join kind=leftanti ( AzureActivity | where TimeGenerated < ago(30d) | summarize count() by Caller, ResourceGroup ) on Caller, ResourceGroup

What to investigate next

Role assignments for the caller
Whether access aligns with job function
Any subsequent configuration changes

Summary Table

This table summarizes each Sentinel threat hunting query and maps it directly to the corresponding MITRE ATT&CK tactic and technique. By aligning hunts to ATT&CK, security teams can clearly communicate what adversary behaviors are being proactively investigated and identify gaps in coverage. This mapping also makes it easier to prioritize hunts, measure maturity, and transition high‑value hunts into analytics rules over time.

Sentinel Hunt	MITRE Tactic	MITRE Technique
Rare privileged sign‑ins	Initial Access	T1078 – Valid Accounts
Failed then successful logons	Credential Access	T1110 – Brute Force
LOLBin execution	Execution	T1059 / T1218
Service principal changes	Persistence	T1098.001
Rare resource access	Discovery	T1526 / T1069.003

Final Thoughts

Threat hunting in Microsoft Sentinel is most effective when it’s continuous, hypothesis‑driven, and contextual. These queries are starting points, not finished detections. Tune them based on your environment, enrich them with UEBA insights, and align your hunts to MITRE ATT&CK techniques, as outlined in your existing Sentinel content strategy.

If you consistently run hunts like these, you’ll catch suspicious behavior before it triggers an alert or before an attacker reaches their objective.

Unlocking value with Microsoft Sentinel data lake

atennant — Thu, 26 Feb 2026 22:28:54 GMT

As security telemetry explodes and AI‑driven defense becomes the norm, it is critical to centralize and retain massive volumes of data for deep analysis and long‑term insights. Security teams are fundamentally rethinking how they manage, analyze, and act on security data.

The Microsoft Sentinel data lake is a game changer for modern security operations, providing the foundation for agentic defense, deeper insights, and graph‑based enrichment. Security teams can centralize signals, simplify data management, and run advanced analytics, without compromising costs or performance.

Across industries, organizations are using the Sentinel data lake to unify distributed data, search across years of telemetry, correlate sophisticated threats using graph-powered analytics, and operationalize agentic workflows at scale, turning raw security data into actionable intelligence. In this blog we will highlight some of the ways Sentinel data lake is transforming modern security operations.

Unified, cost-effective security data foundation

The challenge

Many organizations tell us they have been forced to make difficult tradeoffs: high ingestion costs meant selectively choosing which logs to keep, often leaving data that might have been critical during an investigation. This selective logging creates blind spots, fragmented visibility, and unnecessary operational complexity across security operations. As a result, CISOs increasingly view selective logging as a material security risk to their organizations.

How Sentinel data lake helps

The Sentinel data lake removes these constraints by providing a cost‑effective, security‑optimized foundation for centralizing large volumes of security data. With the data lake, security teams can finally retain the breadth of telemetry they need without the financial penalties traditionally associated with long‑term security data retention.

Organizations benefit from:

A unified security data foundation designed to simplify investigations
Long‑term, cost‑effective retention for up to 12 years
Flexible querying across high‑volume data sets
6x data compression in storage, enabling significantly lower retention costs at scale

Why it matters

By unifying data in a purpose-built security data lake, SOC teams gain reliable, comprehensive visibility without the budget limitations that once forced them to choose between cost and completeness. This stronger foundation not only improves day‑to‑day investigations; it unlocks the advanced analytics and AI‑powered capabilities that future proof SOCs for AI driven defense. With full visibility restored, organizations are better equipped to identify emerging threats, respond with confidence, and modernize their security operations on their own terms.

Historical security analysis

The challenge

SOC teams often struggle with short SIEM retention windows that limit how far back investigators can look. Critical logs age out before teams can fully piece together an attack, making root‑cause analysis slow and incomplete. This challenge grows when incidents span long periods, when new threat indicators emerge, or when organizations need to understand how a compromise evolved over time. Without access to historical telemetry, analysts face significant blind spots that weaken both investigations and hunting efforts.

How Sentinel data lake helps

The Sentinel data lake solves this by enabling organizations to retain and analyze years of security data at a fraction of the cost of traditional SIEM retention. Teams can use KQL and notebooks to run deep, long‑range investigations, perform advanced anomaly detection, and correlate older events that would have been impossible to recover in the analytics tier. Historical data enables retro analysis when new threat intel emerges. SOC teams can instantly look back to validate whether newly discovered indicators, techniques, or threat actors were already present in their environment.

Organizations benefit from:

Years of cost‑effective retention that extend far beyond traditional SIEM windows
Deep forensic investigations using KQL and notebooks over historical data
Improved anomaly detection with long‑range patterns and baselines
Faster scoping of incidents with access to full historical context

Why it matters

By unlocking access to years of searchable telemetry, SOC teams are no longer limited by short retention windows or forced to make compromises that weaken security. They can retrace the full scope of an incident, hunt for slow‑moving threats, and quickly respond to new IOCs, powered by the historical context modern attacks demand. This long‑range visibility strengthens both detection and response, giving organizations the confidence and continuity they need to stay ahead of evolving threats.

Graph-powered attack-path visibility and entity correlation

The challenge

Traditional investigations often rely on reviewing logs in isolation, making it difficult to connect identity activity, endpoint behavior, cloud access, and threat intelligence in a meaningful way. As a result, SOC teams find it difficult to trace attack paths, understand lateral movement, and build complete investigative context. Without a unified view of how entities relate to each other, investigations become slow, fragmented, and are prone to missed signals.

How Sentinel data lake helps

The Sentinel data lake enables powerful graph‑based correlation across identity, asset, activity, and threat intelligence data. Using graph models, analysts can visually explore how entities connect, identify hidden attack paths, pinpoint exposed routes to sensitive assets, and understand the full blast radius of compromised accounts or devices. This graph‑driven context turns complex telemetry into intuitive visuals that dramatically accelerate both pre‑breach context and incident response.

Organizations benefit from:

Graph‑powered correlation across identity, asset, activity, and threat intelligence data
Visualization of attack paths and lateral movement that logs alone cannot expose
Context‑rich investigations supported by relationship‑driven insights
Greater cross‑domain visibility that strengthens both detection and response

Why it matters

With graph‑powered context, SOC teams move beyond event‑by‑event analysis and gain a deep understanding of how their environment behaves as a system. This visibility speeds investigations, strengthens posture before attackers strike, and provides analysts with a clear, intuitive way to uncover relationships that traditional log searches simply can’t reveal.

Agentic workflows powered by MCP server

The challenge

SOC teams are under constant pressure from rising alert volumes, repetitive manual investigative steps, and skill gaps that make consistent triage challenging. Even experienced analysts struggle to reason across large, distributed datasets, and junior analysts often lack the experience needed to understand complex threat scenarios. These challenges slow down response and increase the risk of missed signals.

How the Sentinel data lake helps

The Sentinel data lake, combined with the Model Context Protocol (MCP), enables AI agents to reason over unified, contextual security data using natural‑language prompts. Analysts can ask questions directly: “Does this user have other suspicious activity?” or “What assets are at risk?”, and agents automatically interpret the request, query the data lake, and return actionable insights. These AI‑powered workflows reduce repetitive effort, strengthen investigative consistency, and help teams operate at a higher level of speed and precision.

Organizations benefit from:

AI‑assisted investigations that reduce manual effort and accelerate triage
Agentic workflows powered by MCP to automate multi‑step reasoning over unified data
Natural‑language interactions that make complex queries accessible to all analysts
Consistent, high‑quality analysis regardless of analyst experience level

Why it matters

By introducing agentic, AI‑driven workflows, SOC teams can automate time‑consuming tasks, reduce alert fatigue, and empower every analyst, regardless of seniority, to quickly arrive at high‑quality insights. This shift not only accelerates investigations but also frees teams to focus on high‑value, proactive security work. As organizations continue modernizing their SOC, agentic workflows represent a major step forward in bridging the gap between human expertise and scalable, AI‑powered analysis.

The future of security operations starts here

The Sentinel data lake is becoming the backbone of modern security operations—unifying security data, expanding investigative reach, and enabling graph‑driven, AI‑powered analysis at scale. By centralizing telemetry on a cost‑effective, AI‑ready foundation, and running advanced analytics on that data, security teams can move beyond fragmented insights to correlate threats with clarity and act faster with confidence.

These four use cases are just the beginning. Whether you’re strengthening investigations, advancing threat hunting, operationalizing AI, or preparing your SOC for what’s next, the Sentinel data lake provides the scale, intelligence, and flexibility to reduce complexity and stay ahead of evolving threats. Now is the time to accelerate toward a more resilient, adaptive, and future‑ready security posture.

Get started with Microsoft Sentinel data lake today