Send Entra Sign-in and Audit Logs to Log Analytics for Retention

To keep Microsoft Entra sign-in and audit logs longer than the built-in 7 or 30 days, create a diagnostic setting that sends them to a Log Analytics workspace, then raise the retention of the tables that receive them. Entra only stores the data for a short period, so anything not exported by the time an incident is discovered is gone. This guide walks through the export, the retention settings, cost control and how to get old data back.

Who this is for and what you will have

This is for identity and security administrators who need to answer questions such as "who signed in from that address six months ago" or "who changed this Conditional Access policy last quarter". It also suits teams that must retain identity logs for compliance.

At the end you will have a diagnostic setting that streams the log categories you choose into a workspace, table-level retention set to the period you need, a cost estimate approach, and a tested path for querying and restoring data that has aged out of fast query storage.

What Entra keeps by default

Retention inside Entra depends on the report and the licence. The values below come from Microsoft's data retention reference.

Two details matter. First, retention changes are not retroactive: upgrading from Free to a premium plan only exposes data still inside the 7-day window, and expired data cannot be recovered unless it was archived. Second, Entra audit and sign-in logs are separate from the Microsoft 365 unified audit log, which is retained through Microsoft Purview Audit. If you need that log instead, see Searching the Microsoft 365 unified audit log.

Choose a destination

Diagnostic settings can send logs to a Log Analytics workspace, an event hub, a storage account, or a partner solution through Azure Native ISV services. You can create several settings to send the same logs to different places.

Microsoft's guidance is to use Azure Monitor logs when you do not plan to use a third-party SIEM. It also suggests keeping one workspace for log storage and a different workspace for Log Analytics and Workbooks. This article covers the Log Analytics route because it gives you KQL and, with table retention, long storage in the same place.

Prerequisites

• An Azure subscription and a Log Analytics workspace. The destination must already exist before you configure the diagnostic setting.
• At least the Security Administrator role in the Entra tenant to create or edit the diagnostic setting.
• Permission to read data in the workspace. See Azure Monitor's guidance on managing access to log data and workspaces.
• Attribute Log Administrator, in addition to Security Administrator, if you also want to route custom security attribute audit logs.
• To change retention later: the Log Analytics Contributor built-in role (or equivalent Microsoft.OperationalInsights/workspaces/write and tables/write permissions).

Microsoft Graph activity logs and several other categories require a premium Entra licence. Check that the categories you plan to enable are available in your tenant before you rely on them.

Create the diagnostic setting

1. Sign in to the Microsoft Entra admin center as at least a Security Administrator.
2. Browse to Entra ID > Monitoring & health > Diagnostic settings. You can also select Export Settings from the Audit Logs or Sign-ins page.
3. Select + Add diagnostic setting.
4. Enter a Diagnostic setting name. The name cannot be changed later.
5. Tick the log categories to stream.
6. Under Destination Details, select Send to Log Analytics workspace, then pick the Subscription and Log Analytics workspace.
7. Select Save.

Microsoft states that integrating Entra logs with Azure Monitor automatically enables the Microsoft Entra data connector in Microsoft Sentinel.

Which categories to select

The available categories are named in Microsoft's streaming reference. A practical baseline for investigations:

The table names above were confirmed in the Azure Monitor table reference for SigninLogs, AuditLogs, AADNonInteractiveUserSignInLogs and AADUserRiskEvents. For the other categories, open the Tables list in your workspace after data arrives and note the table names; they are not repeated here because they were not verified.

Microsoft recommends sending MicrosoftGraphActivityLogs to the same workspace as SignInLogs so you can cross-reference token requests. The MicrosoftServicePrincipalSignInLogs category is in preview, is described as high volume and unnecessary for most customers, and is best left off unless you have a specific need. Custom security attribute audit logs are configured separately under Custom security attributes, and Microsoft recommends keeping them apart from directory audit logs so attribute assignments are not revealed inadvertently.

Estimate and control the cost

Sending data to a workspace is billed, and the volume varies with tenant size, policy count and time of day. Microsoft's figures for planning are that an audit log event is around 2 KB, a sign-in event averages 11.5 KB, and a tenant of about 100,000 users could produce about 1.5 million events per day. Events are batched at about five-minute intervals.

The most reliable method is to enable the setting for a day or two, ideally with the workspace in its own resource group, and read Cost Management > Cost analysis scoped to that group. Alternatively, download a sample of logs (Microsoft suggests starting with 1,000 records, or 15 minutes of sign-ins for large tenants) and scale it to a day.

Two ways to reduce cost:

• Select only the categories you need; every category you add increases the ingested volume.
• Use a data collection transformation to exclude whole events, fields or parts of fields at ingestion. See Azure Monitor Agent and data collection rules for the data collection rule concepts.

Note that changing an existing diagnostic setting can incur new charges.

Set retention beyond 30 days

A Log Analytics workspace holds data in two states. Analytics retention keeps data available for fast queries and alerts; long-term retention is a lower-cost state. By default, tables keep data for 30 days, except tables with 90-day default retention. Total retention is analytics retention plus long-term retention.

Set it in the portal

1. In Log Analytics workspaces, open your workspace and select Tables.
2. Open the context menu for the table, for example SigninLogs, and select Manage table.
3. In Data retention settings, set the analytics retention and total retention.

The same Tables screen shows the retention currently applied to every table.

Set it with Azure CLI

This example, adapted from Microsoft's documentation, keeps 30 days of analytics retention and two years of total retention on a table:

