Device and Location Signals

The DeviceDetail object

The DeviceDetail field in every sign-in log entry is a JSON object with seven properties. For identity security, five of them carry operational weight.

operatingSystem reports the OS derived from the user agent string — "Windows 11," "Windows 10," "macOS," "iOS," "Android," "Linux," or browser-derived values like "Chrome OS." This field can be spoofed by a determined attacker because it comes from the user agent, but it provides useful signal for pattern analysis. A user who normally signs in from Windows 11 suddenly appearing from Linux warrants investigation — not because Linux is suspicious, but because the change from established pattern is.

browser reports the browser and version — "Edge 131," "Chrome 125," "Safari 17.4," "Firefox 128." Like operatingSystem, it's user-agent-derived and spoofable, but unexpected browser changes correlate with account compromise. An attacker replaying a stolen token from their own machine typically produces a different browser version than the legitimate user's device. The discrepancy is subtle — "Chrome 125" versus "Chrome 122" — but when combined with an unfamiliar IP address, it's a high-confidence indicator.

deviceId is the Entra ID device registration identifier. This field is populated only when the device is registered with Entra ID — Entra joined, hybrid Entra joined, or Entra registered. An empty deviceId means the device is not registered, which matters for Conditional Access: policies that require device registration, compliance, or managed device status will not apply to sign-ins from unregistered devices. If a sign-in succeeds with an empty deviceId and your policies should require device registration, you have a policy gap.

isCompliant indicates whether the device meets the compliance policies configured in Intune. true means the device is enrolled in Intune and meets all assigned compliance requirements — encryption enabled, antivirus running, OS version current, firewall active. false means the device is enrolled but fails one or more compliance checks. Null or empty means the device is not enrolled in Intune at all. For Conditional Access policies that require compliant devices, this is the enforcement signal.

