How to pull only the alerts type of event from Microsoft Entra ID

Question

How to pull only the alerts type of event from Microsoft Entra ID

Nisha Das 5

Hi Team,

We are currently evaluating options to pull only Microsoft Entra ID alerts into our SIEM platform and would appreciate guidance on the best approach.

At the moment, we are exploring different options such as Microsoft Graph APIs and Event Hub streaming, but we have some uncertainties around how alerts are sourced and filtered.

From our understanding, the Microsoft Graph API can retrieve alerts generated by services such as Microsoft Sentinel and Microsoft Defender. However, we are unsure whether Microsoft Entra ID alerts are also included through the same API endpoints.

Specifically, we would like clarification on the following:

Does the Microsoft Graph API include Microsoft Entra ID alerts along with alerts from Sentinel and Defender?

If Entra ID alerts are included, is there a way to filter the API response to retrieve only Entra ID alerts?

If filtering is not possible through the Graph API, would it be better to use Event Hub streaming to send only Entra ID alerts to our SIEM?

If Event Hub is the recommended approach, which diagnostic settings or alert categories should be configured to ensure that only Entra ID alerts are streamed?

Our goal is to ingest only Entra ID–related alerts into the SIEM to avoid unnecessary data ingestion while still receiving alerts in near real time.

Any recommendations on the best architecture or APIs/services to use for this scenario would be greatly appreciated.

Thank you.

1 answer

Your answer

Answer 1

Marcin Policht 82,355 MVP Volunteer Moderator

Yep - the Microsoft Graph Security API (/security/alerts_v2) does include Microsoft Entra ID alerts, such as those from Identity Protection, alongside alerts from Microsoft Defender for Endpoint, Office, and Cloud Apps, as it acts as a unified broker for Microsoft security products. The API provides a broad view, pulling in alerts from various connected Microsoft security providers into a single schema.

If Entra ID alerts are included, you can filter the API response to retrieve only specific alerts using the $filter query parameter on the vendorInformation/provider field (e.g., Azure Active Directory Identity Protection) or by checking specific alert titles. Using the v2 alert resource (alerts_v2) is generally recommended to ensure you receive the most recent alert data, since the legacy alert API is being deprecated.

If complex filtering is required that the Graph API cannot handle, or if you prefer a push mechanism, using Event Hub streaming would give you near-real-time approach to ingest only relevant alerts. This approach allows you to filter at the source by enabling only specific diagnostic settings, ensuring that only desired data is streamed rather than pulling everything via API.

When using Event Hub , you should configure the Diagnostic Settings in the Entra ID portal to select AuditLogs, SignInLogs, and NonInteractiveUserSignInLogs, and check the specific log categories that align with your required security alerts, such as IdentityProtectionEvents. For the most targeted data, you can create multiple diagnostic settings to send different log categories to different destinations, or use the Filter options to narrow down the data, allowing you to only stream alerts relevant to your SIEM.

For your requirement to minimize ingestion while receiving near real-time alerts, the best architecture is to configure Azure Event Hub streaming directly from Entra ID. This allows you to select only the necessary diagnostic logs (like Sign-in and Audit logs) and push them directly to your SIEM, which is often more efficient and less costly than polling the Graph API.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Nisha Das 5

Hi, thank you for your suggestion.

We explored the Graph API and found that alerts can be filtered using vendor information. In the API response, there is a field called serviceSource which appears to indicate the vendor, and we can use this field to filter alerts accordingly.

However, while exploring the Event Hub streaming option, we are a bit confused about how to identify alerts specifically coming from Identity Protection alerts.

Which field in the Event Hub log payload should we check to determine that an alert belongs to IdentityProtectionEvents? Below is a sample log we received. We would like to understand which field indicates that the alert originated from Identity Protection.

