Microsoft 365 breach detection by location
Who is in your Microsoft 365 right now, pretending to be your employee?
Strong passwords and MFA stop many attacks, not all of them. When someone gets in with a borrowed login, the one thing they cannot fake is where they are. 1Security knows where your people work from, and the moment real activity comes from somewhere else, you know too - who, where, and for how long. Standard license, read-only access.
The problem
A break-in looks like a normal working day. Except for the place.
Attackers rarely break the door down any more. They walk in with a borrowed key: a convincing fake login page, a browser session copied from a home laptop, an app somebody approved once and forgot. Each of those hands them a working account, MFA passed and all. From then on, everything they do looks like an employee doing their job.
The one thing they cannot borrow is your employee's location. A company works from a handful of countries and cities; the intruder sits somewhere else, usually on a rented server. In the raw sign-in log that difference is buried under tens of thousands of addresses a month. On a map it is one red dot among twelve blue ones.
The trap is what happens next. Half of the unexpected places in any company are real trips, and if clearing each one means adding another country to a company-wide allow list, the list covers half the world within a year and the alarm stops meaning anything. A control that survives a travelling sales team has to judge people, not countries.
In practice
From "we would see it in the logs" to an incident within minutes.
How it works in 1Security - next to the identity protection you already have, with nothing new to install.
- 01
Name the places your people work from
Open Locations, then Review, and start from the countries we already observe: a typical tenant shows 3-8 of them, with the user and event counts next to each. Untick the one that is a single contractor, create the allow list, and from that moment every active access from anywhere else is flagged. Global organisations keep a block list instead - the places they never expect - and both lists take Entra named locations and metro cities, not only countries.
- 02
See who was where, within minutes
The Review tab lists one row per person and place the list does not permit: the person, the city and country with the network behind it, when they were there and for how long, and how many real actions they took. Rows appear within about ten minutes of the event. The same event opens an incident on the Anomalies screen, lands in the morning brief and goes out by email under your alerting rules. Failed sign-ins, Microsoft relays and machine identities never make the list.
- 03
Decide per person, not per country
A traveller is one click: "Trip was fine" records that the presence seen so far was reviewed and grants nothing for the future - if the same person turns up there again, the row comes back. "Allow for a period" covers a posting of 30 or 90 days or to a date. Only a real new office goes on the company list. The incident resolves on its own when nobody unreviewed is left at that place.
- 04
Act on the one that is not a trip
The name opens the person: their travel trail says "Warsaw 17:40, Singapore 03:12 - impossible", their devices show whether the session came from a managed laptop or an unknown browser, and their recent files show what was opened. Stage a session revoke or an account disable from the same screen, behind the review window, and the incident carries the evidence.
What makes it work
Three parts of the platform, one incident.
Location-based detection is not a separate product. It runs on the located audit log, the per-user travel model and the incident pipeline you can read about in depth.
Sign-in locations
Every sign-in and file action as a place: country, city and network, with VPN, Tor, hosting and Microsoft traffic told apart and your offices as the anchor.
Explore the feature →Impossible travel
Per-user and per-device trails with plausible, improbable and impossible verdicts, three years back, so a flagged place comes with the leg that led there.
Explore the feature →Anomalies and response
The flagged place is an incident with a severity, a digest, and curated containment actions staged behind a review window.
Explore the feature →
FAQ
Common questions.
Will every business trip raise an incident?
Every first presence in an unexpected place does, once. The decision is per person: "Trip was fine" closes it in one click and keeps the place off the company list, and a posting gets an allowance for a period. What never happens is Lisbon becoming a company location because one person spent a week there.
We already run Entra ID P2, Identity Protection and Conditional Access. What does this add?
A post-authentication signal that does not care how the token was obtained. Risk-based policies act at sign-in; this watches the access that completed afterwards - mailbox reads, file opens, Copilot prompts - against where your own people work, and holds every exception per person with a window and an expiry. Teams with a mature identity stack use it as the control that still fires after a proxied MFA prompt or a replayed cookie, and as the queue their SOC clears every morning. Nothing here needs a premium license; it runs on the audit log with read-only consent.
What about VPN users and Microsoft datacenters?
Microsoft relay traffic is recognised and never counts as a place anyone works from, so server-side mailbox and SharePoint operations do not raise alarms. VPN, Tor and hosting egress is labelled as such on every row; whether a VPN exit belongs on your allow list is your call, and the Review tab shows you the people behind it before you decide.
Why is a failed sign-in not an incident?
Because a password spray from Lagos says nothing about where your people are, and it already has its own detector. The location list judges active access only: a completed sign-in, a file opened, a mailbox read, a Copilot prompt. That is why the Review tab is short enough to clear every morning.
Does this replace Conditional Access?
No, it watches what Conditional Access let through. A policy blocks by named location at sign-in; this detects the access that still completed, including from places your named locations never mentioned, and shows the share of sign-ins that finished with no policy applied at all.
See where your company was really reached from last week - and whether all of it was your people.
Connect read-only and the Review tab fills from activity you already generate, the same day. The first list takes about five minutes.
Or keep assuming every login was an employee.