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

> Route Microsoft Entra sign-in and audit logs to a Log Analytics workspace, set table retention beyond 30 days, and query or restore old data later.

Source: https://www.epifive.com/blog/entra-logs-log-analytics-retention · Published 2026-10-15 · EpiFive

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.

| Report | Entra ID Free | Entra ID P1 | Entra ID P2 |
| --- | --- | --- | --- |
| Audit logs | 7 days | 30 days | 30 days |
| Sign-ins | 7 days | 30 days | 30 days |
| Entra multifactor authentication usage | 30 days | 30 days | 30 days |
| Risky sign-ins | 7 days | 30 days | 90 days |
| Risky users | No limit | No limit | No limit |
| Microsoft Graph activity logs | Not available | Not retained unless exported | Not retained unless exported |

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](https://www.epifive.com/blog/microsoft-365-audit-log-search).

## 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.

| Goal | Recommended destination |
| --- | --- |
| Basic troubleshooting, under 30 days | Entra admin center or Microsoft Graph, no export needed |
| Keep logs long term, rarely queried (compliance) | Storage account |
| Keep logs and query them regularly | Log Analytics workspace |
| Feed a non-Microsoft SIEM | Event hub |

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](https://entra.microsoft.com) 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:

| Category | What it holds | Log Analytics table |
| --- | --- | --- |
| `AuditLogs` | Changes to applications, groups, users and licences | `AuditLogs` |
| `SignInLogs` | Interactive user sign-ins | `SigninLogs` |
| `NonInteractiveUserSignInLogs` | Sign-ins on behalf of a user by a client app, using a token or code | `AADNonInteractiveUserSignInLogs` |
| `ServicePrincipalSignInLogs` | App and service principal sign-ins with secrets or certificates | see note |
| `ManagedIdentitySignInLogs` | Managed identity sign-ins | see note |
| `MicrosoftGraphActivityLogs` | HTTP requests to your tenant through Microsoft Graph | see note |
| `RiskyUsers`, `UserRiskEvents` | ID Protection risky users and risk detections | `AADUserRiskEvents` for risk events |

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](https://www.epifive.com/blog/azure-monitor-agent-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.

| Setting | Limit |
| --- | --- |
| Analytics retention (Analytics plan tables) | Up to two years (730 days) |
| Total retention | Up to 12 years (4,383 days) |
| Azure CLI `--total-retention-time` | Up to 2,556 days |
| Minimum analytics retention | 4 days, but 31 days are included in the ingestion price |

### 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:

```bash
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

```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**.

```kusto
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:

```kusto
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](https://www.epifive.com/blog/aitm-phishing-token-theft-investigation).

## 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.

```bash
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`.

```bash
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

| Symptom | Likely cause and fix |
| --- | --- |
| No diagnostic settings option, or save fails | The account lacks the Security Administrator role. Custom security attribute logs need Attribute Log Administrator as well. |
| Data missing in the workspace | Allow up to three days, then confirm the category is ticked and the correct workspace is selected. |
| Selected a category but the table stays empty | Some categories hold data only if the feature is in use or generally available, such as `NetworkAccessTrafficLogs` without Global Secure Access. |
| Query returns nothing older than 30 days | The table still has default analytics retention, or the data is in long-term retention. Raise analytics retention or run a search job or restore. |
| Cannot find a user's old sign-ins from before the export began | They were never captured. Entra data past its retention period cannot be recovered. |
| Search job rejected | The query uses an unsupported operator such as `contains`, or does not start with a table name. |
| Search or restore fails over a delegated workspace | Azure Lighthouse delegated access and cross-tenant search jobs are not supported. Sign in to the workspace's own tenant. |
| Retention CLI command rejects a long value | `--total-retention-time` tops out at 2,556 days; use the portal, REST API or PowerShell for longer. |

## 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](https://www.epifive.com/blog/advanced-hunting-kql-identity-attacks).

## References

- [Integrate Microsoft Entra logs with Azure Monitor logs](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-integrate-activity-logs-with-azure-monitor-logs)
- [How to configure Microsoft Entra diagnostic settings](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/howto-configure-diagnostic-settings)
- [Logs available for streaming from Microsoft Entra ID](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-diagnostic-settings-logs-options)
- [Microsoft Entra activity log integration options](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-log-monitoring-integration-options-considerations)
- [Microsoft Entra data retention](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention)
- [Manage data retention in a Log Analytics workspace](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/data-retention-configure)
- [Run search jobs in Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/search-jobs)
- [Restore logs in Azure Monitor](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/restore)
- [SigninLogs table reference](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/signinlogs)
- [AuditLogs table reference](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/auditlogs)
- [AADNonInteractiveUserSignInLogs table reference](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aadnoninteractiveusersigninlogs)
- [AADUserRiskEvents table reference](https://learn.microsoft.com/en-us/azure/azure-monitor/reference/tables/aaduserriskevents)

## Frequently asked questions

### How long does Microsoft Entra ID keep sign-in and audit logs?

Seven days on Microsoft Entra ID Free and 30 days on P1 and P2, for both audit logs and sign-ins. Risky sign-ins are kept 7, 30 or 90 days on Free, P1 and P2. To keep anything longer you must route the logs to a destination such as a Log Analytics workspace or a storage account.

### Can I recover Entra sign-in logs that were never exported?

No. Retention changes are not retroactive, and data that has already expired in Entra cannot be recovered unless it was archived earlier. A diagnostic setting only captures events from the point it is created, so create it before you need the history.

### How long can a Log Analytics table keep data?

Analytics retention can be set up to two years, and total retention (analytics plus long-term retention) up to 12 years, which is 4,383 days. The Azure CLI parameter for total retention supports up to 2,556 days; use the portal, REST API or a current Az PowerShell module for longer periods.

### Why are no Entra logs showing up in my workspace?

Microsoft notes it can take up to three days for logs to start appearing in the destination after you save a diagnostic setting. Also confirm the setting has the right categories ticked, that you are querying the correct workspace, and that the category is available for your licence.