In my projects, Entra sign-in logs carry most of the weight in any serious identity monitoring. The portal's 30-day view runs out fast, whether I'm troubleshooting, checking a new Conditional Access policy or working through an actual incident. Plenty of tenants still rely on that default. Once an investigation has to go back several months, or compliance asks for longer retention, a Log Analytics workspace stops being optional. Set up properly, it gives you up to two years of retention, proper queries and a base for proactive security operations.

A diagnostic setting routes Entra sign-in logs into Log Analytics

You need at least an Entra ID P1 licence to send Entra sign-in logs to Log Analytics. Most E3/E5 plans already include it. The configuration sits in the Entra admin center under Monitoring & health → Diagnostic settings. Create a Diagnostic setting for the tenant, pick SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs and AuditLogs as categories, and point it at your Log Analytics workspace. A central workspace for security or identity logs works best. Keep in mind that only logs generated after you enable the setting reach Log Analytics. Historical events can't be exported after the fact.

If your environment runs a lot of automation, service principals or custom integrations, turn on NonInteractiveUserSignInLogs and ServicePrincipalSignInLogs as well. Those categories show attacks and misconfigurations you'll never see in interactive sign-ins. The setup itself is simple. If you want to automate the deployment with ARM or Bicep, though, you'll need a service principal with Monitoring Reader or Contributor.

{
  "category": [
    "SignInLogs",
    "NonInteractiveUserSignInLogs",
    "ServicePrincipalSignInLogs",
    "AuditLogs"
  ],
  "destination": "log-analytics",
  "retention": "365d"
}

Example: JSON payload for Diagnostic Settings via ARM/Bicep

Non-interactive sign-ins and table plans drive most of the cost

In Log Analytics, the NonInteractiveUserSignInLogs are usually where costs get out of hand. Tenants with heavy automation, many app registrations or lots of B2B identities can produce millions of these entries every week. You pay for ingested data and for retention, so look at the table plans in your workspace and think about moving less critical log types to the Basic plan (I went into cost planning in this earlier post).

From experience: Estimate the volume and run a short retention test before you switch on non-interactive logs across the board. You can roll back, but the logs already ingested still end up on the bill.

A few KQL queries cover most of my sign-in log analysis

With logs arriving in your Log Analytics workspace, you can query them with KQL (Log Analytics Reader or higher is required; table reference). These are the queries I reach for most often, and they tend to end up in security or governance dashboards:

1. Finding legacy authentication by client app:

SigninLogs
| where ClientAppUsed != "Browser" and ClientAppUsed != "Mobile Apps and Desktop clients"
| summarize Count = count() by ClientAppUsed, UserPrincipalName
| sort by Count desc

2. Failed sign-ins grouped by cause (ResultType):

SigninLogs
| where ResultType != 0
| summarize Failures = count() by ResultType, ResultDescription
| sort by Failures desc

3. Unusual Service Principal sign-ins (AppDisplayName):

ServicePrincipalSignInLogs
| where AppDisplayName !in ("Microsoft Graph", "Azure CLI")
| summarize Count = count() by AppDisplayName, ServicePrincipalName
| sort by Count desc

The first query is usually a wake-up call. If legacy auth still shows up, the migration plans need another look. It connects directly to my post on Conditional Access testing and the one on SMTP AUTH basic auth retirement.

Workbooks and alerts turn sign-in logs into something you can watch

Custom workbooks are a part of Log Analytics that gets less attention than it deserves. You can build dashboards for the identity or SOC team that show sign-in trends, failed attempts by geography or how a Conditional Access rollout is progressing. Many admins pair workbooks with log-based alerts for things like failure spikes, sign-ins from high-risk countries or new legacy auth attempts. When I test Conditional Access in report-only mode, these logs are the most reliable way to see the actual impact (more in the Conditional Access testing post). Through the Azure Monitor integration, the alerts can kick off incident response workflows or feed your SIEM.

The diagram below shows the flow:

flowchart TD
    EntraID["Entra ID"] --> DiagnosticSettings["Diagnostic Settings"]
    DiagnosticSettings --> LogAnalytics["Log Analytics Workspace"]
    LogAnalytics --> KQLQueries["KQL queries"]
    LogAnalytics --> Workbooks["Workbooks"]
    LogAnalytics --> Alerts["Alerts"]
    KQLQueries --> Admin["Identity/Security Admin"]

Figure: Entra sign-in logs flow into Log Analytics, where administrators use them for queries, workbooks and alerts

The setup is worth the cost for anyone serious about monitoring

Getting Entra sign-in logs into Log Analytics and sorting out retention does take extra work. The costs can climb too, particularly for non-interactive logs if you skip table plans or don't limit the data types. Still, anyone who takes security, compliance or incident response seriously needs this level of detail. Conditional Access testing, finding legacy auth, forensic investigations: in all of these the Log Analytics setup earns its keep quickly. If cost has kept you from doing it, start with the essential log categories and a short retention period, and see what it does for your day-to-day operations.