EI3.6 Device Conditions and Compliance

Device grant controls

Conditional access provides three device-related grant controls:

Require device to be marked as compliant: the strongest device control. The device must be enrolled in Microsoft Intune (or a third-party MDM that integrates with Entra ID) and must meet all assigned compliance policies. Compliance policies can require: disk encryption enabled, antivirus running and up to date, operating system version at or above a minimum, firewall enabled, no jailbreak/root detected, and custom compliance checks. A device that is enrolled but fails any compliance check is marked as non-compliant, and the conditional access policy blocks access.

This control provides the highest device assurance: you know the device is managed, patched, encrypted, and running security software. It is the recommended device control for accessing sensitive applications (Exchange Online, SharePoint, Azure Portal) and is required for all privileged users.

Require Hybrid Azure AD joined device, requires the device to be domain-joined to on-premises Active Directory AND registered with Entra ID through hybrid join. This control is specific to environments that use on-premises AD and is primarily relevant for organizations in hybrid configurations. It does not verify compliance, only that the device is hybrid-joined. A hybrid-joined device that is unpatched and unencrypted still satisfies this control.

Require Entra joined device, requires the device to be joined directly to Entra ID (cloud-native, no on-premises AD dependency). This is the modern equivalent of domain join for cloud-first organizations. Like hybrid join, this control verifies the join type but not compliance. For most organizations, "require compliant device" is preferable because it verifies both join status and security posture.

The compliance verification chain

When conditional access evaluates a device compliance requirement, the chain is: the device is enrolled in Intune → Intune evaluates the device against the assigned compliance policies → Intune reports the compliance status to Entra ID → Entra ID's conditional access reads the compliance status during sign-in evaluation → if compliant, access is granted; if not, access is blocked.

This chain means that Intune enrollment is a prerequisite for device compliance. If your organization has not deployed Intune, the "require compliant device" control will block all sign-ins because no device can report compliance. The deployment sequence is: deploy Intune → enroll devices → create compliance policies → verify devices are reporting compliance → then enable conditional access policies requiring compliance.

For organizations that do not have Intune, the device compliance control is not immediately available. The alternative is to use other controls: require Entra registration (weaker, only confirms the device is known, not its security posture), require an approved client app (limits to managed applications rather than managed devices), or use Conditional Access App Control through Defender for Cloud Apps (proxy-based session control that does not require device enrollment).

// EI3.6 — Device compliance status across sign-ins
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| extend 
    IsCompliant = tostring(DeviceDetail.isCompliant),
    IsManaged = tostring(DeviceDetail.isManaged),
    TrustType = tostring(DeviceDetail.trustType),
    DeviceOS = tostring(DeviceDetail.operatingSystem)
| extend DeviceStatus = case(
    IsCompliant == "true", "Compliant",
    IsManaged == "true", "Managed (non-compliant)",
    TrustType != "", "Registered (unmanaged)",
    "Unregistered")
| summarize 
    SignIns = count(),
    Users = dcount(UserPrincipalName)
    by DeviceStatus, DeviceOS
| order by SignIns desc
// Review: what percentage of sign-ins come from compliant devices?
// "Unregistered" sign-ins = devices outside your management scope
// Before enforcing device compliance, ensure all managed devices are reporting

Device filters

Device filters provide granular targeting based on device attributes, enabling policies that target specific device types without requiring separate policies for each. Device filters can match on: device name pattern, operating system version, device model, manufacturer, ownership type (company-owned vs personal), and extension attributes.

Common device filter scenarios:

Shared workstations, target devices with names matching a pattern (e.g., "KIOSK-" or "SHARED-") and apply specific session controls (sign-in frequency of every time, prevent persistent sessions).

Personal devices (BYOD), target devices with ownership type "Personal" and restrict to browser-only access with Conditional Access App Control (no native app access, no file downloads, session watermarking).

Legacy devices, target devices with operating system versions below a minimum threshold and block access or require additional controls.

Device filters use a rule-based syntax in the conditional access policy. The filter rule specifies the attribute, operator, and value, for example, device.operatingSystemVersion -startsWith "10.0.19" targets Windows 10 devices, or device.displayName -contains "KIOSK" targets kiosk devices.

Device compliance rollout approach

Deploying device compliance in conditional access is a phased process because it depends on Intune infrastructure:

