What can login history show?¶
title: What can login history show? subtitle: It can show an account-access attempt and the context recorded by the provider, not the physical identity of the person behind it. slug: what-can-login-history-show series: email-evidence section: provider-and-account-records card_type: question_card pathway_order: 32 section_order: 4 status: draft public_safe: true video_ready: true word_count: 593 estimated_read_time_seconds: 245 audiences: - investigator - supervisor - fraud and compliance practitioner tags: - email evidence - login history - sign-in logs - IP address - authentication sources: - title: 'Microsoft Learn: Sign-in log activity details' url: https://learn.microsoft.com/en-us/entra/identity/monitoring-health/concept-sign-in-log-activity-details - title: 'Microsoft Learn: Track identity activities with linkable identifiers' url: https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-track-linkable-identifiers - title: 'Google Account Help: See devices with account access' url: https://support.google.com/accounts/answer/3067630?hl=en-GB - title: 'Google Account Help: Secure a hacked or compromised Google Account' url: https://support.google.com/accounts/answer/6294825?hl=en-GB
What can login history show?¶
It can show an account-access attempt and the context recorded by the provider, not the physical identity of the person behind it.
Script¶
Login history can be a very useful part of an email enquiry.
It may show that an account was accessed or that an access attempt was made at a particular time, using a particular application and network connection.
It still doesn’t automatically identify the person behind the activity.
A provider sign-in record may contain:
the account or user ID;
date and time;
success or failure;
source IP address;
approximate location;
browser or client application;
operating system;
device identifier or management state;
authentication method;
multi-factor result;
session or token identifiers;
and security-policy or risk information.
That can help answer several questions.
Was the account active around the time the email was sent?
Did access come from a familiar device or application?
Was there a new or unusual network address?
Did the provider challenge the sign-in?
Was multi-factor authentication used?
Did several failed attempts precede a successful one?
Can the sign-in be linked to later mailbox or sending activity through a session or token identifier?
But keep each field within its limits.
An IP address identifies a network connection seen by the provider.
It may belong to home broadband, mobile data, a workplace, public Wi-Fi, a VPN, a proxy or a provider gateway.
The location shown in the sign-in portal is usually an estimate derived from the IP address. It isn’t GPS evidence and may be far from the device’s physical location.
Mobile networks and VPNs can make a routine sign-in appear to come from another city or country.
Device information may describe the browser, operating system or registered device associated with the request.
A device name can be user-supplied.
A device ID may show that the provider recognised a registered or managed device, but it doesn’t prove who was holding it at that moment.
A successful password and multi-factor event may strengthen the link to the account holder.
It still needs interpretation.
A code may have been intercepted.
A push notification may have been approved without understanding it.
A trusted device or existing session may avoid another challenge.
A connected application may use a token.
Look at the whole sequence rather than one event.
Compare the sign-in with:
the email submission or message-trace time;
session and token activity;
mailbox audit;
device records;
security alerts;
password or recovery changes;
and other messages sent during the same period.
Also look at normal account behaviour.
An unfamiliar IP address may be suspicious, or it may be a normal result of travel, roaming, home-address changes or privacy services.
A familiar address may be used by several people or by an intruder on the same network.
The absence of a sign-in at the exact sending time doesn’t prove the user was absent.
The account may already have had an active session.
The common mistake is:
“This login geolocates to the suspect’s town, so the suspect sent the email.”
That combines an estimated network location with a human conclusion the record doesn’t contain.
Another mistake is:
“There was no new login, so the account couldn’t have been compromised.”
Existing sessions, delegated users, tokens and connected applications may create activity without a fresh interactive login.
A careful conclusion might say:
“The provider recorded a successful sign-in to this account using this application, IP address and device identifier. The same session or related account activity was recorded around the time the message was sent.”
Then explain what evidence links that session to a device or person.
Login history is evidence of account access.
It becomes evidence about a person only when the network, device, authentication and wider context support that next step.
Key takeaway
A login record links an account, time, application and network context. It needs session, device and activity evidence before it becomes a conclusion about a person.
Related questions¶
- What account-access records may exist?
- What records may link an email account to a device or recovery account?
- What if the sender’s account was compromised?
- Can an email identify the person who wrote it?
Source notes¶
- Microsoft Learn: Sign-in log activity details
- Microsoft Learn: Track identity activities with linkable identifiers
- Google Account Help: See devices with account access
- Google Account Help: Secure a hacked or compromised Google Account