Entra ID Logging: Retention, Diagnostic Settings, SIEM Export Gaps

Entra ID Logging Retention, Diagnostic Settings, SIEM Export: What's Missing

Entra ID logging retention, diagnostic settings, SIEM export — three separate controls, and by default none of them do what most teams assume. Sign-in and audit logs expire in days, not months. Nothing is routed anywhere without an explicit diagnostic setting. And unless someone has wired up an event hub or a Log Analytics workspace, Microsoft Sentinel or a third-party SIEM never sees a single Entra ID event.

This is a config gap, not an attack technique — but it is one of the highest-leverage gaps in the whole Azure catalogue, because it decides whether every other detection in this blog is actually usable. A Conditional Access policy that blocks legacy auth is worthless to investigate after the fact if the sign-in that triggered it already aged out of the log. An identity protection risk detection means nothing to a SOC that has no pipe feeding it into their SIEM.

Four related findings sit in this cluster:

• AZ_AUDIT_LOG_RETENTION_SHORT — audit logs are retained for less than the tenant's license entitles it to (or than an incident-response window requires).
• AZ_SIGN_IN_LOGS_NOT_RETAINED — sign-in logs are on the default free-tier window and disappear before most breach-detection timelines even start.
• AZ_DIAGNOSTIC_SETTINGS_MISSING — no diagnostic setting exists to route logs anywhere at all, so the default retention window is the only retention that exists.
• AZ_NO_SIEM_EXPORT — logs may reach a Log Analytics workspace but never leave it for a monitored SIEM, so nobody is alerting on them.

How the Gaps Actually Happen

Retention is a license ceiling, not a policy you set

Per Microsoft's documentation on Microsoft Entra data retention, the built-in retention window for audit logs and sign-in logs is:

Two details make this worse than it looks:

1. Retention changes aren't retroactive. Microsoft's docs state directly: when you upgrade from Free to P1/P2, you only recover whatever is still inside the free 7-day window — data that already expired is gone unless it was previously archived.
2. Microsoft Graph activity logs aren't available at all on Entra ID Free, and are not retained by default even on P1/P2 — Microsoft's own retention table lists them as requiring integration with storage or analytics tooling from day one; there's no fallback default window to fall back on like there is for audit and sign-in logs.

If an incident is discovered nine days after the fact — a very normal timeline for credential-based compromise — a P1/P2 tenant with no export configured has already lost the sign-in evidence for the first two days of the intrusion, and a Free tenant has lost almost everything.

Diagnostic settings are opt-in, per log category, per destination

Routing logs out of Entra ID's default retention window requires a diagnostic setting, configured at Entra admin center → Monitoring & health → Diagnostic settings by a user with the Security Administrator role (How to configure Microsoft Entra diagnostic settings). This is not automatic, and it does not cover "everything" unless every relevant log category is explicitly selected.

Microsoft documents the streamable log categories, each of which has to be picked individually (Logs available for streaming from Microsoft Entra ID) — the security-relevant ones include:

AuditLogs                          SignInLogs
NonInteractiveUserSignInLogs       ServicePrincipalSignInLogs
ManagedIdentitySignInLogs          ProvisioningLogs
ADFSSignInLogs                     RiskyUsers
UserRiskEvents                     RiskyServicePrincipals
ServicePrincipalRiskEvents         RiskyAgents / AgentRiskEvents
NetworkAccessTrafficLogs           MicrosoftGraphActivityLogs
EnrichedOffice365AuditLogs         CustomSecurityAttributeAuditLogs

A tenant can have a diagnostic setting that only forwards AuditLogs while SignInLogs, RiskyUsers, and UserRiskEvents — the categories that actually carry authentication and risk telemetry — stay unrouted and subject to the 7/30-day ceiling above. This is a very common half-configured state: someone enabled logging once for a compliance checkbox, picked one or two categories, and never revisited it. The same gap directly undermines investigations into privileged role activity tracked through Azure PIM — an activation history is only as durable as the audit log it's written into.

The destination itself has to already exist before the diagnostic setting can point to it: a Log Analytics workspace, an event hub, or a storage account. Logs can take up to three days to start appearing after a setting is saved, which matters when validating a fix.

A Log Analytics workspace is not a SIEM

This is where AZ_NO_SIEM_EXPORT diverges from AZ_DIAGNOSTIC_SETTINGS_MISSING: a tenant can have diagnostic settings fully configured, dumping every category into a Log Analytics workspace, and still have zero detection coverage — because nobody is running analytics rules against that workspace, or the workspace was never connected to Microsoft Sentinel or exported to a third-party SIEM (Splunk, Elastic, QRadar) via event hub.