Phase 1: Intune enrollment. Before any device compliance policy can work, devices must be enrolled in Intune. For Windows devices, this typically happens through Autopilot or Group Policy-based auto-enrollment. For macOS, through the Intune Company Portal. For iOS and Android, through the Company Portal app or Apple Business Manager / Android Enterprise. Track enrollment progress: the percentage of devices enrolled vs total devices is your readiness metric.

Phase 2: Compliance policy definition. Create Intune compliance policies that define what "compliant" means for your organization. At minimum: require disk encryption (BitLocker for Windows, FileVault for macOS), require antivirus (Defender for Windows), minimum OS version (prevents unpatched devices), firewall enabled, and no jailbreak/root. Each compliance check takes time to evaluate, newly enrolled devices may be non-compliant for 24-48 hours while Intune evaluates them.

Phase 3: CA policy in report-only. Deploy the conditional access policy requiring compliant devices in report-only mode. Monitor the report-only results to identify: devices that are enrolled but non-compliant (need remediation), users who sign in from unenrolled devices (need enrollment or exception), and applications that have compatibility issues with device compliance enforcement.

Phase 4: Enforce. After resolving the issues identified in report-only, promote the policy to enforcing. Monitor for access failures in the first 48 hours and have the helpdesk prepared to assist users whose devices are unexpectedly non-compliant.

The most common rollout mistake is enforcing device compliance before all managed devices are enrolled and reporting as compliant. This locks out users whose devices were supposed to be managed but were missed during enrollment. The report-only phase catches these gaps.

Environment: Your M365 developer tenant with Sentinel workspace.

Exercise: Run the device compliance status query above. In a developer tenant without Intune configured, most sign-ins will show "Unregistered", this is expected.

If you want to test device compliance: register your development device with Entra ID (Settings → Accounts → Access work or school → Connect) and optionally enroll it in Intune (if you have an Intune license, which is included in E5). After enrollment, check the sign-in logs: the DeviceDetail fields should now show isManaged and potentially isCompliant values.

Understanding the current device landscape is a prerequisite for designing device-based conditional access policies. You cannot enforce device compliance until devices are enrolled and compliance policies are defined in Intune.

What compliance checks should verify

The Intune compliance policies that feed the conditional access device compliance control should verify the security properties that matter for your threat model:

Disk encryption (BitLocker on Windows, FileVault on macOS) ensures that if the device is lost or stolen, the data on disk is not accessible without the encryption key. This is both a security control and a compliance requirement for most frameworks.

Antivirus/antimalware, specifically Microsoft Defender for Endpoint on Windows. The compliance check verifies that Defender is installed, running, and has definitions updated within a configurable timeframe. A device with disabled or outdated antivirus is a higher risk for malware-based token theft.

Minimum operating system version prevents unpatched devices from accessing sensitive applications. Set the minimum to the current supported version minus one (for example, if Windows 11 23H2 is current, allow 22H2 as the minimum). Devices below the minimum fail compliance until they are updated.

Firewall enabled, verifies the Windows Firewall or macOS firewall is active. A disabled firewall increases the device's exposure to network-based attacks.

No jailbreak/root, for iOS and Android devices, verifies the device has not been jailbroken or rooted. Jailbroken devices have weakened security controls that can be exploited for credential theft.

The compliance check is not instant. Intune evaluates device compliance on a schedule (every 8 hours by default for existing devices, more frequently for newly enrolled devices). A device that becomes non-compliant (for example, antivirus definitions expire) remains "compliant" in Entra ID until the next evaluation cycle. The compliance evaluation delay means there is a window where a non-compliant device can still access resources, this is an accepted limitation of the compliance model.

// EI3.6 — Find sign-ins from non-compliant devices accessing sensitive apps
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| where AppDisplayName in ("Office 365 Exchange Online", 
    "Office 365 SharePoint Online", "Microsoft Teams")
| extend IsCompliant = tostring(DeviceDetail.isCompliant)
| where IsCompliant != "true"
| summarize count(), Users = make_set(UserPrincipalName, 10)
    by IsCompliant, tostring(DeviceDetail.operatingSystem)
// Non-compliant or unknown devices accessing sensitive apps
// If your policy should require compliance, these are the gaps
// "null" or empty = unregistered device (not enrolled in Intune)
// "false" = enrolled but failing a compliance check

The reference above captures the operational configuration. The principle below crystallises the design decision.