{
  "time": "2025-01-15T11:11:16.5204878Z",
  "resourceId": "/tenants/7d174b6e-ae92-4bbe-9b67-04b9e1523d76/providers/Microsoft.aadiam",
  "operationName": "Sign-in activity",
  "operationVersion": "1.0",
  "category": "SignInLogs",
  "tenantId": "7d174b6e-ae92-4bbe-9b67-04b9e1523d76",
  "resultType": "0",
  "resultSignature": "None",
  "durationMs": 0,
  "callerIpAddress": "2409:40c1:10fc:9acf:f84b:f459:2ffd:d59",
  "correlationId": "8a05b5f6-ca74-4093-90db-8d1198b6fa9b",
  "identity": "Parag Patwardhan",
  "Level": 4,
  "location": "IN",
  "properties": {
    "id": "565bde09-57a5-423f-a901-0dad99d40900",
    "createdDateTime": "2025-01-15T11:09:37.4839399+00:00",
    "userDisplayName": "Parag Patwardhan",
    "userPrincipalName": "******@metronsecurityqagw.onmicrosoft.com",
    "userId": "ee0ed37e-ba85-49f1-8531-d4ba437bf800",
    "appId": "7eadcef8-456d-4611-9480-4fff72b8b9e2",
    "appDisplayName": "Microsoft Account Controls V2",
    "ipAddress": "2409:40c1:10fc:9acf:f84b:f459:2ffd:d59",
    "status": {
      "errorCode": 0
    },
    "clientAppUsed": "Browser",
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36",
    "deviceDetail": {
      "deviceId": "",
      "operatingSystem": "MacOs",
      "browser": "Chrome 131.0.0"
    },
    "location": {
      "city": "Delhi",
      "state": "Delhi",
      "countryOrRegion": "IN",
      "geoCoordinates": {
        "latitude": 28.635299682617188,
        "longitude": 77.2249984741211
      }
    },
    "correlationId": "8a05b5f6-ca74-4093-90db-8d1198b6fa9b",
    "conditionalAccessStatus": "notApplied",
    "appliedConditionalAccessPolicies": [
      {
        "id": "813f02d7-2ce2-466e-970d-fc010826f812",
        "displayName": "dummy(testing)",
        "enforcedGrantControls": [
          "MfaAndChangePassword"
        ],
        "enforcedSessionControls": [
          "SignInFrequency"
        ],
        "result": "notApplied",
        "conditionsSatisfied": 1,
        "conditionsNotSatisfied": 2
      },
      {
        "id": "6a5c2588-8a26-42ad-b4d8-6aa66ce7e178",
        "displayName": "Require multifactor authentication for admins(testing)",
        "enforcedGrantControls": [
          "Mfa"
        ],
        "enforcedSessionControls": [],
        "result": "notApplied",
        "conditionsSatisfied": 1,
        "conditionsNotSatisfied": 2
      }
    ],
    "authenticationContextClassReferences": [],
    "originalRequestId": "565bde09-57a5-423f-a901-0dad99d40900",
    "isInteractive": true,
    "tokenIssuerName": "",
    "tokenIssuerType": "AzureAD",
    "authenticationProcessingDetails": [
      {
        "key": "Legacy TLS (TLS 1.0, 1.1, 3DES)",
        "value": "False"
      },
      {
        "key": "Is CAE Token",
        "value": "False"
      }
    ],
    "networkLocationDetails": [],
    "clientCredentialType": "none",
    "processingTimeInMilliseconds": 105,
    "riskDetail": "none",
    "riskLevelAggregated": "none",
    "riskLevelDuringSignIn": "none",
    "riskState": "none",
    "riskEventTypes": [],
    "riskEventTypes_v2": [],
    "resourceDisplayName": "Microsoft Graph",
    "resourceId": "00000003-0000-0000-c000-000000000000",
    "resourceTenantId": "7d174b6e-ae92-4bbe-9b67-04b9e1523d76",
    "homeTenantId": "7d174b6e-ae92-4bbe-9b67-04b9e1523d76",
    "tenantId": "7d174b6e-ae92-4bbe-9b67-04b9e1523d76",
    "authenticationDetails": [
      {
        "authenticationStepDateTime": "2025-01-15T11:09:37.4839399+00:00",
        "authenticationMethod": "Previously satisfied",
        "succeeded": true,
        "authenticationStepResultDetail": "First factor requirement satisfied by claim in the token",
        "authenticationStepRequirement": "Primary authentication",
        "StatusSequence": 0,
        "RequestSequence": 0
      }
    ],
    "authenticationRequirementPolicies": [],
    "sessionLifetimePolicies": [],
    "authenticationRequirement": "singleFactorAuthentication",
    "servicePrincipalId": "",
    "userType": "Member",
    "flaggedForReview": false,
    "isTenantRestricted": false,
    "autonomousSystemNumber": 55836,
    "crossTenantAccessType": "none",
    "privateLinkDetails": {},
    "ssoExtensionVersion": "",
    "uniqueTokenIdentifier": "Cd5bVqVXP0KpAQ2tmdQJAA",
    "authenticationStrengths": [],
    "incomingTokenType": "none",
    "authenticationProtocol": "none",
    "appServicePrincipalId": null,
    "resourceServicePrincipalId": "a2032278-e16b-415a-b719-1f387195acca",
    "rngcStatus": 0,
    "signInTokenProtectionStatus": "none",
    "tokenProtectionStatusDetails": {
      "signInSessionStatus": "unbound",
      "signInSessionStatusCode": 1002
    },
    "originalTransferMethod": "none",
    "isThroughGlobalSecureAccess": false,
    "conditionalAccessAudiences": [
      {
        "applicationId": "00000002-0000-0000-c000-000000000000",
        "audienceReasons": "none"
      }
    ],
    "sessionId": "cd086783-e2a0-4bf7-a780-ebe2521aa691",
    "resourceOwnerTenantId": "f8cdef31-a31e-4b4a-93e4-5f571e91255a"
  }
}

