Unlocking value with Microsoft Sentinel data lake
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 todayUpdate: Changing the Account Name Entity Mapping in Microsoft Sentinel
The upcoming update introduces more consistent and predictable entity data across analytics, incidents, and automation by standardizing how the Account Name property is populated when using UPN‑based mappings in analytic rules. Going forward, Account Name property will consistently contain only the UPN prefix, with new dedicated fields added for the full UPN and UPN suffix. While this improves consistency and enables more granular automation, customers who rely on specific Account Name values in automation rules or Logic App playbooks may need to take action. Timeline Effective date: July 1, 2026. The change will apply automatically - no opt-in is required. Scope of impact Analytics Rules which include mapping of User Principal Name (UPN) to the Account Name entity field, where the resulting alerts are processed by Automation Rules or Logic App Playbooks that reference the AccountName property. What’s changing Currently When an Analytic Rule includes mapping of a full UPN (for example: 'user@domain.com') to the Account Name field, the resulting input value for the Automation Rule or/and Logic App Playbook is inconsistent. In some cases, it contains only the UPN prefix: 'user', and in other cases the full UPN ('user@domain.com'). After July 1, 2026 Account Name property will consistently contain only the UPN prefix The following new fields will be added to the entity object: AccountName (UPN prefix) UPNSuffix UserPrincipalName (full UPN) This change provides an enhanced filtering and automation logic based on these new fields. Example Before Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' or 'user@domain.com' (inconsistent) After Analytics Rule maps: 'user@domain.com' Automation Rule receives: Account Name: 'user' UPNSuffix: 'domain.com' Logic App Playbook and SecurityAlert table receives: AccountName: 'user' UPNSuffix: 'domain.com' UserPrincipalName: 'user@domain.com' Feature / Location Before After SecurityAlert table Logic App Playbook Entity Why does it matter? If your automation logic relies on exact string comparisons against the full UPN stored in Account Name, those conditions may no longer match after the update. This most commonly affects: Automation Rules using "Equals" condition on Account Name Logic App Playbooks comparing entity field 'accountName' to a full UPN value Call to action Avoid strict equality checks against Account Name Use flexible operators such as: Contains Starts with Leverage the new UPNSuffix field for clearer intent Example update Before - Account name will show as 'user' or 'user@domain.com' After - Account Name will show as 'user' Recommended changes: Account Name Contains/Startswith 'user' UPNSuffix Equals/Startswith/Contains 'domain.com' This approach ensures compatibility both before and after the change takes effect. Where to update Review any filters, conditions, or branching logic that depend on Account Name values. Automation Rules: Use the 'Account name' field Logic App Playbooks: Update conditions referencing the entity: 'accountName' For example: Automation Rule before the change: Automation Rule after the change: Summary A consistency improvement to Account Name mapping is coming on July 1, 2026 The change affects Automation Rules and Logic App Playbooks that rely on UPN to Account Name mappings New UPN related fields provide better structure and control Customers should follow the recommendations above before the effective change dateWhat’s new in Microsoft Sentinel: February 2026
February brings a set of new innovations to Sentinel that helps you work with security content across your SOC. This month’s updates focus on how security teams ingest, manage, and operationalize content, with new connectors, multi-tenant content distribution capabilities, and an enhanced UEBA Essentials solution to surface high‑risk behavior faster across cloud and identity environments. We’re also introducing new partner-built agentic experiences available through Microsoft Security Store, enabling customers to extend Sentinel with specialized expertise directly inside their existing workflows. Together, these innovations help SOC teams move faster, scale smarter, and unlock deeper security insight without added complexity. Expand your visibility and capabilities with Sentinel content Seamlessly onboard security data with growing out-of-the-box connectors (general availability) Sentinel continues to expand its connector ecosystem, making it easier for security teams to bring together data from across cloud, SaaS, and on-premises‑premises environments so nothing critical slips through the cracks. With broader coverage and faster onboarding, SOCs can unlock unified visibility, stronger analytics, and deeper context across their entire security stack. Customers can now use out-of-the-box connectors and solutions for: o Mimecast Audit Logs o CrowdStrike Falcon Endpoint Protection o Vectra XDR o Palo Alto Networks Cloud NGFW o SocPrime o Proofpoint on Demand (POD) Email Security o Pathlock o MongoDB o Contrast ADR For the full list of connectors, see our documentation. Share your input on what to prioritize next with our App Assure team. Microsoft 365 Copilot data connector (public preview) The Microsoft 365 Copilot connector brings Microsoft 365 Copilot audit logs and activity data into Sentinel, giving security teams visibility into how Microsoft 365 Copilot is being used across their organization. Once ingested, this data can power analytics rules, custom detections, workbooks, automation, and investigations, helping SOC teams quickly spot anomalies, misuse, and policy violations. Customers can also send this data to the Sentinel data lake for advanced scenarios, such as custom graphs and MCP integrations, while benefiting from lower cost ingestion and flexible retention. Learn more here. Transition your Sentinel connectors to the codeless connector framework (CCF) Microsoft is modernizing data connectors by shifting from Azure Function based connectors to the codeless connector framework (CCF). CCF enables partners, customers, and developers to build custom connectors that ingest data into Sentinel with a fully SaaS managed experience, built-in health monitoring, centralized credential management, and enhanced performance. We recommend that customers review their deployed connectors and move to the latest CCF versions to ensure uninterrupted data collection and continued access to the latest Sentinel capabilities. As part of Azure’s modernization of custom data collection, the legacy custom data collection API will be retired in September 2026. Centrally manage and distribute Sentinel content across multiple tenants (public preview) For partners and SOCs managing multiple Sentinel tenants, you can centrally manage and distribute Sentinel content across multiple tenants from the Microsoft Defender portal. With multi-tenant content distribution, you can replicate analytics rules, automation rules, workbooks, and alert tuning rules across tenants instead of rebuilding the same detections, automation, and dashboards in one environment at a time. This helps you onboard new tenants faster, reduce configuration drift, and maintain a consistent security baseline while still keeping local execution in each target tenant under centralized control. Learn more: New content types supported in multi-tenant content distribution Find high-risk anomalous behavior faster with an enhanced UEBA essentials solution (public preview) UEBA Essentials solution now helps SOC teams uncover high‑risk anomalous behavior faster across Azure, AWS, GCP, and Okta. With expanded multi-cloud anomaly detection and new queries powered by the anomalies table, analysts can quickly surface the riskiest activity, establish reliable behavioral baselines, and understand anomalies in context without chasing noisy or disconnected signals. UEBA Essentials aligns activity to MITRE ATT&CK, highlights complex malicious IP patterns, and builds a comprehensive anomaly profile for users in seconds, reducing investigation time while improving signal quality across identity and cloud environments. UEBA Essentials is available directly from the Sentinel content hub, with 30+ prebuilt UEBA queries ready to deploy. Behavior analytics can be enabled automatically from the connectors page as new data sources are added, making it easy to turn deeper insight into immediate action. For more information, see: UEBA Solution Power Boost: Practical Tools for Anomaly Detection Extend Sentinel with partner-built Security Copilot agents in Microsoft Security Store (general availability) You can extend Sentinel with partner-built Security Copilot agents that are discoverable and deployable through Microsoft Security Store in the Defender experience. These AI-powered agents are created by trusted partners specifically to work with Sentinel to deliver packaged expertise for investigation, triage, and response without requiring you to build your own agentic workflows from scratch. These partner-built agents work with Sentinel analytics and incidents to help SOC teams triage faster, investigate deeper, and surface insights that would otherwise take hours of manual effort. For example, these agents can review Sentinel and Defender environments, map attacker activity, or automate forensic analysis and SOC reporting. BlueVoyant’s Watchtower agent helps optimize Sentinel and Defender configurations, AdaQuest’s Data Leak agent accelerates response by surfacing risky data exposure and identity misuse, and Glueckkanja’s Attack Mapping agent automatically maps fragmented entities and attacker behavior into a coherent investigation story. Together, these agents show how the Security Store turns partner innovation into enterprise-ready, Security Copilot-powered capabilities that you can use in your existing SOC workflows. Browse these and more partner-built Security Copilot agents in the Security Store within the Defender portal. At Ignite, we announced the native integration of Security Store within the Defender portal. Read more about the GA announcement here: Microsoft Security Store: Now Generally Available Explore Sentinel experience Enhanced reports in the Threat Intelligence Briefing Agent (general availability) The Threat Intelligence Briefing Agent now applies a structured knowledge graph to Microsoft Defender for Threat Intelligence, enabling it to surface fresher, more relevant threats tailored to a customer’s specific industry and region. Building on this foundation, the agent also features embedded, high‑fidelity Microsoft Threat Intelligence citations, providing authoritative context directly within each insight. With these advancements, security teams gain clearer, more actionable guidance and mitigation steps through context‑rich insights aligned to their environment, helping them focus on what matters most and respond more confidently to emerging threats. Learn more: Microsoft Security Copilot Threat Intelligence Briefing Agent in Microsoft Defender Microsoft Purview Data Security Investigations (DSI) integrated with Sentinel graph (general availability) Sentinel now brings together data‑centric and threat‑centric insights to help teams understand risk faster and respond with more confidence. By combining AI‑powered deep content analysis from Microsoft Purview with activity‑centric graph analytics in Sentinel, security teams can identify sensitive or risky data, see how it was accessed, moved, or exposed, and take action from a single experience. This gives SOC and data security teams a full, contextual view of the potential blast radius, connecting what happened to the data with who accessed it and how, so investigations are faster, clearer, and more actionable. Start using the Microsoft Purview Data Security Investigations (DSI) integration with the Sentinel graph to give your analysts richer context and streamline end‑to‑end data risk investigations. Deadline to migrate the Sentinel experience from Azure to Defender extended to March 2027 To reduce friction and support customers of all sizes, we are extending the sunset date for managing Sentinel in the Azure portal to March 31, 2027. This additional time ensures customers can transition confidently while taking advantage of new capabilities that are becoming available in the Defender portal. Learn more about this decision, why you should start planning your move today, and find helpful resources here: UPDATE: New timeline for transitioning Sentinel experience to Defender portal Events and webinars Stay connected with the latest security innovations and best practices through global conferences and expert‑led sessions that bring the community together to learn, connect, and explore how Microsoft is delivering AI‑driven, end‑to‑end security for the modern enterprise. Join us at RSAC, March 23–26, 2026 at the Moscone Center in San Francisco Register for RSAC and stop by the Microsoft booth to see our latest security innovations in action. Learn how Sentinel SIEM and platform help organizations stay ahead of threats, simplify operations, and protect what matters most. Register today! Microsoft Security Webinars Discover upcoming sessions on Sentinel SIEM & platform, Defender, and more. Sign up today and be part of the conversation that shapes security for everyone. Learn more about upcoming webinars. Additional resources Blogs: UPDATE: New timeline for transitioning Sentinel experience to Defender portal, Accelerate your move to Microsoft Sentinel with AI-powered SIEM migration tool, Automating Microsoft Sentinel: A blog series on enabling Smart Security, The Agentic SOC Era: How Sentinel MCP Enables Autonomous Security Reasoning Documentation: What Is a Security Graph? , SIEM migration tool, Onboarding to Microsoft Sentinel data lake from the Defender portal 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 for SAP Agentless connector GA
Dear Community, Today is the day: Our new agentless connector for Microsoft Sentinel Solution for SAP applications is Generally Available now! Fully onboarded to SAP’s official Business Accelerator Hub and ready for prime time wherever your SAP systems are waiting – on-premises, hyperscalers, RISE, or GROW – to be protected. Let’s hear from an agentless customer: “With the Microsoft Sentinel Solution for SAP and its new agentless connector, we accelerated deployment across our SAP landscape without the complexity of containerized agents. This streamlined approach elevated our SOC’s visibility into SAP security events, strengthened our compliance posture, and enabled faster, more informed incident response” SOC Specialist, North American aviation company Use the video below to kick off your own agentless deployment today. #Kudos to the amazing mvigilante for showing us around the new connector! But we didn’t stop there! Security is being reengineered for the AI era - moving from static, rule-based controls to platform-driven, machine-speed defence that anticipates threats before they strike. Attackers think in graphs - Microsoft does too. We’re bringing relationship-aware context to Microsoft Security - so defenders and AI can see connections, understand the impact of a potential compromise (blast radius), and act faster across pre-breach and post-breach scenarios including SAP systems - your crown jewels. See it in action in below phishing-compromise which lead to an SAP login bypassing MFA with followed operating-system activities on the SAP host downloading trojan software. Enjoy this clickable experience for more details on the scenario. Shows how a phishing compromise escalated to an SAP MFA bypass, highlighting cross-domain correlation. The Sentinel Solution for SAP has AI-first in mind and directly integrates with our security platform on the Defender portal for enterprise-wide signal correlation, Security Copilot reasoning, and Sentinel Data Lake usage. Your real-time SAP detections operate on the Analytics tier for instant results and threat hunting, while the same SAP logs get mirrored to the lake for cost-efficient long-term storage (up to 12 years). Access that data for compliance reporting or historic analysis through KQL jobs on the lake. No more – yeah, I have the data stored somewhere to tick the audit report check box – but be able to query and use your SAP telemetry in long term storage at scale. Learn more here. Findings from the Agentless Connector preview During our preview we learned that majority of customers immediately profit from the far smoother onboarding experience compared to the Docker-based approach. Deployment efforts and time to first SAP log arrival in Sentinel went from days and weeks to hours. ⚠️ Deprecation notice for containerized data connector agent ⚠️ The containerised SAP data connector will be deprecated on September 14th, 2026. This change aligns with the discontinuation of the SAP RFC SDK, SAP's strategic integration roadmap, and customer demand for simpler integration. Migrate to the new agentless connector for simplified onboarding and compliance with SAP’s roadmap. All new deployments starting October 31, 2025, will only have the new agentless connector option, and existing customers should plan their migration using the guidance on Microsoft Learn. It will be billed at the same price as the containerized agent, ensuring no cost impact for customers. Note📌: To support transition for those of you on the Docker-based data connector, we have enhanced our built-in KQL functions for SAP to work across data sources for hybrid and parallel execution. Spotlight on new Features Inspired by the feedback of early adopters we are shipping two of the most requested new capabilities with GA right away. Customizable polling frequency: Balance threat detection value (1min intervals best value) with utilization of SAP Integration Suite resources based on your needs. ⚠️Warning! Increasing the intervals may result in message processing truncation to avoid SAP CPI saturation. See this blog for more insights. Refer to the max-rows parameter and SAP documentation to make informed decisions. Customizable API endpoint path suffix: Flexible endpoints allow running all your SAP security integration flows from the agentless connector and adherence to your naming strategies. Furthermore, you can add the community extensions like SAP S/4HANA Cloud public edition (GROW), the SAP Table Reader, and more. Displays the simplified onboarding flow for the agentless SAP connector You want more? Here is your chance to share additional feature requests to influence our backlog. We would like to hear from you! Getting Started with Agentless The new agentless connector automatically appears in your environment – make sure to upgrade to the latest version 3.4.05 or higher. Sentinel Content Hub View: Highlights the agentless SAP connector tile in Microsoft Defender portal, ready for one-click deployment and integration with your security platform The deployment experience on Sentinel is fully automatic with a single button click: It creates the Azure Data Collection Endpoint (DCE), Data Collection Rule (DCR), and Microsoft Entra ID app registration assigned with RBAC role "Monitoring Metrics Publisher" on the DCR to allow SAP log ingest. Explore partner add-ons that build on top of agentless The ISV partner ecosystem for the Microsoft Sentinel Solution for SAP is growing to tailor the agentless offering even further. The current cohort has flagship providers like our co-engineering partner SAP SE themselves with their security products SAP LogServ & SAP Enterprise Threat Detection (ETD), and our mutual partners Onapsis and SecurityBridge. Ready to go agentless? ➤ Get started from here ➤ Explore partner add-ons here. ➤ Share feature requests here. Next Steps Once deployed, I recommend to check AryaG’s insightful blog series for details on how to move to production with the built-in SAP content of agentless. Looking to expand protection to SAP Business Technology Platform? Here you go. #Kudos to the amazing Sentinel for SAP team and our incredible community contributors! That's a wrap 🎬. Remember: bringing SAP under the protection of your central SIEM isn't just a checkbox - it's essential for comprehensive security and compliance across your entire IT estate. Cheers, MartinAutomating Microsoft Sentinel: Part 2: Automate the mundane away
Welcome to the second entry of our blog series on automating Microsoft Sentinel. In this series, we’re showing you how to automate various aspects of Microsoft Sentinel, from simple automation of Sentinel Alerts and Incidents to more complicated response scenarios with multiple moving parts. So far, we’ve covered Part 1: Introduction to Automating Microsoft Sentinel where we talked about why you would want to automate as well as an overview of the different types of automation you can do in Sentinel. Here is a preview of what you can expect in the upcoming posts [we’ll be updating this post with links to new posts as they happen]: Part 1: Introduction to Automating Microsoft Sentinel Part 2: Automation Rules [You are here] – Automate the mundane away Part 3: Playbooks 1 – Playbooks Part I – Fundamentals Part 4: Playbooks 2 – Playbooks Part II – Diving Deeper Part 5: Azure Functions / Custom Code Part 6: Capstone Project (Art of the Possible) – Putting it all together Part 2: Automation Rules – Automate the mundane away Automation rules can be used to automate Sentinel itself. For example, let’s say there is a group of machines that have been classified as business critical and if there is an alert related to those machines, then the incident needs to be assigned to a Tier 3 response team and the severity of the alert needs to be raised to at least “high”. Using an automation rule, you can take one analytic rule, apply it to the entire enterprise, but then have an automation rule that only applies to those business-critical systems to make those changes. That way only the items that need that immediate escalation receive it, quickly and efficiently. Automation Rules In Depth So, now that we know what Automation Rules are, let’s dive in to them a bit deeper to better understand how to configure them and how they work. Creating Automation Rules There are three main places where we can create an Automation Rule: 1) Navigating to Automation under the left menu 2) In an existing Incident via the “Actions” button 3) When writing an Analytic Rule, under the “Automated response” tab The process for each is generally the same, except for the Incident route and we’ll break that down more in a bit. When we create an Automation Rule, we need to give the rule a name. It should be descriptive and indicative of what the rule is going to do and what conditions it applies to. For example, a rule that automatically resolves an incident based on a known false positive condition on a server named SRV02021 could be titled “Automatically Close Incident When Affected Machine is SRV02021” but really it’s up to you to decide what you want to name your rules. Trigger The next thing we need to define for our Automation Rule is the Trigger. Triggers are what cause the automation rule to begin running. They can fire when an incident is created or updated, or when an alert is created. Of the two options (incident based or alert based), it’s preferred to use incident triggers as they’re potentially the aggregation of multiple alerts and the odds are that you’re going to want to take the same automation steps for all of the alerts since they’re all related. It’s better to reserve alert-based triggers for scenarios where an analytic rule is firing an alert, but is set to not create an incident. Conditions Conditions are, well, the conditions to which this rule applies. There are two conditions that are always present: The Incident provider and the Analytic rule name. You can choose multiple criterion and steps. For example, you could have it apply to all incident providers and all rules (as shown in the picture above) or only a specific provider and all rules, or not apply to a particular provider, etc. etc. You can also add additional Conditions that will either include or exclude the rule from running. When you create a new condition, you can build it out by multiple properties ranging from information about the Incident all the way to information about the Entities that are tagged in the incident Remember our earlier Automation Rule title where we said this was a false positive about a server name SRV02021? This is where we make the rule match that title by setting the Condition to only fire this automation if the Entity has a host name of “SRV2021” By combining AND and OR group clauses with the built in conditional filters, you can make the rule as specific as you need it to be. You might be thinking to yourself that it seems like while there is a lot of power in creating these conditions, it might be a bit onerous to create them for each condition. Recall earlier where I said the process for the three ways of creating Automation Rules was generally the same except using the Incident Action route? Well, that route will pre-fill variables for that selected instance. For example, for the image below, the rule automatically took the rule name, the rules it applies to as well as the entities that were mapped in the incident. You can add, remove, or modify any of the variables that the process auto-maps. NOTE: In the new Unified Security Operations Platform (Defender XDR + Sentinel) that has some new best practice guidance: If you've created an automation using "Title" use "Analytic rule name" instead. The Title value could change with Defender's Correlation engine. The option for "incident provider" has been removed and replaced by "Alert product names" to filter based on the alert provider. Actions Now that we’ve tuned our Automation Rule to only fire for the situations we want, we can now set up what actions we want the rule to execute. Clicking the “Actions” drop down list will show you the options you can choose When you select an option, the user interface will change to map to your selected option. For example, if I choose to change the status of the Incident, the UX will update to show me a drop down menu with options about which status I would like to set. If I choose other options (Run playbook, change severity, assign owner, add tags, add task) the UX will change to reflect my option. You can assign multiple actions within one Automation Rule by clicking the “Add action” button and selecting the next action you want the system to take. For example, you might want to assign an Incident to a particular user or group, change its severity to “High” and then set the status to Active. Notably, when you create an Automation rule from an Incident, Sentinel automatically sets a default action to Change Status. It sets the automation up to set the Status to “Closed” and a “Benign Positive – Suspicious by expected”. This default action can be deleted and you can then set up your own action. In a future episode of this blog we’re going to be talking about Playbooks in detail, but for now just know that this is the place where you can assign a Playbook to your Automation Rules. There is one other option in the Actions menu that I wanted to specifically talk about in this blog post though: Incident Tasks Incident Tasks Like most cybersecurity teams, you probably have a run book of the different tasks or steps that your analysts and responders should take for different situations. By using Incident Tasks, you can now embed those runbook steps directly in the Incident. Incident tasks can be as lightweight or as detailed as you need them to be and can include rich formatting, links to external content, images, etc. When an incident with Tasks is generated, the SOC team will see these tasks attached as part of the Incident and can then take the defined actions and check off that they’ve been completed. Rule Lifetime and Order There is one last section of Automation rules that we need to define before we can start automating the mundane away: when should the rule expire and in what order should the rule run compared to other rules. When you create a rule in the standalone automation UX, the default is for the rule to expire at an indefinite date and time in the future, e.g. forever. You can change the expiration date and time to any date and time in the future. If you are creating the automation rule from an Incident, Sentinel will automatically assume that this rule should have an expiration date and time and sets it automatically to 24 hours in the future. Just as with the default action when created from an incident, you can change the date and time of expiration to any datetime in the future, or set it to “Indefinite” by deleting the date. Conclusion In this blog post, we talked about Automation Rules in Sentinel and how you can use them to automate mundane tasks in Sentinel as well as leverage them to help your SOC analysts be more effective and consistent in their day-to-day with capabilities like Incident Tasks. Stay tuned for more updates and tips on automating Microsoft Sentinel!What’s new in Microsoft Sentinel: January 2026
Welcome back! As we kick off the new year, we’re bringing key Ignite 2025 announcements into your day‑to‑day Sentinel experience so you can turn insights into measurable SecOps outcomes with the AI-ready Sentinel SIEM and platform. Building on last year’s momentum around AI-ready platforms, agentic defense, data lake innovation, and advanced SIEM capabilities, the January edition delivers security features designed to elevate your operations. This release brings powerful enhancements, including streamlined ingestion of Microsoft Defender data into the Sentinel data lake, deeper partner connector integrations, QRadar migration support, enriched UEBA insights, and a refreshed ASIM schema for consistent normalization. Together, these advancements help security teams simplify operations, strengthen detection, and unlock greater value from their data. What’s new Ingest Defender data directly into Sentinel data lake At Ignite 2025, Microsoft announced that Defender for Endpoint (MDE) data could be ingested directly into the Sentinel data lake. Building on this, we now support direct ingestion of Microsoft Defender for Office (MDO) and Microsoft Defender for Cloud Apps (MDA) data as well. You can choose to ingest supported XDR tables exclusively into the data lake tier by selecting the data lake tier option when configuring the retention settings. Table settings are easily managed through the built-in table management experience in the Defender portal, enabling cost-effective, long-term data retention without moving data to the analytics tier. This expansion delivers improved visibility, deeper historical analysis, reduced total cost of ownership, and empowers modern security operations with advanced capabilities. Growing connector ecosystem At Ignite 2025, Microsoft unveiled new connectors and integrations that seamlessly unify signals across multi-cloud and multiplatform environments. These innovations deliver enhanced visibility and scalable security insights across cloud, endpoint, and identity platforms. To explore the complete list of new solutions from Microsoft Sentinel and our third-party partners see – Ignite 2025: New Microsoft Sentinel Connectors Announcement. Accelerate your migration from QRadar to Microsoft Sentinel Microsoft is excited to announce support for QRadar-to-Microsoft Sentinel migrations through the enhanced, AI-powered SIEM migration experience. This new capability simplifies and streamlines the process by helping organizations efficiently migrate detection rules and enable required data connectors in Sentinel’s cloud-native SIEM. As a result, customers gain improved visibility, accelerated threat detection, and more modern security operations powered by Microsoft’s intelligent cloud. Early adopters are seeing smoother transitions with minimal disruption, more predictable outcomes, and greater value from their SIEM investment. In addition, Microsoft provides free migration support through the Cloud Accelerate Factory program. Eligible customers receive expert guidance to quickly deploy Sentinel and migrate from Splunk and QRadar using the new SIEM migration experience, in collaboration with their preferred migration partner. For details, contact your Microsoft representative or visit: https://aka.ms/FactoryCustomerPortal To learn more, tune in to our webinar on February 2, 2025, at 9:00AM PST: https://aka.ms/SecurityCommunity Announcing the Behaviors Layer within UEBA Now in public preview! Microsoft Sentinel’s Behaviors layer is a new UEBA capability that provides a high-level behavioral lens on top of raw security telemetry. Its goal is to answer the question “What happened? Who did what to whom?” in your environment by aggregating, sequencing, and enriching events into human-readable behaviors. Each “behavior” is a synthesized security event or pattern that describes an action (or sequence of actions) an entity performed. This includes rich context such as involved entities, MITRE ATT&CK tactics/techniques, and a plain-English description. Learn more here: Turn Complexity into Clarity: Introducing the New UEBA Behaviors Layer in Microsoft Sentinel Unified schema alignment for ASIM Following our Advanced Security Information Model (ASIM) reaching General Availability in September, this latest refresh delivers comprehensive alignment across all ASIM schemas to the latest ASIM standard. This update ensures: Consistent field coverage across all major activity types. A stable baseline for accelerating parser development, normalization improvements, and future ASIM-driven experiences. Key additions across older schemas: Inspection fields – enabling normalization of security findings across all activity types. Risk fields – providing consistent representation of source-reported risk. Full details are available here: Advanced Security Information Model (ASIM) schemas Additional resources Blogs: What’s new in Microsoft Sentinel: December 2025, Automating IOC hunts in Microsoft Sentinel data lake, Efficiently process high volume logs and optimize costs with Microsoft Sentinel data lake Documentation: Microsoft Sentinel data lake overview - Microsoft Security | Microsoft Learn, Use the SIEM migration experience - Microsoft Sentinel | Microsoft Learn Sign up for upcoming webinars: Feb. 2 | 9:00am | Accelerate your SIEM migration to Microsoft Sentinel 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!Microsoft Sentinel Platform: Audit Logs and Where to Find Them
Looking to understand where audit activities for Sentinel Platform are surfaced? Look no further than this writeup! With the launch of the Sentinel Platform, a new suite of features for the Microsoft Sentinel service, users may find themselves wanting to monitor who is using these new features and how. This blog sets out to highlight how auditing and monitoring can be achieved and where this data can be found. *Thank you to my teammates Ian Parramore and David Hoerster for reviewing and contributing to this blog.* What are Audit Logs? Audit logs are documented activities that are eligible for usage within SOC tools, such as a SIEM. These logs are meant to exist as a paper trail to show: Who performed an action What type of action was performed When the action was performed Where the action was performed How the action was performed Audit logs can be generated by many platforms, whether they are Microsoft services or platforms outside of the Microsoft ecosystem. Each source is a great option for a SOC to monitor. Types of Audit Logs Audit logs can vary in how they are classified or where they are placed. Focusing just on Microsoft, the logs can vary based on platform. A few examples are: - Windows: Events generated by the operating system that are available in EventViewer - Azure – Diagnostic logs generated by services that can be sent to Azure Log Analytics - Defender – Audit logs generated by Defender services that are sent to M365 Audit Logs What is the CloudAppEvents Table? The CloudAppEvents table is a data table that is provided via Advanced Hunting in Defender. This table contains events of applications being used within the environment. This table is also a destination for Microsoft audit logs that are being sent to Purview. Purview’s audit log blade includes logs from platforms like M365, Defender, and now Sentinel Platform. How to Check if the Purview Unified Audit Logging is Enabled For CloudAppEvents to receive data, Audit Logging within Purview must be enabled and M365 needs to be configured to be connected as a Defender for Cloud Apps component. Enabling Audit Logs By default, Purview Auditing is enabled by default within environments. In the event that they have been disabled, Audit logs can be enabled and checked via PowerShell. To do so, the user must have the Audit Logs role within Exchange Online. The command to run is: Get-AdminAuditLogConfig | Format-List UnifiedAuditLogIngestionEnabled The result will either be true if auditing is already turned on, and false if it is disabled. If the result is false, the setting will need to be enabled. To do so: Install the Exchange Online module with: Import-Module ExchangeOnlineManagement Connect and authenticate to Exchange Online with an interactive window Connect-ExchangeOnline -UserPrincipalName USER PRINCIPAL NAME HERE Run the command to enable auditing Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true Note: It may take 60 minutes for the change to take effect. Connecting M365 to MDA To connect M365 to MDA as a connector: Within the Defender portal, go to System > Settings. Within Settings, choose Cloud Apps. Within the settings navigation, go to Connected apps > App Connectors. If Microsoft 365 is not already listed, click Connect an app. Find and select Microsoft 365. Within the settings, select the boxes for Microsoft 365 activities. Once set, click on the Connect Microsoft 365 button. Note: You have to have a proper license that includes Microsoft Defender for Cloud Apps in order to have these settings for app connections. Monitoring Activities As laid out within the public documentation, there are several categories of audit logs for Sentinel platform, including: Onboarding/offboarding KQL activities Job activities Notebook activities AI tool activities Graph activities All of these events are surfaced within the Purview audit viewer and CloudAppEvents table. When querying the table, each of the activities will appear under a column called ActionType. Onboarding Friendly Name Operation Description Changed subscription of Sentinel lake SentinelLakeSubscriptionChanged User modified the billing subscription ID or resource group associated with the data lake. Onboarded data for Sentinel lake SentinelLakeDefaultDataOnboarded During onboarding, default data onboard is logged. Setup Sentinel lake SentinelLakeSetup At the time of onboarding, Sentinel data lake is set up and the details are logged. For querying these activities, one example would be: CloudAppEvents | where ActionType == ‘SentinelLakeDefaultDataOnboarded’ | project AccountDisplayName, Application, Timestamp, ActionType KQL Queries There is only one type of activity for KQL available. These logs function similarly to how LAQueryLogs work today, showing details like who ran the query, if it was successful, and what the body of the query was. Friendly Name Operation Description Completed KQL query KQLQueryCompleted User runs interactive queries via KQL on data in their Microsoft Sentinel data lake For querying these activities, one example would be: CloudAppEvents | where ActionType == ‘KQLQueryCompleted’ | project Timestamp, AccountDisplayName, Application, RawEventData.Interface, RawEventData.QueryText, RawEventData.TotalRows Jobs Jobs pertain to KQL jobs and Notebook jobs offered by the Sentinel Platform. These logs will detail job activities as well as actions taken against jobs. This will be useful for monitoring who is creating or modifying jobs, as well as monitoring that jobs are properly running. Friendly Name Operation Description Completed a job run adhoc JobRunAdhocCompleted Adhoc Job execution completed. Completed a job run scheduled JobRunScheduledCompleted Scheduled Job execution completed. Created job JobCreated A job is created. Deleted a custom table CustomTableDelete As part of a job run, the custom table was deleted. Deleted job JobDeleted A job is deleted. Disabled job JobDisabled The job is disabled. Enabled job JobEnabled A disabled job is reenabled. Ran a job adhoc JobRunAdhoc Job is triggered manually and run started. Ran a job on schedule JobRunScheduled Job run is triggered due to schedule. Read from table TableRead As part of the job run, a table is read. Stopped a job run JobRunStopped User manually cancels or stops an ongoing job run. Updated job JobUpdated The job definition and/or configuration and schedule details of the job if updated. Writing to a custom table CustomTableWrite As part of the job run, data was written to a custom table. For querying these activities, one example would be: CloudAppEvents | where ActionType == ‘JobCreated’ | project Timestamp, AccountDisplayName, Application, ActionType, RawEventData.JobName, RawEventData.JobType, RawEventData.Interface AI Tools AI tool logs pertain to events being generated by MCP server usage. This is generated any time that users operate with MCP server and leverage one of the tools available today to run prompts and sessions. Friendly Name Operation Description Completed AI tool run SentinelAIToolRunCompleted Sentinel AI tool run completed Created AI tool SentinelAIToolCreated User creates a Sentinel AI tool Started AI tool run SentinelAIToolRunStarted Sentinel AI tool run started For querying these activities, the query would be: CloudAppEvents | where ActionType == ‘SentinelAIToolRunStarted’ | project Timestamp, AccountDisplayName, ActionType, Application, RawEventData.Interface, RawEventData.ToolName Notebooks Notebook activities pertain to actions performed by users via Notebooks. This can include querying data via a Notebook, writing to a table via Notebooks, or launching new Notebook sessions. Friendly Name Operation Description Deleted a custom table CustomTableDelete User deleted a table as part of their notebook execution. Read from table TableRead User read a table as part of their notebook execution. Started session SessionStarted User started a notebook session. Stopped session SessionStopped User stopped a notebook session. Wrote to a custom table CustomTableWrite User wrote to a table as part of their notebook execution. For querying these activities, one example would be: CloudAppEvents | where ActionType == ‘TableRead’ Graph Usage Graph activities pertain to users modifying or running a graph based scenario within the environment. This can include creating a new graph scenario, deleting one, or running a scenario. Created a graph scenario GraphScenarioCreated User created a graph instance for a pre-defined graph scenario. Deleted a graph scenario GraphScenarioDeleted User deleted or disable a graph instance for a pre-defined graph scenario. Ran a graph query GraphQueryRun User ran a graph query. For querying these activities, one example would be: CloudAppEvents | where ActionType == 'GraphQueryRun' | project AccountDisplayName, IsExternalUser, IsImpersonated, RawEventData.['GraphName'], RawEventData.['CreationTime'] Monitoring without Access to the CloudAppSecurity Table If accessing the CloudAppSecurity table is not possible in the environment, both Defender and Purview allow for manually searching for activities within the environment. For Purview (https://purview.microsoft.com), the audit page can be found by going to the Audit blade within the Purview portal. For Defender, the audit blade can be found under Permissions > Audit To run a search that will match Sentinel Platform related activities, the easiest method is using the Activities – friendly names field to filter for Sentinel Platform. Custom Ingestion of Audit Logs If looking to ingest the data into a table, a custom connector can be used to fetch the information. The Purview Audit Logs use the Office Management API when calling events programmatically. This leverages registered applications with proper permissions to poll the API and forward the data into a data collection rule. As the Office Management API does not support filtering entirely within the content URI, making a custom connector for this source is a bit more tricky. For a custom connector to work, it will need to: Call the API Review each content URL Filter for events that are related to Sentinel Platform This leaves two options for accomplishing a custom connector route: A code-based connector that is hosted within an Azure Function A codeless connector paired with a filtering data collection rule This blog will just focus on the codeless connector as an example. A codeless connector can be made from scratch or by referencing an existing connector within the Microsoft Sentinel GitHub repository. For the connector, an example API call would appear as such: https://manage.office.com/api/v1.0/{tenant-id}/activity/feed/subscriptions/content?contentType=Audit.General&startTime={startTime}&endTime={endTime} When using a registered application, it will need ActivityFeed.Read read permissions on the Office Management API for it to be able to call the API and view the information returned. The catch with the Management API is that it uses a content URL in the API response, thus requiring one more step. Luckily, Codeless Connectors support nested actions and JSON. An example of a connector that does this today is the Salesforce connector. When looking to filter the events to be specifically the Sentinel Platform audit logs, the queries listed above can be used in the body of a data collection rule. For example: "streams": [ "Custom-PurviewAudit" ], "destinations": [ "logAnalyticsWorkspace" ], "transformKql": "source | where ActionType has_any (‘GraphQueryRun’, ‘TableRead’… etc) "outputStream": "Custom-SentinelPlatformAuditLogs” Note that putting all of the audit logs may lead to a schema mismatch depending on how they are being parsed. If concerned about this, consider placing each event into different tables, such as SentinelLakeQueries, KQLJobActions, etc. This can all be defined within the data collection rule, though the custom tables for each action will need to exist before defining them within the data collection rule. Closing Now that audit logs are flowing, actions taken by users within the environment can be used for detections, hunting, Workbooks, and automation. Since the logs are being ingested via a data collection rule, they can also be sent to Microsoft Sentinel data lake if desired. May this blog lead to some creativity and stronger monitoring of the Sentinel Platform!Ignite 2025: New Microsoft Sentinel Connectors Announcement
Microsoft Sentinel continues to set the pace for innovation in cloud-native SIEMs, empowering security teams to meet today’s challenges with scalable analytics, built-in AI, and a cost-effective data lake. Recognized as a leader by Gartner and Forrester, Microsoft Sentinel is a platform for all of security, evolving to unify signals, cut costs, and power agentic AI for the modern SOC. As Microsoft Sentinel’s capabilities expand, so does its connector ecosystem. With over 350+ integrations available, organizations can seamlessly bring data from a wide range of sources into Microsoft Sentinel’s analytics and data lake tiers. This momentum is driven by our partners, who continue to deliver new and enhanced connectors that address real customer needs. The past year has seen rapid growth in both the number and diversity of connectors, ensuring that Microsoft Sentinel remains robust, flexible, and ready to meet the demands of any security environment. Today we showcase some of the most recent additions to our growing Microsoft Sentinel ecosystem spanning categories such as cloud security, endpoint protection, identity, IT operations, threat intelligence, compliance, and more: New and notable integrations BlinkOps and Microsoft Sentinel BlinkOps is an enterprise-ready agentic security automation platform that integrates seamlessly with Microsoft Sentinel to accelerate incident response and streamline operations. With Blink, analysts can rapidly build sophisticated workflows and custom security agents—without writing a single line of code—enabling agile, scalable automation with both Microsoft Sentinel and any other security platform. This integration helps eliminate alert fatigue, reduce mean time to resolution (MTTR), and free teams to focus on what matters most: driving faster operations, staying ahead of cyber threats, and unlocking new levels of efficiency through reliable, trusted orchestration. Check Point for Microsoft Sentinel solutions Check Point’s External Risk Management (ERM) IOC and Alerts integration with Microsoft Sentinel streamlines how organizations detect and respond to external threats by automatically sending both alerts and indicators of compromise (IOCs) into Microsoft Sentinel. Through this integration, customers can configure SOAR playbooks to trigger automated actions such as updating security policies, blocking malicious traffic, and executing other security operations tasks. This orchestration reduces manual effort, accelerates response times, and allows IT teams, network administrators, and security personnel to focus on strategic threat analysis—strengthening the organization’s overall security posture. Cloudflare for Microsoft Sentinel Cloudflare’s integration with Microsoft Sentinel, powered by Logpush, brings detailed security telemetry from its Zero Trust and network services into your SIEM environment. By forwarding logs such as DNS queries, HTTP requests, and access events through Logpush, the connector enables SOC teams to correlate Cloudflare data with other sources for comprehensive threat detection. This integration supports automated workflows for alerting and investigation, helping organizations strengthen visibility across web traffic and identity-based access while reducing manual overhead. Contrast ADR for Microsoft Sentinel Contrast Security gives Microsoft Sentinel users their first-ever integration with Application Detection and Response (ADR), delivering real-time visibility into application and API attacks, eliminating the application-layer blind spot. By embedding security directly into applications, Contrast enables continuous monitoring and precise blocking of attacks, and with AI assistance, the ability to fix underlying software vulnerabilities in minutes. This integration helps security teams prioritize actionable insights, reduce noise, and better understand the severity of threats targeting APIs and web apps. GreyNoise Enterprise Solution for Microsoft Sentinel GreyNoise helps Microsoft Sentinel users cut through the noise by identifying and filtering out internet background traffic that clutters security alerts. Drawing from a global sensor network, GreyNoise classifies IP addresses that are scanning the internet, allowing SOC teams to deprioritize benign activity and focus on real threats. The integration supports automated triage, threat hunting, and enrichment workflows, giving analysts the context they need to investigate faster and more effectively. iboss Connector for Microsoft Sentinel The iboss Connector for Microsoft Sentinel delivers real-time ingestion of URL event logs, enriching your SIEM with high-fidelity web traffic insights. Logs are forwarded in Common Event Format (CEF) over Syslog, enabling streamlined integration without the need for a proxy. With built-in parser functions and custom workbooks, the solution supports rapid threat detection and investigation. This integration is especially valuable for organizations adopting Zero Trust principles, offering granular visibility into user access patterns and helping analysts accelerate response workflows. Mimecast Mimecast’s integration with Microsoft Sentinel consolidates email security telemetry into a unified threat detection environment. By streaming data from Mimecast into Microsoft Sentinel’s Log Analytics workspace, security teams can craft custom queries, automate response workflows, and prioritize high-risk events. This connector supports a wide range of use cases, from phishing detection to compliance monitoring, while helping reduce mean time to respond (MTTR). MongoDB Atlas Solution for Microsoft Sentinel MongoDB Atlas integrates with Microsoft Sentinel to provide visibility into database activity and security events across cloud environments. By forwarding database logs into Sentinel, this connector enables SOC teams to monitor access patterns, detect anomalies, and correlate database alerts with broader security signals. The integration allows for custom queries and dashboards to be built on real-time log data, helping organizations strengthen data security, streamline investigations, and maintain compliance for critical workloads. Onapsis Defend Onapsis Defend integrates with Microsoft Sentinel Solution for SAP to deliver real-time security monitoring and threat detection from both cloud and on-premises SAP systems. By forwarding Onapsis's unique SAP exploit detection, proprietary SAP zero-day rules, and expert SAP-focused insights into Microsoft Sentinel, this integration enables SOC teams to correlate SAP-specific risks with enterprise-wide telemetry and accelerate incident response. The integration supports prebuilt analytics rules and dashboards, helping organizations detect suspicious behavior and malicious activity, prioritize remediation, and strengthen compliance across complex SAP application landscapes. Proofpoint on Demand (POD) Email Security for Microsoft Sentinel Proofpoint’s Core Email Protection integrates with Microsoft Sentinel to deliver granular email security telemetry for advanced threat analysis. By forwarding events such as phishing attempts, malware detections, and policy violations into Microsoft Sentinel, SOC teams can correlate Proofpoint data with other sources for a unified view of risk. The connector supports custom queries, dashboards, and automated playbooks, enabling faster investigations and streamlined remediation workflows. This integration helps organizations strengthen email defenses and improve response efficiency across complex attack surfaces. Proofpoint TAP Solution Proofpoint’s Targeted Attack Protection (TAP), part of its Core Email Protection, integrates with Microsoft Sentinel to centralize email security telemetry for advanced threat detection and response. By streaming logs and events from Proofpoint into Microsoft Sentinel, SOC teams gain visibility into phishing attempts, malicious attachments, and compromised accounts. The connector supports custom queries, dashboards, and automated playbooks, enabling faster investigations and streamlined remediation workflows. This integration helps organizations strengthen email defenses while reducing manual effort across incident response processes. RSA ID Plus Admin Log Connector The RSA ID Plus Admin Log Connector integrates with Microsoft Sentinel to provide centralized visibility into administrative activity within RSA ID Plus Connector. By streaming admin-level logs into Sentinel, SOC teams can monitor changes, track authentication-related operations, and correlate identity events with broader security signals. The connector supports custom queries and dashboards, enabling organizations to strengthen oversight and streamline investigations across their hybrid environments. Rubrik Integrations with Microsoft Sentinel for Ransomware Protection Rubrik’s integration with Microsoft Sentinel strengthens ransomware resilience by combining data security with real-time threat detection. The connector streams anomaly alerts, such as suspicious deletions, modifications, encryptions, or downloads, directly into Microsoft Sentinel, enabling fast investigations and more informed responses. With built-in automation, security teams can trigger recovery workflows from within Microsoft Sentinel, restoring clean backups or isolating affected systems. The integration bridges IT and SecOps, helping organizations minimize downtime and maintain business continuity when facing data-centric threats. Samsung Knox Asset Intelligence for Microsoft Sentinel Samsung’s Knox Asset Intelligence integration with Microsoft Sentinel equips security teams with near real-time visibility into mobile device threats across Samsung Galaxy enterprise fleets. By streaming security events and logs from managed Samsung devices into Microsoft Sentinel via the Azure Monitor Log Ingestion API, organizations can monitor risk posture, detect anomalies, and investigate incidents from a centralized dashboard. This solution is especially valuable for SOC teams monitoring endpoints for large mobile workforces, offering data-driven insights to reduce blind spots and strengthen endpoint security without disrupting device performance. SAP S/4HANA Public Cloud – Microsoft Sentinel SAP S/4HANA Cloud, public edition integrates with Microsoft Sentinel Solution for SAP to deliver unified, real-time security monitoring for cloud ERP environments. This connector leverages Microsoft’s native SAP integration capabilities to stream SAP logs into Microsoft Sentinel, enabling SOC teams to correlate SAP-specific events with enterprise-wide telemetry for faster, more accurate threat detection and response. SAP Enterprise Threat Detection – Microsoft Sentinel SAP Enterprise Threat Detection integrates with Microsoft Sentinel Solution for SAP to deliver unified, real-time security monitoring across SAP landscapes and the broader enterprise. Normalized SAP logs, alerts, and investigation reports flow into Microsoft Sentinel, enabling SOC teams to correlate SAP-specific alerts with enterprise telemetry for faster, more accurate threat detection and response. SecurityBridge: SAP Data to Microsoft Sentinel SecurityBridge extends Microsoft Sentinel for SAP’s reach into SAP environments, offering real-time monitoring and threat detection across both cloud and on-premises SAP systems. By funneling normalized SAP security events into Microsoft Sentinel, this integration enables SOC teams to correlate SAP-specific risks with broader enterprise telemetry. With support for S/4HANA, SAP BTP, and NetWeaver-based applications, SecurityBridge simplifies SAP security auditing and provides prebuilt dashboards and templates to accelerate investigations. Tanium Microsoft Sentinel Connector Tanium’s integration with Microsoft Sentinel bridges real-time endpoint intelligence and SIEM analytics, offering a unified approach to threat detection and response. By streaming real-time telemetry and alerts into Microsoft Sentinel,Tanium enables security teams to monitor endpoint health, investigate incidents, and trigger automated remediation, all from a single console. The connector supports prebuilt workbooks and playbooks, helping organizations reduce dwell time and align IT and security operations around a shared source of truth. Team Cymru Pure Signal Scout for Microsoft Sentinel Team Cymru’s Pure Signal™ Scout integration with Microsoft Sentinel delivers high-fidelity threat intelligence drawn from global internet telemetry. By enriching Microsoft Sentinel alerts with real-time context on IPs, domains, and adversary infrastructure, Scout enables security teams to proactively monitor third-party compromise, track threat actor infrastructure, and reduce false positives. The integration supports external threat hunting and attribution, enabling analysts to discover command-and-control activity, signals of data exfiltration and compromise with greater precision. For organizations seeking to build preemptive defenses by elevating threat visibility beyond their borders, Scout offers a lens into the broader threat landscape at internet scale. Veeam App for Microsoft Sentinel The Veeam App for Microsoft Sentinel enhances data protection by streaming backup and recovery telemetry into your SIEM environment. The solution provides visibility into backup job status, anomalies, and potential ransomware indicators, enabling SOC teams to correlate these events with broader security signals. With support for custom queries and automated playbooks, this integration helps organizations accelerate investigations, trigger recovery workflows, and maintain resilience against data-centric threats. WithSecure Elements via Function for Microsoft Sentinel WithSecure’s Elements platform integrates with Microsoft Sentinel to provide centralized visibility into endpoint protection and detection events. By streaming incident and malware telemetry into Microsoft Sentinel, organizations can correlate endpoint data with broader security signals for faster, more informed responses. The solution supports a proactive approach to cybersecurity, combining predictive, preventive, and responsive capabilities, making it well-suited for teams seeking speed and flexibility without sacrificing depth. This integration helps reduce complexity while enhancing situational awareness across hybrid environments, and for companies to prevent or minimize any disruption. In addition to these solutions from our third-party partners, we are also excited to announce the following connectors published by the Microsoft Sentinel team, available now in Azure Marketplace and Microsoft Sentinel content hub. Alibaba Cloud Action Trail Logs AWS: Network Firewall AWS: Route 53 DNS AWS: Security Hub Findings AWS: Server Access Cisco Secure Endpoint GCP: Apigee GCP: CDN GCP: Cloud Monitor GCP: Cloud Run GCP: DNS GCP: Google Kubernetes Engine (GKE) GCP: NAT GCP: Resource Manager GCP: SQL GCP: VPC Flow GCP: IAM OneLogin IAM Oracle Cloud Infrastructure Palo Alto: Cortex Xpanse CCF Palo Alto: Prisma Cloud CWPP Ping One Qualys Vulnerability Management Salesforce Service Cloud Slack Audit Snowflake App Assure: The Microsoft Sentinel promise Every connector in the Microsoft Sentinel ecosystem is built to work out of the box, backed by the App Assure team and the Microsoft Sentinel promise. In the unlikely event that customers encounter any issues, App Assure stands ready to assist to ensure rapid resolution. With the new Microsoft Sentinel data lake features, we extend our promise for customers looking to bring their data to the lake. To request a new connector or features for an existing one, contact 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 What’s New in Microsoft Sentinel Microsoft App Assure App Assure home page App Assure services App Assure blog App Assure’s promise: Migrate to Sentinel with confidence App Assure’s Sentinel promise now extends to Microsoft Sentinel data lake RSAC 2025 new Microsoft Sentinel connectors announcement Microsoft Security Microsoft’s Secure Future Initiative Microsoft Unified SecOpsCall to Action: Migrate Your Classic Alert‑trigger Automations to Automation Rules Before March 2026
Reminder: Following the Retirement Announcement published in March 2023, classic alert‑trigger automation in Microsoft Sentinel, where playbooks are triggered directly from analytic rules will be deprecated in March 2026. To ensure your alert‑driven automations continue to run without interruption, please migrate to automation rules. How to Identify the Impacted Rules To help you quickly identify if any analytic rules should be updated, we created a Logic App solution that identifies all the analytic rules which use classic automation. The solution is available in two deployment options: Subscription-level version – scans all workspaces in the subscription Workspace-level version – scans a single workspace (useful when subscription Owner permissions are not available) Both options create an output of a list of analytic rules which need to be updated as described in the next section. The solution is published as part of Sentinel's GitHub community solutions with deployment instructions and further details: sentinel-classic-automation-detection After deploying and running the tool, open the Logic App run history. The final action contains the list of the analytic rules which require migration. How to Migrate the identified Analytic Rules from Classic Alert‑trigger Automations Once you have identified the analytic rules using classic automation, follow the official Microsoft Learn guidance to migrate them to automation rules: migrate-playbooks-to-automation-rules In short: Identify classic automation in your analytic rules Create automation rules to replace the classic automation To complete the migration, remove the Alert Automation Classic Actions identified in step #1 by clicking on the three dots and 'Remove' Summary Classic automation will retire in March 2026 Use the detection tool to identify any remaining classic alert-trigger playbooks Follow the official Microsoft documentation to complete the required changes Act now to ensure your SOC automations continue to run smoothly
