New Graph API methods available for Entra ID audit logs operations

It’s been a while since we talked about the Entra audit logs, and this time we will actually cover some positive developments, for a change. Namely, a set of new methods and resources were recently released under the (/beta) Graph API, allowing us to support some of the scenarios that have been available for years in the portal UI. You can get a quick summary by looking at the screenshot below, or read on for additional details.

 

Let us start with the set of “summarized” (or “aggregated”) sign-in events for the User non-interactive, Service principal and Managed identity categories. All of these have been available for a while now in the portal and provide a grouping of sign-in events per user/app/IP combo, and allow you to view aggregated data for time windows spanning from a single hour to a day. Well, technically you can only choose between three predefined values (1h, 6h or 1d), so “spanning” is not the correct word I suppose.

Three new methods (endpoints) have been added to fetch the corresponding set of “summarized” sign-in events. They match the method names used by the portal, as noted in my initial post on the subject back in 2020. The difference being, they are now part of the Microsoft Graph, not the old Azure AD Graph. And yes, the portal is still using the old, “deprecated” API. Yet another example of “do as I say, not as I do”… but I digress. Here’s the list of methods:

• User sign-ins (non-interactive): getSummarizedNonInteractiveSignIns

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedNonInteractiveSignIns(aggregationWindow='h1')

• Service principal sign-ins: getSummarizedServicePrincipalSignIns

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedServicePrincipalSignIns(aggregationWindow='h1')

• Managed Identity sign-ins: getSummarizedMSISignIns

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedMSISignIns(aggregationWindow='h1')

The example below shows how a sample “summarized” event looks like. As you can see, only a handful of properties will be returned, as opposed to the few dozen supported by the “regular” endpoint. This is intentional and matches the behavior of the portal. Should you require all the additional properties, you can leverage the returned properties to construct a filter for the “standard” /auditLogs/signIns endpoint.

        {
            "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "signInCount": 1227,
            "aggregationDateTime": "2025-09-30T00:00:00Z",
            "firstSignInDateTime": "2025-09-30T00:01:03Z",
            "userPrincipalName": "user@domain.com",
            "appId": "d3590ed6-52b3-4102-aeff-aad2292ab01c",
            "appDisplayName": "Microsoft Office",
            "ipAddress": "xxx.xxx.xxx.xxx",
            "conditionalAccessStatus": "success",
            "resourceDisplayName": "Office 365 SharePoint Online",
            "resourceId": "00000003-0000-0ff1-ce00-000000000000",
            "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
            "servicePrincipalName": null,
            "servicePrincipalId": "",
            "agent": {
                "agentType": "notAgentic",
                "parentAppId": ""
            },
            "status": {
                "errorCode": 9002341,
                "failureReason": "Other",
                "additionalDetails": null
            },
            "managedServiceIdentity": {
                "msiType": "none",
                "associatedResourceId": null,
                "federatedTokenId": null,
                "federatedTokenIssuer": null
            }
        }

All of the above are currently only available under the /beta endpoint. Each method supports both delegate and application permissions, with the AuditLog.Read.All scope being the required one. Each of them also has a mandatory parameter that you need to provide, aggregationWindow, i.e. the time period for which to generate the summary data. The following list of values is supported: h1 (1 hour), h6 (6 hours), d1 (1 day). Do note that the request will fail if you do not provide a value for the aggregationWindow parameter.

The methods support pagination, with the default page size set to 1000. You can modify this via the $top parameter, albeit the maximum page size matches the default one, that is 1000. They also support a robust set of filters via the $filter query parameter, on almost all of the properties available on the summarizedSignIn resource. For example, we can filter by the app id, by leveraging the query below:

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedNonInteractiveSignIns(aggregationWindow='d1')?$filter=appid eq '00000006-0000-0ff1-ce00-000000000000'

A more interesting scenario is filtering all the sign-ins that failed Conditional access checks, which you can do via:

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedNonInteractiveSignIns(aggregationWindow='d1')?$filter=conditionalAccessStatus eq 'failure'

Lastly, as a bonus tip, you can also filter based on the date range, even though the documentation claims otherwise. You can use the firstSignInDateTime property for that, as shown in the example below:

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedNonInteractiveSignIns(aggregationWindow='d1')?$filter=(firstSignInDateTime ge 2025-09-30T00:00:00.000Z and firstSignInDateTime lt 2025-10-01T00:00:00.000Z)

And since I’m spilling the beans on undocumented features, here’s another one: you can also use the $orderby parameter:

GET https://graph.microsoft.com/beta/auditLogs/getSummarizedNonInteractiveSignIns(aggregationWindow='d1')?$filter=(firstSignInDateTime ge 2025-09-30T12:41:50.000Z and firstSignInDateTime lt 2025-10-07T12:41:50.000Z)$orderby=firstSignInDateTime%20asc

The example above will override the default sorting behavior and will arrange the summarized events in an ascending order.

 

Next, we have two far less interesting endpoints, again likely released as replacement for deprecated APIs that are still in use by the Entra portal. First, the signInEventsActivity method gives us the count of sign-in events per day, which is basically the data from the Overview > Monitoring tab. We also get the signInEventsAppActivity method, or a Graph API endpoint for the application activity report, albeit without the breakdown between success and failure events. Both are quite boring, though I might find a use for the latter as part of my service principals report. Just in case, here’s how to use the two endpoints:

#Fetch the Sign-in events summary report
GET https://graph.microsoft.com/beta/auditLogs/signInEventsSummary

#Fetch the App Sign-in events summary report
GET https://graph.microsoft.com/beta/auditLogs/signInEventsAppSummary

Both reports require the AuditLog.Read.All permission, either in delegate or application permission flavor.

 

Lastly, we have the auditActivityTypes method, which serves as sort of metadata document for the Entra audit logs. In other words, it gives you the list of all possible event types supported by Entra, as well as which service they belong to. At present, there are a total of 1312 entries returned by said method, and you can expect the list to grow over time:

The behavior of the method matches the ones we detailed above, with both application and delegate permissions supported, and AuditLog.Read.All required. It does support the $filter operator as well, although given the purpose of the method, you’d probably want to get the full list anyway, and apply any filtering client side. Anyway, here’s an example:

GET https://graph.microsoft.com/beta/auditLogs/auditActivityTypes?$filter=category eq 'WorkflowManagement'

 

And with that, we can close this roundup of Entra audit-related additions to the Graph API. Hopefully you found it useful!