LocationsCopy Anchor Link

The Locations screen answers two questions that belong together: "Where is our data actually being reached from - and do the rules we declared match that reality?" Every sign-in and every file action in your tenant happens somewhere; this screen collects those somewheres into stable, named places, ranks them by activity, and lays your Conditional Access configuration over the top so the gaps have nowhere to hide.

A Location here is not an IP address. It is a resolved identity made of country, city, and the network that owns the connection - so two hundred fleeting addresses from one household read as a single "Warsaw, Poland - home ISP" row. How that resolution works, including how Microsoft's own relay traffic is recognised and neutralised, is covered in Location Intelligence.

What You Can AchieveCopy Anchor Link

Four Tabs, One QuestionCopy Anchor Link

• Locations - every place activity has been observed from, as a filterable, sortable list.
• Company locations - the places you have marked as offices, plus recommended candidates.
• Map - the same data on a world map, with layers for offices, user locations, Microsoft datacenters, suspicious networks, and Conditional Access gaps.
• Conditional Access - your declared policy laid over observed reality. See Conditional Access for the full mechanics.
• Review - the locations with active access that your location allow list or block list does not permit, each one also an open incident. See Review - the location list.

Reading the ListCopy Anchor Link

One place is one row by construction: however a record names a location - a district here, a different spelling there - it lands on the single row for the place it really is, with the precise label preserved ("Łódź · Widzew"), while independent small towns keep their own identity. On top of that, the list bundles locations by city by default - one row per metro, and clicking it drills into the individual locations behind it. Switch to All locations for the raw view.

Each row carries the location's identity - country, city, and network (the ASN: a home ISP, a mobile carrier, a corporate network, a cloud provider) - alongside its infrastructure type, its CA coverage verdict, the distance to the nearest office, how many events, users and devices have been seen there, an activity sparkline, and when it was first and last seen.

Above the list, quick-filter chips put the highest-signal cuts one click away, each with a live count: Tor, VPN, Datacenter, and Microsoft. The full filter drawer goes further - by country, city, network, infrastructure type, Conditional Access coverage state, a specific CA finding, or a specific named location.

First seen deserves special attention across this screen: 1Security flags the first time any user is observed at a given location, so "new place, real activity" is a filterable fact rather than a hunch.

Active Access vs Attempts vs ProcessingCopy Anchor Link

Not every event that lands on a location means somebody was there. 1Security sorts each attributed event into one of four kinds, and every count on this screen - lists, chips, drawers, map - is split by them:

• Active access - a session that exists did something: a file view or download, a mail read, a Copilot prompt, an admin change, a successful sign-in. An AI agent acting under a person's identity counts here too, because the person is the one who got in. This is the number that answers "did anyone actually get in from here?"
• Sign-in attempts - rejected, blocked or abandoned sign-ins. They prove only that someone tried from a place, and the address belongs to whoever was guessing. Every internet-facing tenant collects these from half the planet.
• Automated - an app, service principal or agent identity acting on its own, with no person behind the session: Power Automate runs, Entra agent identities, autonomous Copilot work.
• System processing - Microsoft's own relay datacenters (the address is a server, not a person), meeting and call relays and bots, and 1Security's own remediation writes.

A location's headline access kind is the highest of those it has: anything with active access reads active; a place with nothing but attempts reads sign-in attempts only; and so on. The Active access and Sign-in attempts only chips above the list put the two opposite findings one click apart: if your company works from Poland, a sign-in attempts only row in Ghana is noise to glance past, while an active row in Ghana means somebody succeeded. The same split appears on each user's and device's Locations tab ("did this account do something from here?"), on the location drawer's Users and Devices tabs, and in the CSV export.

Company LocationsCopy Anchor Link

Offices are the anchor of the whole screen: once 1Security knows where normal work happens, everything else can be measured by its distance from normal.

Marking an office takes one click on any location row and a short dialog - name the office and set its normal-use radius in kilometres. From then on, every location row and map point shows how far it sits from the nearest office.

The tab opens with Recommended actions - candidates derived from what we observe, what Entra declares, and what you have already marked. A suggestion like "This looks like an office" comes with its evidence attached: dozens of users behind a handful of addresses, weekday-and-working-hours concentration, managed devices, sustained activity across many days. Accepting a suggestion opens the ordinary marking dialog, so you stay in control of the name and radius. The reverse direction exists too: "This office has gone quiet" flags marked offices with no recent activity.

Report a NetworkCopy Anchor Link

Next to the office button in every location drawer sits Classify network - the correction channel for the rare case where 1Security's classification or geolocation disagrees with what you know. Reclassify a network (whole network or just this location), correct the place, or record a judgment: Mark as expected quiets a network you trust (your red team's Tor exit, a contractor's VPN) without falsifying what it is, and Mark as suspicious flags an ordinary-looking network into the suspicious layer and policy reach.

