Entra ID logs: why 30 days of retention is not enough to investigate an incident
When an account is compromised, the first question is always the same: since when? Without an export of Entra ID logs, the answer often stops at thirty days, or even seven. Here is how to organise collection so that an investigation remains possible.
Native retention is deliberately short
Entra ID keeps its activity logs in the portal for a period that depends on your licence. On the free tier, sign-in and audit logs are only available for a few days (seven days according to current documentation). With Entra ID P1 or P2 this rises to thirty days. That is enough to troubleshoot a user, but not to reconstruct a compromise discovered several weeks later, which is by far the most common situation.
These durations change from time to time, so check the current Microsoft documentation rather than relying on a remembered figure.
Export through diagnostic settings
The answer is Entra ID diagnostic settings (Monitoring and health > Diagnostic settings), which require a P1 or P2 licence. Three destinations are available, and you can combine them:
- Log Analytics: KQL queries, workbooks and alerts; it is also the foundation for Microsoft Sentinel;
- storage account: low-cost long-term archiving, but awkward to search;
- Event Hub: streaming to a third-party SIEM.
Retention then becomes whatever you configure on the workspace or storage account, with ingestion costs to plan for.
Which categories to collect
The classic mistake is to tick only SignInLogs and AuditLogs. Much of the real activity lives elsewhere:
NonInteractiveUserSignInLogs: token refreshes by client apps, which is where use of a stolen token shows up;ServicePrincipalSignInLogs: applications authenticating with a secret or certificate;ManagedIdentitySignInLogs: activity of Azure managed identities;ProvisioningLogs,RiskyUsersandUserRiskEvents, depending on your licences;MicrosoftGraphActivityLogs, useful to trace the API calls of a malicious application.
Non-interactive sign-ins are high volume. If budget is tight, send them at least to archive storage rather than dropping them.
Key point. An export configured after the incident recovers nothing from the past. Diagnostic settings are not retroactive, so they need to be enabled now.
Why investigations fail without these logs
During incident response you need to establish the first suspicious sign-in, the IP address and user agent, the changes made afterwards (MFA methods added, application consents, mailbox rules) and any persistence through a service principal. Each of those steps relies on a different log category. Without the full history you can neither scope the incident nor demonstrate to an insurer or regulator that exposure is under control.
A simple Log Analytics query confirms that collection is working:
union SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs | where TimeGenerated > ago(1d) | summarize count() by Type
What an audit checks
- at least one active diagnostic setting on the tenant;
- non-interactive, service principal and managed identity categories are included;
- retention consistent with internal policy and regulatory obligations;
- restricted read and delete permissions on the destination workspace.