Login Geography in Google Workspace: The Security Signal Most Admins Never See
Google Workspace logs every sign-in with city, country, and IP. Most orgs never review it systematically. Here's how location-based security review actually works.
Google Workspace logs every sign-in attempt. The data is there — timestamps, IP addresses, cities, countries, failure reasons, device types. It's in the Admin Reports API, complete and accurate.
Most orgs never look at it in any structured way.
Not because they don't care. Because looking at it requires knowing where to look, drilling into individual user records in the Admin Console, and holding enough context in your head to know when something's anomalous. That's a lot of friction for a daily or weekly review habit.
The result: the signal gets lost. A credential attack that starts with three failed logins from a country your team doesn't operate in goes unnoticed for days.
Two Tabs, Two Questions
The Security Events dashboard has two tabs, and each one answers a different question.
The Events tab answers: what's happening right now, and to whom?
It's a timestamped feed filtered by default to notable events: failed sign-ins, suspicious sign-ins flagged by Google, and 2FA challenges. Each row shows the user, the event type, city and country, IP address, device type, and — for failures — the specific failure reason. You can widen the filter to all sign-ins, or narrow to a specific user.
The Login Locations tab answers: where is my org signing in from, and is that normal?
Instead of a timeline, it aggregates by geography: Country > Region > City. Each card shows how many successful sign-ins and how many failures came from that location, and when the last activity was.
This view makes patterns visible that the event feed hides. Ten scattered failed logins across a week look like noise in a timeline. In the location view, they stack up on one card labeled "Frankfurt, Germany" and become a finding.
The Label That Travels
The most operationally useful feature is location labeling. You mark a location as "safe" or "unsafe," and that label flows back into the Events tab.
Any event from a location marked unsafe gets flagged inline — an "Unsafe location" badge right next to the user email and timestamp. The analyst doesn't have to hold a mental map or cross-reference two tabs. The context travels with the data.
Mark your headquarters city as safe. Mark a country your team has never operated in as unsafe after you see suspicious activity from it. The label persists. The next person who opens the dashboard sees the same interpretation, without rebuilding it from scratch.
From Location to Account
When a location shows failed sign-ins, there's a drill-down. One click opens a list of exactly which user accounts had failures from that location.
That's the jump from "something's wrong in this region" to "these are the three accounts to investigate right now." Without that link, geography is just context. With it, it's an action queue.
What the Events Feed Filters
The default view filters to notable events. The full filter set covers:
- Notable events (default) — failures, 2FA challenges, and Google-flagged suspicious logins
- All sign-ins — the complete log, unfiltered
- Failed sign-ins — credential failures only
- Suspicious sign-ins — events Google has already flagged
- 2FA challenges — authentication challenges, useful for spotting phishing waves
The user filter applies on top of any of these — search by email to scope to a single account.
The Part That Surprised Us
We assumed the Events tab would be the primary view and Locations would be secondary. It turned out to be the other way around.
Most review sessions start in the Locations tab, because that's where you see the shape of the problem before drilling into specifics. The Events feed is where you go to confirm and act. The Locations view is where you notice something is wrong in the first place.
Good security tooling should surface anomalies before the analyst decides to go looking for them. The geographic aggregation does that in a way the raw event timeline doesn't.
What IT Support Can Do Here
IT Support role users have full access to the Security Events dashboard — both the Events tab and the Login Locations tab, including location labeling. They can mark locations as safe or unsafe. They can drill down to specific user accounts.
They cannot access the user's inbox, chat history, or execute transfers. The access boundary is between monitoring and action.
This is covered in more depth in the overview article: How to Give Your Helpdesk the Right Level of Google Workspace Access.