Merge pull request #309987 from limwainstein/alert-violations-clarification

prmerger-automator[bot] · web-flow · commit 803f17237f98 · 2026-01-21T15:21:10.000Z
Adding alert violations clarification
diff --git a/articles/defender-for-iot/organizations/alerts.md b/articles/defender-for-iot/organizations/alerts.md
@@ -34,30 +34,30 @@ While you can view alert details, investigate alert context, and triage and mana
 |**OT network sensor consoles**     |   Alerts generated by that OT sensor      |    - View the alert's source and destination in the **Device map** <br>- View related events on the **Event timeline**  <br>- Forward alerts directly to partner vendors  <br>- Create alert comments <br> - Create custom alert rules <br>- Unlearn alerts    |
 |**Microsoft 365 Defender**     |  Alerts generated for Enterprise IoT devices detected by Microsoft Defender for Endpoint         |  - Manage alerts data together with other Microsoft 365 Defender data, including advanced hunting |
 
-> [!TIP]
-> Any alerts generated from different sensors in the same zone within a 10-minute timeframe, with the same type, status, alert protocol, and associated devices, are listed as a single, unified alert.
->
-> - The 10-minute timeframe is based on the alert's *first detection* time. 
-> - The single, unified alert lists all of the sensors that detected the alert. 
-> - Alerts are combined based on the *alert* protocol, and not the device protocol.
->
-
-For more information, see:
-
-- [Alert data retention](references-data-retention.md#alert-data-retention)
-- [Accelerating OT alert workflows](#accelerating-ot-alert-workflows)
-- [Alert statuses and triaging options](alerts.md#alert-statuses-and-triaging-options)
-- [Plan OT sites and zones](best-practices/plan-corporate-monitoring.md#plan-ot-sites-and-zones)
-
-Alert options also differ depending on your location and user role. For more information, see [Azure user roles and permissions](roles-azure.md) and [On-premises users and roles](roles-on-premises.md).
+### Alert management considerations
+
+- Any alerts generated from different sensors in the same zone within a 10-minute timeframe, with the same type, status, alert protocol, and associated devices, are listed as a single, unified alert.
+    - The 10-minute timeframe is based on the alert's *first detection* time. 
+    - The single, unified alert lists all of the sensors that detected the alert. 
+    - Alerts are combined based on the *alert* protocol, and not the device protocol.
+    - For more information, see:
+        - [Alert data retention](references-data-retention.md#alert-data-retention)
+        - [Accelerating OT alert workflows](#accelerating-ot-alert-workflows)
+        - [Alert statuses and triaging options](alerts.md#alert-statuses-and-triaging-options)
+        - [Plan OT sites and zones](best-practices/plan-corporate-monitoring.md#plan-ot-sites-and-zones)
+- Alert options also differ depending on your location and user role. For more information, see [Azure user roles and permissions](roles-azure.md) and [On-premises users and roles](roles-on-premises.md).
+- When you view alerts in the alert list, some alerts may not correlate with alerts on specific sensors. For more information, see [Investigate alerts that don't correlate with specific sensors](respond-ot-alert.md#investigate-alerts-that-dont-correlate-with-a-specific-sensor).
 
 ## Aggregating alert violations
 
 Alert fatigue caused by a high number of identical alerts could lead to your team failing to see or remediate vital alerts. Each alert listed in the Alerts page is a result of a network violation, for example the *Unpermitted Usage of Modbus Function Code*. Aggregating violations with the same parameters and remediation requirements into one single alert listing, reduces the number of alerts displayed on the Alerts page. The matching parameters differ depending on the alert type. For example, the *Unpermitted Usage of Modbus Function Code* alert needs to have the same source and destination IP addresses to produce an aggregated alert violation. The aggregated alert could include alerts with different violation codes, such as read and write codes.
 
 You download the aggregated alert violation data, that lists each alert with the relevant parameters and functions, as a CSV file in the **Violations** tab of the alert details. This data can help teams to identify patterns, assess impact and prioritize responses more effectively based on the remediation suggestions in the **Take action** tab. Only alerts that have the same remediation process are aggregated into a single alert. However, individual violation events can still be viewed separately within their respective devices, providing additional clarity.
 
-The alerts that can be aggregated are listed in the [Alert reference](alert-engine-messages.md#policy-engine-alerts) policy engine alerts tables under the **Aggregarted** heading.
+> [!NOTE]
+> After you learn an alert (with the **Learn** option in the alert's **Take action** tab), the same alert might be triggered again. This can happen if the new alert has different violation parameters than the original alert. To check which violations exist for an alert: 
+> - In the Azure portal, in the alert's **Violations** tab, select **Export**. 
+> - In the OT sensor console, in the alert's **Violations** tab, select **Download CSV**.
 
 Alert grouping appears in both the OT sensor console and the Azure portal. For more information, see [remediate aggregated alerts in Sensor console](how-to-view-alerts.md#remediate-aggregated-alert-violations) and [remediate aggregated alerts in Azure portal](how-to-manage-cloud-alerts.md#remediate-aggregated-alert-violations).
 
@@ -149,6 +149,14 @@ Use learning mode to perform an initial triage on the alerts in your network, *l
 
 For more information, see [Create a learned baseline of OT alerts](ot-deploy/create-learned-baseline.md).
 
+## Alert investigation and remediation
+
+Alert investigation allows you to understand the context of the alert, including the sensor that triggered the alert, the source and destination devices, and related activity on your OT network.
+
+After you triage and investigate an alert, you can take remediation actions to resolve any issues identified during your investigation.
+
+For more information, see [Investigate and respond to an OT network alert](respond-ot-alert.md).
+
 ## Next steps
 
 Review alert types and messages to help you understand and plan remediation actions and playbook integrations. For more information, see [OT monitoring alert types and descriptions](alert-engine-messages.md).
diff --git a/articles/defender-for-iot/organizations/how-to-manage-cloud-alerts.md b/articles/defender-for-iot/organizations/how-to-manage-cloud-alerts.md
@@ -18,6 +18,9 @@ Microsoft Defender for IoT alerts enhance your network security and operations w
 
     For more information, see [Securing IoT devices in the enterprise](concept-enterprise.md) and the [Alerts queue in Microsoft Defender XDR](/microsoft-365/security/defender-endpoint/alerts-queue-endpoint-detection-response).
 
+> [!TIP]
+> You can use different areas in Defender for IoT to investigate alerts, and drill down into device and network details, violations, and more. For more information, see [Investigate and respond to and OT network alert](respond-ot-alert.md).
+
 ## Prerequisites
 
 - **To have alerts in Defender for IoT**, you must have an [OT](onboard-sensors.md) onboarded, and network data streaming into Defender for IoT.
@@ -61,8 +64,10 @@ For more information, see [Azure user roles and permissions for Defender for IoT
         | **Category**| The [category](alert-engine-messages.md#supported-alert-categories) associated with the alert, such as *operational issues*, *custom alerts*, or *illegal commands*. |
         | **Type**| The  internal name of the alert. |
 
-> [!TIP]
-> If you're seeing more alerts than expected, you might want to create suppression rules to prevent alerts from being triggered for legitimate network activity. For more information, see [Suppress irrelevant alerts](how-to-accelerate-alert-incident-response.md#suppress-irrelevant-alerts).
+### Considerations
+
+- If you're seeing more alerts than expected, you might want to create suppression rules to prevent alerts from being triggered for legitimate network activity. For more information, see [Suppress irrelevant alerts](how-to-accelerate-alert-incident-response.md#suppress-irrelevant-alerts).
+- When you view alerts in the alert list, some alerts may not correlate with alerts on specific sensors. For more information, see [Investigate alerts that don't correlate with specific sensors](respond-ot-alert.md#investigate-alerts-that-dont-correlate-with-a-specific-sensor).
 
 ### Filter alerts displayed
 
@@ -165,6 +170,9 @@ To reduce alert fatigue, multiple versions of the same alert violation with iden
 
 1. Select **Learn**, if needed. For more information, see [learning an alert](alerts.md#alert-statuses-and-triaging-options).
 
+> [!NOTE]
+> After you learn an alert, the same alert might be triggered again if the new alert has different violation parameters. To check why the alert was triggered, review the list of violations in the CSV file you downloaded in step 3.
+
 ## Next steps
 
 > [!div class="nextstepaction"]
diff --git a/articles/defender-for-iot/organizations/how-to-view-alerts.md b/articles/defender-for-iot/organizations/how-to-view-alerts.md
@@ -26,6 +26,9 @@ For more information, see [On-premises users and roles for OT monitoring with De
 
 ## View alerts on an OT sensor
 
+> [!NOTE]
+> When you view alerts in the Azure portal **Alerts** page, some alerts may not correlate with alerts on specific sensors. For more information, see [Investigate alerts that don't correlate with specific sensors](respond-ot-alert.md#investigate-alerts-that-dont-correlate-with-a-specific-sensor).
+
 1. Sign into your OT sensor console and select the **Alerts** page on the left.
 
     By default, the following details are shown in the grid:
@@ -196,6 +199,9 @@ To reduce alert fatigue, multiple versions of the same alert violation with iden
 
 1. Select **Learn**, if needed. For more information, see [learning an alert](alerts.md#alert-statuses-and-triaging-options).
 
+> [!NOTE]
+> An alert with specific violations does not prevent new alerts with different violations from appearing. After you learn an alert, the same alert might be triggered again if the new alert has different violation parameters. To check why the alert was triggered, review the list of violations in the alert list (for the first 10 alerts) or the CSV file you downloaded in step 3.
+
 ## Next steps
 
 > [!div class="nextstepaction"]
diff --git a/articles/defender-for-iot/organizations/respond-ot-alert.md b/articles/defender-for-iot/organizations/respond-ot-alert.md
@@ -45,7 +45,12 @@ After updating the status, check the alert details page for the following detail
 
 - **Source and destination device details**. Source and destination devices are listed in **Alert details** tab, and also in the **Entities** area below, as Microsoft Sentinel *entities*, with their own [entity pages](iot-advanced-threat-monitoring.md#investigate-further-with-iot-device-entities). In the **Entities** area, you'll use the links in the **Name** column to open the relevant device details pages for [further investigation](#investigate-related-alerts-on-the-azure-portal).
 
-- **Site and/or zone**. These values help you understand the geographic and network location of the alert and if there are areas of the network that are now more vulnerable to attack.
+- **Site and/or zone**. These values help you understand the geographic and network location of the alert and if there are areas of the network that are now more vulnerable to attack. 
+
+- **Sensor information**. Review the **Sensor**, **SiteDisplayName**, and other sensor information to provide context about the sensor that triggered the alert. 
+
+    > [!NOTE] 
+    > In some cases, the alerts displayed in the alert list might not correlate with specific sensors. For more information, see [Investigate alerts that don't correlate with specific sensors](#investigate-alerts-that-dont-correlate-with-a-specific-sensor).
 
 - **MITRE ATT&CK** tactics and techniques. Scroll down in the left pane to view all MITRE ATT&CK details. In addition to descriptions of the tactics and techniques, select the links to the MITRE ATT&CK site to learn more about each one.
 
@@ -67,6 +72,12 @@ For example, a device that attempted to connect to a malicious IP, together with
 
     :::image type="content" source="media/iot-solution/device-details-alerts.png" alt-text="Screenshot of the Alerts tab on a device details page.":::
 
+## Investigate alerts that don't correlate with a specific sensor
+
+In some cases, alerts in the Azure portal might not correlate with alerts on a specific sensor. The alert may be triggered by a specific sensor's configuration, like a device marked as a scanner in one sensor but not in another. As a result, alerts may only be displayed on the sensor that has the relevant configuration, even if other sensors also see the same traffic.
+
+In this scenario, you can check the **Sensor**, **SiteDisplayName**, and **SensorZone** fields in the alert's **Alert details** tab to identify the sensor that generated the alert. You can then review that sensor's configuration and context to understand why the alert was triggered.
+
 ## Investigate alert details on the OT sensor
 
 The OT sensor that triggered the alert will have more details to help your investigation.
