In this module
EI1.1 Anatomy of a Sign-In Log Entry
The sign-in log as your primary instrument
Every identity security operation in this course — every policy verification, every anomaly detection, every attack indicator — depends on the sign-in log. It is the single data source that records every authentication attempt against your Entra ID tenant. Before you deploy conditional access policies (EI3), before you configure Identity Protection (EI5), before you build detection rules (EI13), you need to read sign-in logs the way a pilot reads instruments: fluently, without hesitation, knowing what each indicator means and what action each value demands.
The Entra ID sign-in log records every authentication event — successful and failed, interactive and non-interactive, user and service principal. A typical M365 tenant with 1,000 users generates thousands of sign-in events per day. The volume is not the challenge. The challenge is knowing which fields matter for security, what the values mean in context, and how to query the data at scale.
There are four separate sign-in log tables in Entra ID, each recording a different category of authentication event. This subsection covers the fields that are common across all four tables. Subsequent subsections cover the differences between the log types and the specialized fields in each.
The fields that answer security questions
Every sign-in log entry contains dozens of fields, but for identity security work, a core set answers the questions that matter. Here is each field, what it contains, and the security question it answers.
UserPrincipalName is the identity that authenticated — the email address format (user@domain.com) that uniquely identifies the account. This answers the most basic question: whose account was used? In a compromise investigation, this is the starting point for every query. Note that this field reflects the account as it exists in the directory, not necessarily the email address the user typed at the login page — if the user has aliases, the UPN is the canonical identifier.
The first query: reading your own sign-in log
Before diving deeper into the specialized fields, run this query in your Sentinel workspace to see the core fields for recent sign-ins in your developer tenant:
// EI1.1 — Core sign-in log fields for security assessment
// Run this in your Sentinel workspace (Logs blade)
// Requires: diagnostic settings configured (EI0.9)
SigninLogs
| where TimeGenerated > ago(24h)
| project
TimeGenerated,
UserPrincipalName, // WHO — which account
AppDisplayName, // WHAT — which application
IPAddress, // WHERE — source IP
Location = tostring(LocationDetails.city), // WHERE — city
Country = tostring(LocationDetails.countryOrRegion), // WHERE — country
DeviceOS = tostring(DeviceDetail.operatingSystem), // HOW — device OS
ClientApp = ClientAppUsed, // HOW — client type
ResultType, // OUTCOME — success/failure code
ConditionalAccessStatus, // OUTCOME — CA decision
RiskLevelDuringSignIn, // RISK — real-time risk
AuthenticationRequirement // HOW — single factor or MFA
| order by TimeGenerated desc
| take 50Run this query and examine the results. Every row is a sign-in event. Every column is a security signal. By the end of this module, you will be able to look at any row and immediately assess whether it is normal, suspicious, or a confirmed indicator of compromise.
Try it yourself
Try It — Read Your First Sign-In Log Entry
Environment: Your M365 developer tenant with Sentinel workspace (configured in EI0.9).
Exercise: Run the query above in your Sentinel workspace. Find a sign-in event for your admin account. For that single event, answer these questions:
1. What application were you accessing? (AppDisplayName) 2. What IP address did the sign-in come from? (IPAddress) 3. What device were you using? (DeviceOS) 4. Was the sign-in evaluated by conditional access? (ConditionalAccessStatus) 5. Was the sign-in flagged as risky? (RiskLevelDuringSignIn) 6. Was MFA required? (AuthenticationRequirement)
If any of these fields is empty or null, that is information too — it tells you that the data source for that field is not configured or that the sign-in type does not populate that field. EI1.2 explains which log types populate which fields.
The myth: Our security team reviews the sign-in logs every Monday. We will see any suspicious activity during the weekly review.
The reality: The AiTM attack in EI0.8's case study 1 progressed from initial access to BEC wire fraud in under thirty minutes. A weekly log review would discover this attack four to seven days after the $47,000 payment was sent to the attacker. By that point, the money is unrecoverable, the attacker's persistence mechanisms are deeply embedded, and the investigation scope has expanded significantly. Sign-in log monitoring must be real-time — through Sentinel analytics rules that fire on suspicious patterns as they occur (EI13), not through manual human review on a weekly schedule. Manual review is useful for posture assessment and trend analysis (EI14), but it is not a detection mechanism.
A sign-in log shows a successful authentication from an IP in a country where NE has no employees. MFA was satisfied by push notification. The user says they approved the MFA prompt while traveling. Do you accept this explanation?
Verify, do not accept at face value. Check: does the user have a travel request on file? Does the IP geo-location match the claimed travel destination? Does the device fingerprint match the user's enrolled device? Are there other sign-ins from NE's corporate IP in the same time window (which would indicate the user is NOT traveling)? An attacker who stole credentials and is bombarding the user with MFA prompts (MFA fatigue) gets the same 'I approved it' response from a confused user. The investigation confirms or refutes the travel explanation within 5 minutes.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
- 17 engineering modules — authentication methods, conditional access architecture, Identity Protection, PIM, token protection, application governance, and detection rules
- The Defense Design Method — the six-step framework applied to every identity control you'll build
- EI18 Capstone — Identity Security Architecture Design — design complete identity architectures for three realistic organisations (SMB, mid-market, regulated enterprise)
- Identity Security Toolkit lab pack — deployable conditional access policies, PIM configurations, and Identity Protection risk rules
- Cross-domain detection (EI16) — email-to-identity correlation and the full phishing-to-inbox-rule attack chain