isManaged indicates whether the device is managed by a device management solution — Intune or a third-party MDM. Related to but distinct from isCompliant: a managed device may not be compliant (enrolled but failing a compliance check), and a compliant device is always managed (you can't pass compliance checks without being enrolled). An unmanaged device is outside your organization's control entirely.

trustType records the device registration type: "Azure AD joined" for Entra joined devices (cloud-native, organization-owned), "ServerAD" for hybrid Entra joined (domain-joined and cloud-registered), "Workplace" for Entra registered (typically personal BYOD devices), or empty for unregistered devices. This field determines which Conditional Access device conditions apply — some policies target specifically Entra joined versus hybrid joined versus registered devices.

Here is what the DeviceDetail looks like for a compliant, Entra-joined device:

{
  "deviceDetail": {
    "deviceId": "8a4f2e6c-1d3b-4a7f-9e2c-5b8d0f3a1e7c",
    "displayName": "LAPTOP-PS01",
    "operatingSystem": "Windows 11",
    "browser": "Edge 131.0.2903",
    "isCompliant": true,
    "isManaged": true,
    "trustType": "Azure AD joined"
  }
}

Every field is populated. The device is Entra joined, managed by Intune, and compliant with all assigned policies. This is the highest device trust state — a Conditional Access policy requiring compliant devices will show success for this sign-in. Now compare an unregistered personal device:

{
  "deviceDetail": {
    "deviceId": "",
    "displayName": "",
    "operatingSystem": "iOS 18.2",
    "browser": "Safari 18.2",
    "isCompliant": null,
    "isManaged": null,
    "trustType": ""
  }
}

Empty deviceId, empty trustType, null compliance and management fields. This is a personal device that has never been registered with Entra ID. It's invisible to Intune, has no compliance state, and cannot satisfy any Conditional Access policy that requires device registration, compliance, or management. If your policies should block access from unregistered devices to sensitive applications and this sign-in succeeded, you have a coverage gap — the same type of gap the query in Section 1.5 detects at the policy level.

The LocationDetails object

The LocationDetails field is a JSON object containing geographic information derived from the sign-in's IP address. Four sub-fields matter for security analysis.

countryOrRegion is the two-letter ISO country code — US, GB, DE, JP. This is the most reliable geographic field because IP-to-country mapping is significantly more accurate than IP-to-city. Most organizations operate in a defined set of countries. A sign-in from a country not in that set is a strong anomaly signal — not conclusive (users travel, VPNs exit in unexpected countries), but worth investigating when combined with other signals from Sections 1.4 through 1.6.

city and state provide finer geographic context. Accuracy varies — major metropolitan areas are typically correct, but smaller locations and mobile network gateways can be inaccurate by dozens of miles. Use these fields for pattern analysis, not for forensic location determination.

geoCoordinates provides latitude and longitude. This is the foundation for impossible travel detection — Identity Protection calculates the distance between consecutive sign-in locations and flags impossible travel when the distance exceeds what physical travel would allow in the elapsed time.

IPAddress is the public IP address of the sign-in. This is the raw network identifier — the field you use for IP reputation lookups, corporate IP range matching, and named location correlation. The NetworkLocationDetails array (when populated) shows whether the IP matched a named location defined in Conditional Access, which is how CA knows whether a sign-in came from a "trusted" location.

Querying device state across your tenant

The device state distribution query tells you what percentage of sign-ins come from compliant, managed, registered, and unregistered devices — the device security posture of your entire tenant in one result set.

// Device state distribution across all successful sign-ins
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend
    DeviceOS = tostring(DeviceDetail.operatingSystem),
    IsCompliant = tostring(DeviceDetail.isCompliant),
    IsManaged = tostring(DeviceDetail.isManaged),
    DeviceId = tostring(DeviceDetail.deviceId)
| extend DeviceState = case(
    IsCompliant == "true", "Compliant",
    IsManaged == "true" and IsCompliant != "true", "Managed (non-compliant)",
    DeviceId != "", "Registered (unmanaged)",
    "Unregistered")
| summarize
    SignIns = count(),
    Users = dcount(UserPrincipalName)
    by DeviceState, DeviceOS
| order by SignIns desc

The "Unregistered" row is your device security gap. Every sign-in from an unregistered device is from a device your organization doesn't control — no compliance enforcement, no management policies, no encryption verification. In a developer tenant without Intune configured, most sign-ins will show as unregistered, which is expected. In a production tenant, the ratio between compliant and unregistered tells you how much of your access surface is outside your device security boundary. EI6 teaches device compliance policies. EI4 teaches the CA policies that enforce them.

Finding sign-ins from unexpected countries

The geographic distribution query answers the question: where are your users authenticating from, and does the answer match what you expect?

// Sign-ins from countries outside your expected operating geography
let expectedCountries = dynamic(["US", "GB", "CA"]);
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
// Replace the expectedCountries list with your organization's operating countries.
// Every result warrants review — not all are malicious (travel, VPN),
// but all represent sign-ins from outside your expected geography.

Every result from this query is a sign-in from a country where your organization doesn't expect user activity. Some will be legitimate — users traveling, corporate VPN exit nodes in unexpected countries, mobile networks routing through regional gateways. Others will be the first sign of credential compromise. The triage decision uses the other fields you've learned in this module: check the RiskLevelDuringSignIn from Section 1.6 (was the sign-in flagged?), the AuthenticationDetails from Section 1.4 (was MFA actively completed or satisfied by claim?), and the ConditionalAccessStatus from Section 1.5 (did any policy evaluate?). A sign-in from an unexpected country that also shows high risk, MFA satisfied by claim, and no CA evaluation is a strong compromise indicator.

Combining device and location for trust assessment

The most powerful analysis combines device state with location to produce a composite trust score. The pattern is straightforward: a compliant device from a trusted location is high trust. An unregistered device from an unexpected country with risk signals is investigate-immediately.

A compliant device from an expected country with no risk signals is your normal operating pattern — no action needed. A managed but non-compliant device from an expected country is a compliance remediation task, not a security incident — the user needs to update their device or resolve the compliance failure. A registered but unmanaged device from an expected country is a BYOD access pattern that your Conditional Access policies should address in EI4. An unregistered device from an unexpected country with medium or high risk is the pattern that warrants immediate investigation — the combination of uncontrolled device, unexpected geography, and risk signals is the strongest non-alert indicator of compromise.

Record your device state distribution and your geographic distribution now. These are your device and location baselines. Every change you make in EI4 (device compliance CA policies), EI6 (device compliance configuration), and EI3 (named locations and country-based CA policies) should shift these numbers measurably. The "Unregistered" count should decrease as you roll out device enrollment. The unexpected-country count should decrease as you deploy named location restrictions. If a control deployment doesn't change the numbers, it isn't working as intended.