Microsoft's own integration docs note that connecting Entra logs to Azure Monitor logs does automatically enable the Microsoft Entra data connector inside Microsoft Sentinel (Integrate Microsoft Entra logs with Azure Monitor logs) — but only if Sentinel is deployed on that same workspace in the first place. A workspace with no Sentinel (or no equivalent SIEM ingestion) on top of it is a write-only archive: data is being retained, but nobody, and nothing, is looking at it.

Detection

Check each of the four gaps independently — a tenant frequently has some but not all fixed.

1. Confirm what's actually configured, not what you assume is configured. In the Entra admin center, go to Monitoring & health → Diagnostic settings and check every existing setting: which log categories are selected, and which destination they point to. If the list is empty, AZ_DIAGNOSTIC_SETTINGS_MISSING applies immediately — the tenant is running on default retention only.

2. Check the license-driven retention ceiling against your actual incident-response requirements. A 7-day window on Entra ID Free, or even the 30-day window on P1/P2, is short compared to typical dwell-time statistics for identity-based intrusions — if nothing extends it, flag AZ_AUDIT_LOG_RETENTION_SHORT / AZ_SIGN_IN_LOGS_NOT_RETAINED.

3. Verify data is actually reaching Log Analytics, not just that a setting exists. In Sentinel or a connected workspace, run:

SigninLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

AuditLogs
| summarize LastEvent = max(TimeGenerated), Count = count()

Note the table names use SigninLogs (lowercase "i") in Log Analytics, distinct from the SignInLogs diagnostic-setting category name — a common source of "why is my query empty" confusion. If LastEvent is stale or the table doesn't exist, the diagnostic setting either isn't saved, doesn't include that category, or is pointed at a different workspace than the one you're querying.

4. Confirm the SIEM side, not just the pipe. If Microsoft Sentinel is the target, check Data connectors → Microsoft Entra ID shows connected, with both SignInLogs and AuditLogs toggled on — this is a separate switch from the Entra-side diagnostic setting and both have to point at the same workspace. For a third-party SIEM, confirm the event hub actually has an active consumer group pulling from it, not just that the diagnostic setting lists an event hub as a destination.

5. For programmatic evidence gathering, the Microsoft Graph PowerShell SDK exposes the underlying data directly, independent of any SIEM pipeline, which is useful to confirm what Entra ID itself currently holds:

# Confirm how far back sign-in data currently goes
Get-MgAuditLogSignIn -Top 1 -Sort "createdDateTime asc"

# Same check for directory audit events
Get-MgAuditLogDirectoryAudit -Top 1 -Sort "activityDateTime asc"

Remediation

1. Stand up the destination first. Create (or identify) a Log Analytics workspace, and if long-term cold storage is also required, a separate storage account — diagnostic settings need the destination to exist before they can point to it.
2. Create the diagnostic setting with every security-relevant category selected, not just AuditLogs. At minimum: AuditLogs, SignInLogs, NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, RiskyUsers, UserRiskEvents. Add ADFSSignInLogs and ProvisioningLogs if those apply to your environment.
3. Connect the workspace to Microsoft Sentinel (or your SIEM's event-hub consumer) and confirm the Microsoft Entra ID data connector shows both SignInLogs and AuditLogs as connected — a workspace receiving data with no SIEM reading it closes AZ_DIAGNOSTIC_SETTINGS_MISSING but leaves AZ_NO_SIEM_EXPORT open.
4. Extend retention past the license ceiling by configuring the Log Analytics workspace or storage account's own retention policy independently of Entra ID's 7/30-day default — Entra ID's retention window stops mattering once the data lives in Azure Monitor. Organizations with Microsoft 365 E5 / Purview Suite licensing can alternatively extend retention through Microsoft Purview Audit (Premium).
5. Re-run the detection queries above after saving the setting — allow up to three days for data to appear before concluding it failed — and confirm LastEvent in SigninLogs / AuditLogs is current, not just that the query returns some rows.
6. Document who owns re-validation. Diagnostic settings drift silently: a workspace migration, a Sentinel onboarding that missed re-pointing the connector, or a lapsed Purview license can all quietly stop the pipeline without any error visible in the Entra admin center.

How EtcSec Detects This

EtcSec checks AZ_AUDIT_LOG_RETENTION_SHORT, AZ_SIGN_IN_LOGS_NOT_RETAINED, AZ_DIAGNOSTIC_SETTINGS_MISSING, and AZ_NO_SIEM_EXPORT as part of every Azure/Entra ID audit — confirming not just that a diagnostic setting exists, but which log categories it actually forwards and whether the destination is one your SOC is monitoring. This is a companion check to the broader tenant hardening picture covered in how to audit Microsoft Entra ID security and the Azure tenant hardening baseline.