Guardrails protect you from your own click: vendor-verified cloud networks and Tor cannot be reclassified wholesale, and a whole-network change touching many locations is refused with the count. Corrections about public networks can optionally be shared so classification improves for everyone - judgments and anything about your own infrastructure never leave your tenant. See Location Intelligence for the full rules.

The MapCopy Anchor Link

The Map tab draws every located place on a world map - point size follows activity, quiet locations fade, and clusters group nearby points until you zoom. Layers toggle offices (with their radius), the four access kinds described above, suspicious networks (VPN, Tor and hosting egress), and CA gaps - a ring around every location Conditional Access does not cover, covers only partly, or has never enforced at. A time-range control from 24 hours to all-time turns the map into an answer for "where were we being reached from last week?"

Zoom in and the base map keeps up: past country level the first-order regions appear - voivodeships, states, provinces, Länder - as a lighter dashed line under the country borders, and once a region is wide enough to carry a name, its name appears too. The same detail backs the small maps inside the drawers, so a location framed next to its office sits in a recognisable region rather than on an undivided country shape.

Colour on the map is the location's access kind: blue for places with active access, yellow for places that only ever saw sign-in attempts, green for automated identities working on their own, and grey for pure processing - Microsoft relays, meeting bots. Each is a layer you can switch off, with the number of places it holds; the sign-in-attempts and processing layers are the ones to hide when the question is "where do our people actually work from?", and the blue layer alone is the one to study when the question is "did anyone get in from somewhere they should not?". Suspicious networks (VPN, Tor, hosting egress) keep their red rim whatever their colour, so a blue dot with a red rim - real access through an anonymiser - stands out at a glance. A failed attempt never makes a place one of the targeted user's locations.

When a location list is set up, the map also carries a To review pill with a count: every place with active access the list does not permit gets a dashed red ring, and the tooltip of such a point shows a To review chip. Only to review fades everything else so those places carry the map - offices stay as reference geometry - which is the fastest way to see whether the three flagged places are three trips or one campaign.

One honesty rule keeps the map trustworthy: cloud providers shuffle IP ranges between datacenters faster than any geolocation database keeps up, so a datacenter or Microsoft point is pinned only where the provider's own published region data places it - Azure, AWS and Google Cloud all publish theirs. Hosting egress nobody publishes a location for still appears in the list with its best-known country, but never as a pin that could be hundreds of kilometres off.

The Conditional Access TabCopy Anchor Link

This tab is the observed-versus-declared comparison in one place. The headline strip summarises your configuration - enforcing policies, report-only policies, named locations and how many are trusted - next to the number that matters most: the share of sign-ins that completed with no policy applied.

Every observed location carries one coverage verdict - Not covered, Partly covered, Named, Trusted, or Undetermined - computed from the source addresses actually seen there, not from the policy's stated scope. Findings explain why a row deserves action: sign-ins with no enforcement, undeclared but active places, an office not trusted by any trusted range, a trusted range resolving to risky infrastructure, a range your egress has outgrown, country-only coverage, and more - each with a live count of the locations carrying it.

The Named locations sub-view turns the comparison around and starts from what you declared: ranges nothing has ever signed in from, named locations no enabled policy references, and ranges Microsoft returned in a form that could not be parsed - shown rather than silently swallowed.

Connecting the tab takes a single read-only re-consent (Policy.Read.All); the per-sign-in verdicts are already inside the logs 1Security ingests. Conditional Access itself requires Microsoft Entra ID P1 on the Microsoft side - if your tenant does not have it, 1Security says so plainly, and everything else on this screen keeps working.

Review - the Location ListCopy Anchor Link

The Review tab is where a breach shows up first, whatever got the attacker in: a session replayed from a hosting network after a proxied MFA prompt, a consented app's token used from another continent, a contractor working from a country you have no staff in. Keep an allow list of the countries, cities and Entra named locations people are expected to work from, or a block list of places nobody should sign in from - one or the other, never both. From then on, every location with active access the list does not permit is listed here for review, and the same event opens an incident on the Anomalies screen ("Active access from an unlisted location"), so the alerting, digests and triage you already have apply. The Alert rules link in the page header opens those rules - channels, digests, recipients - already filtered to locations.

Only active access counts. A password spray from an unlisted country proves nothing about where the company works, Microsoft's relays are not a place, and a private network has no country - none of those ever land on the review list.