Additionally, in the diagnostic settings we see the following event types available. As far as we understand, Sign-in logs and Audit logs are not alert-based events. From the available event types, which category actually contains the alert-type logs?

AuditLogs
SignInLogs
NonInteractiveUserSignInLogs
ServicePrincipalSignInLogs
ManagedIdentitySignInLogs
ProvisioningLogs
ADFSSignInLogs
RiskyUsers
UserRiskEvents
NetworkAccessTrafficLogs
RiskyServicePrincipals
ServicePrincipalRiskEvents
EnrichedOffice365AuditLogs
MicrosoftGraphActivityLogs
RemoteNetworkHealthLogs
NetworkAccessAlerts
NetworkAccessConnectionEvents
MicrosoftServicePrincipalSignInLogs
AzureADGraphActivityLogs
NetworkAccessGenerativeAIInsights
GraphNotificationsActivityLogs

Any clarification on how to distinguish Identity Protection alerts in Event Hub logs would be very helpful. Thank you.

Marcin Policht 82,355 Reputation points MVP Volunteer Moderator

2026-03-11T13:56:52.6066667+00:00

In the Event Hub log payload, the primary field used to distinguish the source of the data is the category field. In the sample log you provided, the category is set to SignInLogs, which indicates this is a standard authentication record rather than a security alert. To identify alerts specifically from Microsoft Entra ID Protection, look for logs where the category is either UserRiskEvents (for specific detections like leaked credentials or anonymous IP usage) or ServicePrincipalRiskEvents. These categories carry the actual "alert" metadata, while the SignInLogs you shared only show the risk posture of a specific login attempt via the riskLevelDuringSignIn and riskEventTypes properties.

To ensure you are only ingesting alert-type data into your SIEM, consider focusing on the UserRiskEvents and ServicePrincipalRiskEvents diagnostic categories. While RiskyUsers and RiskyServicePrincipals provide the current risk state of an identity, the "Event" categories function as the chronological stream of security detections that most closely align with the definition of an alert. Additionally, if you are using Global Secure Access, the NetworkAccessAlerts category would also contain high-fidelity security alerts related to network traffic and identity perimeter breaches.

If you choose to continue monitoring SignInLogs but want to filter for only those that triggered a security concern, you can inspect the properties object for the riskLevelDuringSignIn or riskState fields. Any value other than none in these fields indicates that Identity Protection flagged the session. However, for a pure "Alert only" stream that avoids the massive volume of successful, low-risk sign-ins, it would be better to deselect SignInLogs in your diagnostic settings and only enable the risk event and alert categories mentioned above.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Share via

How to pull only the alerts type of event from Microsoft Entra ID

1 answer

Your answer