How long are Azure sign-in logs kept?

In the Microsoft Entra portal, sign-in and audit logs are retained only for a limited period — commonly around 7 days on a free tier and up to 30 days with a paid Entra ID plan. That is not enough for most investigations or compliance requirements, which is why you export the logs via diagnostic settings to a Log Analytics workspace or storage account where you control the retention period.

What is the difference between sign-in logs and audit logs in Entra ID?

Sign-in logs record authentication events — who signed in, from where, on what device, whether MFA was satisfied, and whether the sign-in was risky. Audit logs record changes to the directory — a role assignment, a user or group edit, a Conditional Access policy change. You usually export both: sign-in logs to catch account-takeover attempts, audit logs to catch privilege and configuration changes.

Can I alert on failed or risky sign-ins in Azure?

Yes. Once the sign-in logs are in a Log Analytics workspace, you can write a KQL query — for example counting failed sign-ins per user or filtering to risky sign-ins — and attach an Azure Monitor alert rule that fires when the query crosses a threshold. That turns passive logs into active detection. For identity risk specifically, Entra ID Protection (P2) also surfaces risky sign-ins and can trigger automatic responses.

Field notes · Governance

Sign-in / login auditing

Auditing sign-in activity in Azure with diagnostic settings

Q: How do I audit sign-in activity in Azure?

Route the Microsoft Entra sign-in and audit logs to a durable destination using diagnostic settings. Send them to a Log Analytics workspace so you can query them with KQL and build alerts, optionally to a storage account for cheap long-term retention, and to an event hub if a SIEM needs to ingest them. The portal's built-in sign-in logs are kept only for a limited window, so exporting them is what gives you real, queryable login auditing and history.

By Captain O7 min read

The day you need to know who signed in three weeks ago is the day you discover the portal only kept a week of logs. Export them now, while it costs nothing but a diagnostic setting.

New to cloud? CAMPUX is a free, build-first course. Start here →

Audit sign-ins by exporting the Entra sign-in and audit logs with diagnostic settings: send them to a Log Analytics workspace to query with KQL and alert, a storage account for cheap long-term retention, and an event hub if a SIEM ingests them. The portal keeps sign-in logs only briefly — around 7 to 30 days — so the export is what turns "we have logs" into "we can actually investigate." One diagnostic setting, and your identity plane becomes observable.

Guardrails you can't see working aren't guardrails you can trust. You enforced MFA, blocked legacy auth, tightened access — but if you can't answer "was this account's login normal?" a month later, you're flying blind. Sign-in auditing is the evidence layer under the whole identity plane, and it's almost free to set up before you need it (and impossible to set up retroactively — logs you didn't export are gone).

Sign-in logs vs audit logs

	Sign-in logs	Audit logs
Record	Authentication events	Directory changes
Answers	Who signed in, from where, MFA satisfied, risky?	Who changed a role, policy, user, or group?
Catches	Account-takeover attempts	Privilege & config changes

Export both. Sign-in logs catch the attacker trying to get in; audit logs catch what changed once someone did (or what an insider altered). There are also non-interactive sign-in logs — for service principals and tokens — worth exporting if you run a lot of automation.

Set up the export

In Microsoft Entra ID → Diagnostic settings → Add diagnostic setting, tick the log categories (SignInLogs, AuditLogs, and the non-interactive/service-principal categories you want) and pick destinations:

Log Analytics workspace — the important one: makes logs queryable with KQL and alertable. Set the workspace retention to what you need.
Storage account — cheap, long-term retention for compliance; not queryable directly.
Event hub — stream to a SIEM (Sentinel, Splunk, etc.).

Most setups send to Log Analytics for working queries plus a storage account for the long tail. If you run Microsoft Sentinel, the Entra data connector wires this up for you.

Query it — the KQL you'll actually use

Once logs land in Log Analytics, a few queries earn their keep immediately. Failed sign-ins by user (spray/brute-force signal):

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType != 0        // non-zero = failed
| summarize failures = count() by UserPrincipalName, IPAddress
| where failures > 10
| sort by failures desc

Risky sign-ins, or sign-ins from unexpected countries, follow the same shape — filter RiskLevelDuringSignIn or Location. Attach an Azure Monitor alert rule to any of these so a threshold breach pages someone instead of sitting in a table nobody reads.

Guarantee it everywhere with policy

Setting a diagnostic setting once is good; guaranteeing every relevant resource has one is better. A DeployIfNotExists Azure Policy can enforce diagnostic settings across the estate so nothing silently stops logging — see enforcing diagnostic settings with Azure Policy.

The logs you didn't export are the ones the investigation always needs. Turn it on before, not after.

Questions people also ask

How do I audit sign-in activity in Azure?

Export the Entra sign-in and audit logs via diagnostic settings to a Log Analytics workspace (query + alert), optionally a storage account (retention) and an event hub (SIEM). The portal keeps them only briefly, so the export is what enables real auditing.

How long are sign-in logs kept?

In the portal, roughly 7 days on the free tier and up to 30 days on a paid plan — usually not enough for investigations or compliance, which is why you export to a destination whose retention you control.

Sign-in logs vs audit logs?

Sign-in logs record authentication (who signed in, from where, MFA, risk); audit logs record directory changes (roles, policies, users, groups). Export both — one for account-takeover, the other for privilege and config changes.

Can I alert on failed or risky sign-ins?

Yes — with logs in Log Analytics, write a KQL query (failed sign-ins per user, risky sign-ins) and attach an Azure Monitor alert rule that fires on a threshold. Entra ID Protection (P2) also surfaces risky sign-ins and can respond automatically.