Entra Sign-In Logs: Turning Lines of Log Text Into a Story

A sign-in log is the record of who tried to enter a system, when, from where, and whether they succeeded, and in a cloud identity system such as Microsoft Entra, those lines accumulate quickly. A single user may generate dozens of sign-ins a day across devices and applications, and an organisation of any size generates thousands, so nobody reads such logs line by line. Instead, administrators summarise: how many sign-ins succeeded, how many failed, which users account for the failures, and whether the failures cluster in a way that suggests a forgotten password, a broken configuration, or an attack. Summarising is not a shortcut; it is the only way the volume becomes readable at all.

The Entra Sign-In Log Analyzer takes sign-in log lines you paste in and summarises successes, failures and counts per user. It works on pasted text only, which means it does not connect to a live tenant, does not verify events against a real directory, and cannot see sign-ins that were not included in the paste. What it gives is a structured summary of the lines it was given: totals, a breakdown by result, and a per-user count that shows where activity concentrates. That summary is a starting point for investigation, not a security verdict, and a clean summary of a partial paste says nothing about the lines that were left out.

Two patterns deserve attention above the rest, because they point at different problems. Repeated failures for a single account often mean a user with a wrong saved password, a device retrying with an expired credential, or an attacker guessing at one account. Failures spread thinly across many accounts, sometimes called spraying, often mean an attacker trying a few common passwords against many accounts, hoping that one will match. The first pattern is concentrated and loud; the second is diffuse and quiet, and it only becomes visible when the logs are counted per user and per result rather than read as a stream. A summary that shows both dimensions is therefore far more useful than a simple total.

Worked example

Worked example with sample values. Suppose you paste 50 sample log lines: 40 successes and 10 failures. Dividing 10 by 50 gives 0.20, so the failure rate is 20 percent, which is high enough to investigate. Breaking the 10 failures down per user gives 7 failures for one user, 2 for a second, and 1 for a third, and 7 divided by 10 equals 0.70, so 70 percent of failures belong to a single account. That concentration points first at that account: a saved password, a stale device, or a targeted guessing attempt. If instead the 10 failures were spread as 1 failure across each of 10 different users, the same total would point at a different explanation, such as a spraying attempt or a shared configuration problem. These are sample values only, invented to show how the same total supports different conclusions once it is broken down.

Now suppose the same 50 lines cover a period in which a password policy changed, and the failures cluster in the first hour after the change before falling to zero. Counting failures per hour gives 8 in the first hour, 2 in the second, and 0 afterwards, which suggests users adapting to a change rather than an attack. The lesson is that counts need context: a total without a time window, a user breakdown, and a result breakdown is a number in search of a story, while the same lines broken down by all three usually tell the story themselves.

Mistakes to avoid

The first mistake is treating a summary of pasted lines as a complete picture of a tenant. A paste is a sample, and an attacker whose lines were not included will not appear in it, however thorough the summary looks. The second mistake is acting on a failure count without checking the user breakdown, which leads to locking an account that merely needs a password reset, or to missing a diffuse attack because no single user stood out. The third mistake is pasting sensitive log content into an untrusted page: logs can contain usernames, addresses, device details and sometimes tokens, so paste only the lines needed, redact anything sensitive first, and never paste passwords, secrets or tokens. The fourth mistake is confusing correlation with cause: a spike in failures after a change may be caused by the change, by an attack, or by coincidence, and only further evidence separates those explanations.

Another trap is setting an alert threshold on totals alone. A total threshold will fire on a busy Monday and stay silent during a quiet, diffuse attack, because totals measure volume while attacks often measure distribution. Thresholds on per-user failures, on failure rates, and on new locations or devices catch more real problems with fewer false alarms than a single total ever will.

Putting it into practice

Use the analyzer when triaging a batch of sign-in lines, when preparing a report for a security review, and when deciding whether a failure pattern needs escalation. Paste a defined set of lines, note the time window they cover, read the totals, then the per-user breakdown, then the result breakdown, and record what each pattern suggests before acting. Follow up through the proper administrative tools for any account or pattern that looks wrong, and re-run the summary on fresh lines after a fix. Logs become useful when they are counted carefully and acted on through the right channels, not when they are merely collected.

Related tools and reading: the JSON Studio, the User-Agent Parser cover neighbouring checks that pair naturally with this one, and the guide at [/blog/cloud-iam-policy-analyzer-guide/] extends the same topic with further background and examples for readers who want to go deeper.

Key points

• Summaries describe the pasted lines only, never a whole tenant
• Per-user counts separate concentrated from diffuse patterns
• Failure rate needs a time window and a user breakdown
• Redact sensitive details before pasting any log

In short: Sign-in logs become readable when counted by result, by user, and by time. The analyzer summarises pasted lines in those dimensions. A concentrated pattern and a diffuse pattern point at different causes. Pasted lines are a sample, never the whole picture.

One habit ties all of this together: re-check after every change. A result from the Entra Sign-In Log Analyzer is only as current as the input it was run on, so a fix, a redesign, or a new version of the underlying material deserves a fresh run rather than reliance on an old report. Keep the previous result alongside the new one, note what changed between them, and treat any new finding as a question to investigate rather than a verdict to accept or dismiss. That loop of checking, fixing, re-checking and recording is what turns a one-off test into a reliable routine, and it costs far less time than debugging a problem that a second check would have caught early.