Setting the list up is one click, not a form: start from the countries we already observe, from the cities we observe, from your Conditional Access named locations (country lists become countries, IP ranges match through the coverage stamp), or - for a block list - from every country never seen. Each source is staged with everything ticked; untick the odd one out and submit. Nothing exists until that submit - picking allow or block only opens the staged list, so you can open both to compare them and close either without leaving a list behind. Submitting sends your exclusions, so a source with more candidates than one screen still gets added in full. Single entries are added from a location's row or drawer at the granularity you choose - whole country, metro city or named location - or picked by name in the list dialog - any country, or any city in the world, with the places we already observe listed first - where every entry also has its own Remove.

The review list is per person: one row for each traveller and the place the list does not permit, with when they were there and for how long. The person and the place are the same clickable pills as everywhere else in 1Security, and the row itself opens the place (a By location view bundles the rows per place). Trip was fine on a row acknowledges that person's presence in the country up to now in one click. Allow… opens the decision dialog for that person, and on the location view the first action is Allow people…: it lists the people with active access there whom nothing permits yet, all ticked, and records a per-person decision at the width you choose (this city, the whole country or the named location). The default is Just this trip: it marks the access seen so far as reviewed and grants nothing for the future, so a review done weeks after the travel leaves no open door - if the same person turns up there again, the place is flagged again. The other choices are allowances for a period (30 or 90 days, a date, or open-ended), with an optional note. The place stays off the company list; the incident resolves because nobody unreviewed is left there, and the row reads "Permitted for named people". A large organisation therefore never ends up with an allow list that covers half the world, and a block list still means something. The tenant-wide entry is the second button ("Everyone…") and a link inside the dialog for the rare case where a place really is a new office. Allowances work the same on a block list (they permit named people despite the block), survive a mode switch, expire on their date and are listed under Per-person allowances in the list dialog, each with its own Remove.

Two more views answer the questions that come after the decision. Reviewed is every per-person allowance and acknowledgement ever taken - the person, the place, the decision and until when, who reviewed it and when - expired ones greyed rather than hidden, so "was this ever looked at?" always has an answer; each row has its own Remove, which re-flags the place for that person on their next active access there. History is the tenant-wide feed of everything that touched locations - list entries added or removed, the list switched on, off or between modes, allowances given or removed, offices marked, networks reported, response actions requested and comments - newest first, each naming who did it and when.

Respond - the same containment anomalies offerCopy Anchor Link

A flagged place is sometimes not a trip but a stolen session, and the answer is then not an allowance but a lock. Every By person row carries a Respond shield, every By location row and the location drawer a Respond button, offering the same curated containment actions an anomaly offers for a user: Block sign-in and Remove all licences. On a location it opens a dialog listing the people with active access from that place - on a flagged place, the ones no allowance covers - all ticked; untick the ones you trust, pick an action, and it runs for everyone still ticked, lands in the Action Center like any other action and is recorded in the location's history. Demo tenants run it simulated.

Allowing a place resolves its open incidents on its own; removing an entry re-opens them on the next active access. Switching between allow and block clears the entries, because an allow list read as a block list would block exactly where people work - the switch asks first. The verdict is also a column, a filter ("Location list") and a policy field (access_list_verdict), so a trend can watch it like any other finding.

History & CommentsCopy Anchor Link

Every location drawer has a History & Comments tab: the complete history of that place, newest first, with a composer at the top (Enter sends, Shift+Enter adds a line). Recorded on its own, without anyone typing: list entries added or removed that cover the place, the list switched on, off or between modes, per-person allowances and acknowledgements added or removed, the office marking, network reports - trusted or suspicious, a classification or a place correction - and every response action requested from here. A country-wide allowance shows on every location in that country, so a drawer always explains why its row stopped being flagged. Comments are for the rest: what you checked, who you asked, what you decided.

The tab badge and an Updates column on the Locations list show how many entries a place has. Many updates is itself a signal - real work was already done there - and the column sorts the "already handled" places out from the untouched ones at a glance.

Travel, Per User and Per DeviceCopy Anchor Link

Locations follow the identities that visit them. Inside every user and device drawer, a travel trail replays that identity's movement between places - each leg with the distance covered, the time gap, the speed that gap implies, and a verdict: plausible, improbable, or impossible travel. A leg flagged as impossible ("1,800 km in 40 minutes") is a stronger statement than any anomaly score, and it links straight to the exact events on both ends.

LicensingCopy Anchor Link

Everything on this screen runs on a standard Microsoft 365 license. Location resolution happens locally - no third-party IP lookup service ever sees your data - and requires no Entra ID P2 or premium sign-in log add-on. The one exception is the Conditional Access tab's Microsoft-side prerequisite described above, and that limit belongs to Conditional Access itself, not to 1Security.