Office 365 login report
Every sign-in, with the city, the device and the policy that let it in.
A raw sign-in log is a timestamp and an IP address. In a typical tenant, hundreds of sign-ins a week come from VPNs, hosting networks or countries nobody in the company lives in - and an IP address alone cannot tell you which ones. 1Security resolves every sign-in to a country, city and network, joins the device that carried it, reads the Conditional Access verdict, and keeps it all for up to three years.
The problem
A sign-in log tells you when. You need where, and from what.
A sign-in export gives you a timestamp and an IP address. Then the reading starts: paste the IP into a lookup site, guess whether the ISP is a home connection or a rented server, and hope the device column means what you think it means. And a review that only reaches a few weeks back cannot answer a question from three months ago.
There is a trap most admins hit in the first week: many cloud actions arrive stamped with a service relay address instead of the user's own. Read the raw log and it looks like half your company works from a datacenter abroad. Teams either learn to ignore "foreign" sign-ins - or spend hours chasing phantom ones.
The device column is no better. A sign-in from an enrolled, compliant laptop and a sign-in from a machine your directory has never met look identical in an export. The second kind is exactly the one you were looking for.
In practice
One list. Where, from what device, under which policy.
How a login review runs in 1Security - no lookup sites, no CSV, no guessing.
- 01
Open Activity logs and filter to sign-ins
Pick a user, a date range, a country or a network type. Every row is a sign-in with its resolved location - country, city and the network behind it (home ISP, mobile carrier, corporate, cloud provider). Sort and filter live, export the whole list when the auditor wants the file.
- 02
Read the real origin, not the relay
Service relay traffic is recognised and labelled as such, VPN, Tor and hosting networks are called out, and the first time a user ever appears in a new place is flagged as first seen. In a typical mid-size tenant that turns thousands of IP rows into a few dozen named places you can actually read.
- 03
See the device on the same row
Each sign-in is joined to a device: enrolled and compliant, unregistered, or a shadow device that only ever showed up in activity. Filter to "unregistered device" and you get the machines that never enrolled - typically dozens in a tenant of a few hundred users - as a complement to what Intune already manages.
- 04
Check which policy governed it
The per-sign-in Conditional Access verdict travels inside the records 1Security ingests. The report shows which sign-ins completed with no policy in force at all - as a share of the tenant's traffic and per location - so the "are we actually covered" question is a number, not a hope.
What makes it work
Three parts of the platform, one login report.
The login report is a view over the same enriched activity every other screen in 1Security reads. Each part is documented in depth.
Locations
Country, city and network for every action, VPN / Tor / datacenter / Microsoft called out, first-seen detection and impossible-travel verdicts - resolved locally, no third-party lookup service.
See the feature →Conditional Access coverage
Your declared policies laid over the sign-ins actually observed: a coverage verdict per location and the share of traffic that walked in ungoverned.
See the feature →Devices, including unenrolled ones
Every sign-in joined to a device identity - registered, unregistered or shadow - with a real last-seen taken from activity, refreshed as the device is used.
See the feature →
FAQ
Common questions.
Do I need Entra ID P2 or the premium sign-in log add-on?
No. Location and device enrichment run inside 1Security on the records a standard tenant already produces, and history is kept for up to three years on a standard license. The one Microsoft-side prerequisite is that Conditional Access itself needs Entra ID P1 - if your tenant does not have it, the report still works, only the policy column stays empty.
Why does my current report show sign-ins from US datacenters?
Because many cloud actions carry a service relay address instead of the user's. 1Security recognises those ranges, labels that traffic as relay rather than as a foreign login, and prefers the real-country signal the sign-in record carries where it is available. A genuine sign-in from a rented server abroad stays fully visible.
How far back does the report go?
Up to three years of retained activity on a standard license - go from a few weeks of sign-in history to three years. A login review can cover the whole period an auditor asks about, and "last sign-in" per user comes from actual activity, refreshed as it happens.
Can I get last-login per user, not just a log?
Yes. The Users screen carries last sign-in and last activity per account, sortable - "last sign-in ascending" is the fastest way to find the accounts that should not exist any more, and it is the same one-click filter behind the dormant-account cleanup.
Stop pasting IP addresses into lookup sites.
Connect read-only and see your sign-ins with the city, the device and the policy verdict on every row the same day - and three years of them from then on.
Or keep guessing what an IP address means, row by row.