In this module
EI1.7 Device and Location Signals
The DeviceDetail object
The DeviceDetail field in the sign-in log is a JSON object containing information about the device used for the authentication. For identity security, the critical sub-fields are:
operatingSystem — the operating system reported by the client: "Windows 11," "Windows 10," "macOS," "iOS," "Android," "Linux," or browser-derived values like "Chrome OS." This field is based on the user agent string and can be spoofed by a determined attacker, but it provides useful signal for pattern analysis. A user who normally signs in from Windows 11 suddenly appearing from Linux warrants investigation.
// EI1.7 — Device state analysis for all successful sign-ins
// Reveals which devices are managed, compliant, and registered
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend
DeviceOS = tostring(DeviceDetail.operatingSystem),
Browser = tostring(DeviceDetail.browser),
DeviceId = tostring(DeviceDetail.deviceId),
IsCompliant = tostring(DeviceDetail.isCompliant),
IsManaged = tostring(DeviceDetail.isManaged),
TrustType = tostring(DeviceDetail.trustType)
| extend DeviceState = case(
IsCompliant == "true", "Compliant",
IsManaged == "true" and IsCompliant != "true", "Managed (non-compliant)",
DeviceId != "", "Registered (unmanaged)",
"Unregistered"
)
| summarize
SignInCount = count(),
DistinctUsers = dcount(UserPrincipalName)
by DeviceState, DeviceOS
| order by SignInCount desc
// Review: What percentage of sign-ins come from compliant devices?
// "Unregistered" sign-ins = devices outside your management scope
// These are the sign-ins most vulnerable to token theftThe Location object
The Location field (also accessible as LocationDetails in KQL) is a JSON object containing geographic information derived from the IP address:
city — the approximate city. Accuracy varies — major cities are typically correct, but smaller locations and mobile networks may be inaccurate.
// EI1.7 — Geographic distribution of sign-ins
// Identifies countries and cities your users authenticate from
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| extend
Country = tostring(LocationDetails.countryOrRegion),
City = tostring(LocationDetails.city)
| summarize
SignInCount = count(),
DistinctUsers = dcount(UserPrincipalName),
Users = make_set(UserPrincipalName, 5)
by Country, City
| order by SignInCount desc
// Review: Are there countries you do not expect?
// A sign-in from a country where no employee is based = investigate
// Cross-reference with named locations in conditional access (EI3)// EI1.7 — Find sign-ins from unexpected countries
// Define your expected countries and find everything else
let expectedCountries = dynamic(["US", "GB", "CA"]); // Replace with your countries
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend Country = tostring(LocationDetails.countryOrRegion)
| where Country !in (expectedCountries)
| where isnotempty(Country)
| project
TimeGenerated, UserPrincipalName, AppDisplayName,
Country, City = tostring(LocationDetails.city),
IPAddress, RiskLevelDuringSignIn,
DeviceOS = tostring(DeviceDetail.operatingSystem)
| order by TimeGenerated desc
// Every result is a sign-in from outside your expected geography
// Not all are malicious (travel, VPN) — but all warrant reviewCombining device and location for security assessment
The most powerful sign-in log analysis combines device state with location to produce a trust assessment. Here are the patterns that experienced identity security engineers look for:
High trust (expected pattern): Compliant device + expected country + known IP range + low risk. This is a normal sign-in from a managed device in a familiar location. No action needed.
// EI1.7 — Trust assessment combining device and location
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend
Country = tostring(LocationDetails.countryOrRegion),
IsCompliant = tostring(DeviceDetail.isCompliant),
IsManaged = tostring(DeviceDetail.isManaged),
DeviceRegistered = isnotempty(tostring(DeviceDetail.deviceId))
| extend TrustLevel = case(
IsCompliant == "true" and Country in ("US", "GB"), "High",
IsManaged == "true" and Country in ("US", "GB"), "Medium",
DeviceRegistered and Country in ("US", "GB"), "Medium-Low",
Country in ("US", "GB"), "Low (unregistered device)",
"Investigate (unexpected country)"
)
| where TrustLevel has "Investigate" or TrustLevel has "Low"
| project
TimeGenerated, UserPrincipalName, AppDisplayName,
TrustLevel, Country,
DeviceOS = tostring(DeviceDetail.operatingSystem),
RiskLevelDuringSignIn
| order by TimeGenerated desc
// Results: sign-ins that warrant attention based on combined signals
// Adapt the country list and trust criteria to your environmentTry it yourself
Try It — Profile Your Device Landscape
Environment: Your M365 developer tenant with Sentinel workspace.
Exercise: Run the device state analysis query from above. Answer these questions:
1. What percentage of sign-ins are from compliant devices vs unregistered devices? In a developer tenant without Intune configured, most sign-ins will show as unregistered — this is expected. 2. What operating systems appear in your sign-in data? 3. Run the geographic distribution query. What countries show up? If you signed in from a VPN during the lab setup (EI0.9), you may see unexpected countries. 4. If you have access to a mobile device, sign in to Outlook from your phone and then check the sign-in log. Note the DeviceDetail differences between your desktop and mobile sign-ins.
This exercise establishes your personal device and location baseline — the reference point for recognizing anomalies in future modules.
The myth: The sign-in log shows the user signed in from Moscow. The user claims they were in London. The geolocation proves they are lying.
The reality: IP geolocation determines where the IP address is registered, not where the person is physically located. VPN services, corporate proxies, and mobile network gateways all produce IP addresses that geolocate to their exit point, not the user's physical location. A user in London using a VPN with a Russian exit node will produce a sign-in that geolocates to Russia. Conversely, an attacker in Russia using a VPN with a London exit node will produce a sign-in that geolocates to London. IP geolocation is a useful signal for identifying unexpected patterns, but it is not forensic evidence of physical location. The IR course covers how to correlate geolocation with other evidence for investigation-grade conclusions.
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
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