az monitor log-analytics workspace table update \
  --resource-group "<ResourceGroupName>" \
  --workspace-name "<WorkspaceName>" \
  --name "SigninLogs" \
  --retention-time 30 \
  --total-retention-time 730

Set it with PowerShell

$params = @{
    ResourceGroupName    = "<ResourceGroupName>"
    WorkspaceName        = "<WorkspaceName>"
    TableName            = "AuditLogs"
    RetentionInDays      = 30
    TotalRetentionInDays = 730
}
Update-AzOperationalInsightsTable @params

Run the same command for each table you export. To change the workspace default instead, use az monitor log-analytics workspace update --retention-time or Set-AzOperationalInsightsWorkspace -RetentionInDays; this affects only tables that still use the default.

How retention changes behave

• Increasing total retention applies to data already in the table that has not yet been removed.
• Shortening total retention is not applied immediately: Azure Monitor waits 30 days before removing data so you can revert a mistake.
• If you lower analytics retention without lowering total retention, the remaining days become long-term retention, so data is not lost.
• Setting both values to -1 resets a table to the workspace defaults.

Workspaces with 30-day retention might keep data for 31 days. If a privacy policy requires strictly 30 days, Microsoft documents the immediatePurgeDataOn30Days workspace property, set through the Workspaces - Update REST API. Note that this makes the data nonrecoverable.

Table plan matters too: the AuditLogs table does not support the Basic plan according to the table reference, while SigninLogs and AADNonInteractiveUserSignInLogs do. Basic tables have a fixed 30-day query window, so for tables you investigate often, keep the Analytics plan.

Verify the export

Wait for data to arrive (Microsoft says it can take up to three days for logs to start appearing), then open the workspace and select Logs.

SigninLogs
| where TimeGenerated > ago(1d)
| summarize signIns = count(), failures = countif(ResultType != "0") by bin(TimeGenerated, 1h)
| order by TimeGenerated asc

ResultType is the 5 to 6 digit error code, where 0 means success. Then check the audit table:

AuditLogs
| where TimeGenerated > ago(1d)
| summarize events = count() by LoggedByService, ActivityDisplayName
| order by events desc

Finally, confirm retention with az monitor log-analytics workspace table show for the table, or in the Tables screen. For investigation queries to run once the data is flowing, see Investigating AiTM phishing and token theft.

Query data past analytics retention

Data older than analytics retention but inside total retention stays in the table but is not available to normal queries. Two features bring it back.

Search jobs

A search job is an asynchronous query that writes matching records to a new table ending in _SRCH. It suits targeted lookups, such as one user or one IP address, over a long period.

az monitor log-analytics workspace table search-job create \
  --resource-group "<ResourceGroupName>" \
  --workspace-name "<WorkspaceName>" \
  --name "SigninLogsByIp_SRCH" \
  --search-query "SigninLogs | where IPAddress has '203.0.113.25'" \
  --limit 1500 \
  --start-search-time "2026-01-01T00:00:00Z" \
  --end-search-time "2026-03-01T00:00:00Z" \
  --no-wait

Limits from Microsoft: the query must start with a table name and supports a subset of KQL (where, extend, project and related operators, parse); contains is blocked, so use has. Jobs time out at 24 hours, results are capped at 100 million records, you can run ten concurrently, and a workspace is limited to 200 search results tables and 200 search job executions per day. Cost depends on the data scanned in long-term retention plus the data ingested into the results table. Delete the results table when you finish.

Restore

Restore makes a time range of a table available for full KQL in a table ending in _RST.

az monitor log-analytics workspace table restore create \
  --resource-group "<ResourceGroupName>" \
  --workspace-name "<WorkspaceName>" \
  --name "SigninLogs_RST" \
  --restore-source-table "SigninLogs" \
  --start-restore-time "2026-01-01T00:00:00Z" \
  --end-restore-time "2026-03-01T00:00:00Z" \
  --no-wait

Constraints from Microsoft: Analytics and Basic plans only, at least two days of data per restore, up to 60 TB, two concurrent restores per workspace, four restores per table per week. Billing has a 2 TB minimum volume and 12-hour minimum duration, and continues until you delete the _RST table, so dismiss it as soon as you finish. Restored records keep their original timestamps, so filter on the original time range. Wait for provisioningState to show Succeeded before you query.

Troubleshooting

Checklist

• Create the Log Analytics workspace, ideally separate from the one used for daily analytics.
• Create a diagnostic setting with at least AuditLogs, SignInLogs and NonInteractiveUserSignInLogs.
• Add MicrosoftGraphActivityLogs, risk categories and service principal categories if your licence and investigations need them.
• Measure a day or two of ingestion in Cost Management before committing.
• Set total retention on each exported table to match your compliance or investigation window.
• Run the verification queries and confirm the retention values.
• Practise a search job or a small restore once, so the procedure is known before an incident.
• Document who holds the Security Administrator and Log Analytics Contributor roles.

For related reading, see Defender XDR advanced hunting KQL for identity attacks.

References

• Integrate Microsoft Entra logs with Azure Monitor logs
• How to configure Microsoft Entra diagnostic settings
• Logs available for streaming from Microsoft Entra ID
• Microsoft Entra activity log integration options
• Microsoft Entra data retention
• Manage data retention in a Log Analytics workspace
• Run search jobs in Azure Monitor
• Restore logs in Azure Monitor
• SigninLogs table reference
• AuditLogs table reference
• AADNonInteractiveUserSignInLogs table reference
• AADUserRiskEvents table reference