Office 365 failed login attempts report
Thousands of failed logins a day. Three of them are an attack.
A mid-size tenant produces hundreds to thousands of failed sign-ins every day - almost all of them someone mistyping a password on a Monday. Somewhere in that pile is a password spray working through your user list from a rented server. In a plain export the two look identical. 1Security shows where each attempt came from, what device carried it, whether the burst is unusual for that account, and mails you once when a line is crossed.
The problem
Attackers do not break in any more. They log in - and first, they try.
Every password spray, credential-stuffing run and MFA-fatigue attempt starts as rows of failed and blocked sign-ins that look, one by one, like nothing. Then one of them succeeds, and the incident starts with a valid credential nobody was watching.
Volume is the problem. In a tenant of a few hundred users, failed sign-ins run into the hundreds a day; in a large one, thousands. A reviewer who sees them as undifferentiated rows learns to stop reviewing within a week. And a pattern that only becomes obvious over months needs months of history - 1Security keeps up to three years, so the dots are still there to connect.
The difference between a typo and a spray is not in the count. It is in the origin (a home ISP or a hosting datacenter), the machine (an enrolled laptop or a fingerprint your directory has never met), the spread (one account or nine at once) and how far today sits from that account's own normal. 1Security attaches all four to every failed attempt.
In practice
From a pile of failures to a verdict, in minutes.
How a burst of failed sign-ins gets triaged in 1Security.
- 01
The burst surfaces on its own
Every account's failed sign-ins are measured against the median of its own trailing 30 days. Twelve failures on an account that never fails opens an anomaly episode in Anomalies; twelve failures spread across a Monday morning across the company does not. You do not set a threshold - the account's own history is the threshold.
- 02
Read where the attempts came from
Open the episode and every attempt carries its resolved location and network type - home ISP, mobile carrier, VPN, Tor, hosting datacenter - plus a first-seen flag when the place is new for that account. Forty failures from one hosting network across nine accounts is a spray. Forty from the user's usual home ISP is a stuck keyboard.
- 03
Check the device and what Conditional Access stopped
The device is on the same row: a known enrolled laptop, or an unregistered fingerprint. Blocked sign-ins are a first-class log type, so what a Conditional Access policy turned away sits next to what failed on credentials - and the coverage view shows which sign-ins no policy governed at all.
- 04
Get one alert, not four hundred
An instant alert mails the moment the deviation or threshold line is crossed, with a per-episode cooldown so one attack is one message. Everything under the line stays recorded and filterable in Activity logs for up to three years - so the retrospective a month later still has the rows.
What makes it work
Three parts of the platform, one failed-login report.
The report reads the same activity log every other screen in 1Security reads - with the enrichment already done.
Locations
Country, city and network for every attempt, VPN / Tor / datacenter called out, first-seen novelty per account - and cloud relay traffic labelled as such instead of polluting the review.
See the feature →Alerts with a baseline
The default rule needs no number from you: deviation from the account's own 30-day baseline opens an episode, the instant channel mails once, and the sensitivity dial re-answers against your real history the moment you move it.
See the feature →The device behind the attempt
Registered, unregistered or shadow - the machine is part of the row, because a valid credential used from the wrong machine is the story failed logins are trying to tell.
See the feature →
FAQ
Common questions.
Will this alert on every failed login?
No - that is the point. Alerts fire on threshold or deviation lines, evaluated per account against its own baseline, with a cooldown per episode. The individual failures stay recorded and filterable without mailing anyone.
How is this different from a plain sign-in export?
An export gives you rows with an IP address. 1Security gives you the same rows with the place, the network type, the device and the account's baseline attached, keeps them for up to three years, and turns bursts into alerts on its own. It also recognises sign-ins that arrive through cloud relay addresses and labels them, so your report never claims half the company logs in from a datacenter.
Does it see what Conditional Access already blocked?
Yes. Blocked sign-ins are a first-class activity type, so a review covers both what failed on credentials and what a policy turned away - and the Conditional Access coverage view shows which sign-ins no policy governed at all.
How long before the baselines mean anything?
Anomaly detection stays quiet for the first 14 days on purpose, so the first alerts are grounded in a real normal rather than first-week noise. Thresholds, filters and the enriched report itself work from the first sync. No Entra P2 and no E5 are needed for any of it.
See the spray before the successful login.
Connect read-only and get failed and blocked sign-ins with origin, network, device and baseline attached the same day - and one alert when it matters.
Or keep scrolling an export where every row looks the same.