MSA3.5 Device-Based Conditional Access Policies

Device-based CA policies are the most common source of "it doesn't work as expected" because the dependency chain is longer than any other CA control. Authentication strength requires passkeys to be registered, one dependency. Device compliance requires: (1) devices enrolled in Intune, (2) compliance policies defined in Intune, (3) devices evaluated against those policies, (4) compliance status synced to Entra ID, and (5) the CA policy referencing that status. If any link breaks. Intune service outage, compliance policy not assigned to a device group, sync delay: the device appears non-compliant and the CA policy blocks access. This sub teaches the dependency chain end-to-end so you can design device policies that are robust, not fragile.

Estimated time: 50 minutes.

The Intune dependency chain, what "compliant" actually means

When a CA policy requires "Require device to be marked as compliant," Entra ID checks a single boolean property on the device object: isCompliant. This property is set by Intune after the device is evaluated against a compliance policy. If the property is true, the device passes. If false or null (device not enrolled), the device fails.

The chain that produces this boolean has six links. If any link breaks, every device appears non-compliant and every user is blocked.

STEP    SYSTEM        ACTION                            FAILURE MODE
------  ----------    --------------------------------  --------------------------
  1     Admin         Create compliance policy in       No evaluation criteria →
                      Intune (OS version, encryption,   all devices non-compliant
                      password, antivirus, etc.)

  2     Admin         Assign compliance policy to a     Unassigned devices aren't
                      device group in Intune            evaluated → non-compliant

  3     Device        Enrol in Intune (auto-enrol       Unenrolled devices have
                      via Entra join, or manual)        isCompliant = null → fail

  4     Intune        Evaluate device against the       Failed evaluation =
                      assigned compliance policy        isCompliant = false

  5     Intune→Entra  Sync compliance status to the     Sync delay (up to 30 min)
                      device object in Entra ID         → temporary false negative

  6     Entra CA      CA policy checks device.          null or false = device
                      isCompliant                       blocked by CA policy

The most common failure. Step 1: An admin creates a CA policy requiring device compliance without first creating a compliance policy in Intune. Without a compliance policy, Intune has no criteria to evaluate: every device defaults to non-compliant. The CA policy blocks every user. The helpdesk receives hundreds of "I can't sign in" tickets. The fix: always create and assign the Intune compliance policy before enabling the CA policy that references it.

The second most common failure. Step 2: The compliance policy exists but isn't assigned to the device group that contains the user's device. The device is enrolled in Intune (Step 3 passes) but has no policy to evaluate against. Intune treats it as non-compliant.

Run this verification before deploying any device-based CA policy:

Connect-MgGraph -Scopes "Device.Read.All"

$devices = Get-MgDevice -All -Property DisplayName, OperatingSystem, TrustType,
  IsCompliant, IsManaged, ApproximateLastSignInDateTime

$total = $devices.Count
$compliant = ($devices | Where-Object { $_.IsCompliant -eq $true }).Count
$managed = ($devices | Where-Object { $_.IsManaged -eq $true }).Count
$entraJoined = ($devices | Where-Object { $_.TrustType -eq "AzureAd" }).Count
$hybridJoined = ($devices | Where-Object { $_.TrustType -eq "ServerAd" }).Count
$registered = ($devices | Where-Object { $_.TrustType -eq "Workplace" }).Count
$unregistered = $total - $entraJoined - $hybridJoined - $registered

Write-Host "=== DEVICE COMPLIANCE VERIFICATION ==="
Write-Host "Total devices:     $total"
Write-Host ""
Write-Host "[Step 3] Enrolment:"
Write-Host "  Entra joined:    $entraJoined"
Write-Host "  Hybrid joined:   $hybridJoined"
Write-Host "  Registered:      $registered"
Write-Host "  Unregistered:    $unregistered (can't satisfy device compliance)"
Write-Host ""
Write-Host "[Step 4-5] Compliance:"
Write-Host "  Managed (Intune): $managed ($([math]::Round($managed/$total*100,1))%)"
Write-Host "  Compliant:        $compliant ($([math]::Round($compliant/$total*100,1))%)"
$managedNotCompliant = $managed - $compliant
Write-Host "  Managed but NOT compliant: $managedNotCompliant"
if ($managedNotCompliant -gt 0) {
  Write-Host "    (Check Intune: these devices are enrolled but failing compliance."
  Write-Host "     Common causes: OS not updated, encryption not enabled, no antivirus.)"
}
Write-Host ""

# Stale devices (not signed in for 90+ days)
$stale = ($devices | Where-Object {
  $_.ApproximateLastSignInDateTime -and
  $_.ApproximateLastSignInDateTime -lt (Get-Date).AddDays(-90)
}).Count
Write-Host "Stale (90+ days no sign-in): $stale"
Write-Host "  (Consider cleaning stale devices to keep the inventory accurate)"

# Platform distribution
Write-Host ""
Write-Host "Platform distribution:"
$devices | Group-Object OperatingSystem | Sort-Object Count -Descending |
  Select-Object @{N='OS';E={$_.Name}}, Count | Format-Table -AutoSize

if ($compliant -eq 0) {
  Write-Host ""
  Write-Host "⚠ ZERO compliant devices."
  Write-Host "  Dependency chain check:"
  Write-Host "  [Step 1] Do Intune compliance policies exist?"
  Write-Host "    → Intune admin center → Devices → Compliance policies"
  Write-Host "  [Step 2] Are policies assigned to device groups?"
  Write-Host "    → Click each policy → Assignments → verify group(s)"
  Write-Host "  [Step 3] Are devices enrolled in Intune?"
  Write-Host "    → Managed count = $managed (0 = no enrollment)"
  Write-Host "  DO NOT deploy device compliance CA policies until all 3 pass."
}

Reading your results: A developer tenant with no Intune configuration shows Compliant: 0. That's expected: the query and the verification logic are the skills to build. In production, the key metric is the ratio of Managed to Compliant. If 500 devices are managed but only 300 are compliant, 200 devices are failing compliance checks, check Intune for the specific failures (OS update missing, encryption not enabled, etc.). If you deploy a CA policy requiring compliance with 200 non-compliant managed devices, those 200 users are blocked.

Pre-deployment check. Intune readiness verification

Before creating any device compliance CA policy, verify every link in the dependency chain. This checklist prevents the most common deployment failure (blocking everyone because Intune isn't configured):

Write-Host "=== DEVICE CA READINESS CHECKLIST ==="
Write-Host ""

# Check 1: Do devices exist in Entra ID?
$deviceCount = (Get-MgDevice -All).Count
Write-Host "[1] Devices in Entra ID: $deviceCount"
if ($deviceCount -eq 0) {
  Write-Host "    ⚠ BLOCKER: No devices registered. Enrol devices before deploying."
}

# Check 2: Are devices managed by Intune?
$managed = (Get-MgDevice -All -Property IsManaged |
  Where-Object { $_.IsManaged -eq $true }).Count
Write-Host "[2] Intune-managed devices: $managed / $deviceCount"
if ($managed -eq 0) {
  Write-Host "    ⚠ BLOCKER: No managed devices. Deploy Intune enrollment first."
}

# Check 3: Are devices compliant?
$compliant = (Get-MgDevice -All -Property IsCompliant |
  Where-Object { $_.IsCompliant -eq $true }).Count
Write-Host "[3] Compliant devices: $compliant / $managed"
if ($compliant -eq 0 -and $managed -gt 0) {
  Write-Host "    ⚠ BLOCKER: Devices are managed but not compliant."
  Write-Host "    Create and assign Intune compliance policies before deploying CA."
}

# Check 4: Are break-glass accounts excluded?
$bgGroup = Get-MgGroup -Filter "displayName eq 'SG-CA-Exclude-BreakGlass'" -ErrorAction SilentlyContinue
Write-Host "[4] Break-glass exclusion group: $(if ($bgGroup) { '✓ Exists' } else { '⚠ MISSING' })"

# Overall readiness
$ready = $deviceCount -gt 0 -and $managed -gt 0 -and $compliant -gt 0 -and $bgGroup
Write-Host ""
if ($ready) {
  Write-Host "✓ READY to deploy device compliance CA policies."
  Write-Host "  $compliant of $deviceCount devices are compliant."
  Write-Host "  Deploy in report-only for 14 days to verify impact."
} else {
  Write-Host "✗ NOT READY. Resolve blockers above before deploying."
  Write-Host "  Deploying device compliance CA without Intune readiness"
  Write-Host "  blocks every user because no device can satisfy the grant."
}

The device compliance CA policy. OR vs AND

The grant control for device-based policies uses one of two operators, and the choice determines whether device compliance is a requirement or a preference. Getting this wrong either locks out your workforce (AND when it should be OR) or weakens your admin security (OR when it should be AND).

OR ("Require one of the selected controls"): The user must satisfy ANY ONE of the listed controls, compliant device, hybrid-joined device, or MFA. This is the standard user model. If they're on a compliant device, the device satisfies the grant: no MFA prompt. If they're on an unmanaged device, MFA is the fallback. The OR model treats device compliance as a preferred signal that earns a frictionless experience, not as a hard requirement that blocks non-compliant access.

AND ("Require all of the selected controls"): The user must satisfy ALL listed controls. Compliant device AND MFA. Both required, no fallback. This is the admin model, but in practice, the admin tier achieves AND through separate policies (a grant policy for MFA + a block policy for non-compliant devices) rather than a single AND policy. The block policy approach is cleaner because each policy has a single purpose: one enforces the method, the other enforces the device.

Worked scenario. OR logic (standard user)

SOC Analyst 2 (L1 SOC analyst at NE) signs in to Outlook from her Intune-managed, compliant Windows laptop.

1. CA evaluates: user = All users (matches baseline + device policy). App = Exchange Online.
2. Device policy grant: compliant device OR hybrid joined OR MFA. Operator = OR.
3. The user's device is compliant (device.isCompliant = true). One OR condition satisfied.
4. Baseline policy grant: authentication strength (standard MFA). their passkey satisfies this.
5. Combined result: access granted. The user sees a seamless sign-in: the compliant device satisfied the device policy, and her passkey (used for the baseline) satisfied the MFA requirement. If system-preferred authentication presented the passkey (MSA2.4), both are satisfied in one step.

Now the user signs in from her personal Android phone (not enrolled in Intune, not registered in Entra):

1. CA evaluates: same user, same app, but device is unregistered. device.isCompliant = null, device.trustType = null.
2. Device policy: compliant device OR hybrid joined OR MFA. Device compliance fails (null ≠ true). Hybrid join fails (null ≠ "ServerAd"). MFA is the remaining OR option.
3. The user is prompted for MFA. She completes it with her passkey.
4. Baseline MFA is also satisfied by the same passkey authentication.
5. Combined result: access granted after MFA. The user can check email on her personal phone, she just has to complete MFA instead of getting the frictionless compliant-device experience.

The architectural effect: The OR model creates a soft incentive for device enrollment without punishing BYOD. Users notice that their work laptop "just works" while their phone prompts for MFA every time. When the helpdesk explains "enrol your phone in Intune and the MFA prompt goes away," the adoption incentive is built into the authentication experience.

Worked scenario. AND logic (admin)

the security architect (Security Architect at NE, in the Admin persona group) signs in to the Azure portal from his managed, compliant laptop.

1. CA evaluates: user = SG-CA-Persona-Admins, app = Azure portal (matches admin tiered policies).
2. Admin Policy 1: phishing-resistant MFA required. Admin Policy 2: block if not compliant.
3. Marcus's device is compliant. He authenticates with his FIDO2 key (phishing-resistant).
4. Result: access granted. Both controls satisfied.

Now Marcus tries from his personal iPad (not enrolled in Intune):

1. CA evaluates: user = Admin, app = Azure portal.
2. Admin Policy 2: device filter matches (not compliant, not hybrid joined) → BLOCK.
3. Result: blocked. It doesn't matter that Marcus has a FIDO2 key. The block policy overrides any grant. Marcus cannot access the Azure portal from a personal device, period.

The AND model for admins is achieved through separate policies, not a single policy with AND operator. Policy 1 (phishing-resistant MFA) is a grant policy. Policy 2 (block unmanaged) is a block policy. Because block overrides grant (MSA3.1 resolution model), the admin must satisfy the grant control AND not trigger the block. This is functionally equivalent to AND logic but uses two policies instead of one, which is cleaner because each policy has a single purpose.

# Standard user policy: compliant device OR MFA
$mfaStrengthId = ((Invoke-MgGraphRequest -Method GET `
  -Uri "https://graph.microsoft.com/v1.0/identity/conditionalAccess/authenticationStrength/policies?`$filter=policyType eq 'builtIn'" `
  -OutputType PSObject).value |
  Where-Object { $_.displayName -eq "Multifactor authentication" }).id

$standardDevicePolicy = @{
  displayName = "CA-All-RequireCompliantOrMFA-AllApps"
  state = "enabledForReportingButNotEnforced"
  conditions = @{
    users = @{
      includeUsers = @("All")
      excludeGroups = @(
        $bgId,
        $adminGroupId
      )
    }
    applications = @{ includeApplications = @("All") }
  }
  grantControls = @{
    builtInControls = @("compliantDevice", "domainJoinedDevice")
    authenticationStrength = @{ id = $mfaStrengthId }
    operator = "OR"
  }
} | ConvertTo-Json -Depth 5

Write-Host "Standard user device policy (OR logic):"
Write-Host "  Compliant device → access granted (no additional MFA prompt)"
Write-Host "  Hybrid joined device → access granted (no additional MFA prompt)"
Write-Host "  Neither → MFA required as compensating control"
Write-Host "  Admins excluded (they have their own stronger policies)"

Why admins are excluded from this policy: Admins have their own separate policies (MSA3.4 Admin Policy 1 + 2) that enforce phishing-resistant MFA AND block unmanaged devices. Including admins in the OR policy would weaken their controls: the OR logic would allow admins to satisfy the requirement with just MFA on an unmanaged device, which contradicts the admin tier's block-unmanaged requirement.

Filter for devices, granular device targeting

The filter for devices condition lets you target CA policies based on device attributes beyond just compliance and join type. Device extension attributes (extensionAttribute1–15, set via Intune or Graph API) enable scenarios like:

Secure Admin Workstations (SAWs): Set extensionAttribute1 = "SAW" on designated admin workstations. Create a CA policy that only allows admin portal access from devices where device.extensionAttribute1 -eq "SAW". This is more restrictive than "compliant device", it requires a specific, designated workstation, not just any Intune-managed laptop.

Kiosk or shared devices: Set extensionAttribute2 = "SharedKiosk" on shared devices. Create a CA policy with shorter sign-in frequency (1 hour) for these devices, ensuring shared device sessions expire quickly.

# Check if any devices have extension attributes set
$devicesWithExtAttrs = Get-MgDevice -All -Property DisplayName, ExtensionAttributes |
  Where-Object { $_.ExtensionAttributes.PSObject.Properties |
    Where-Object { $_.Value -and $_.Value -ne '' } }

Write-Host "=== DEVICE EXTENSION ATTRIBUTES ==="
Write-Host "Devices with extension attributes: $($devicesWithExtAttrs.Count)"
foreach ($d in $devicesWithExtAttrs | Select-Object -First 5) {
  $attrs = $d.ExtensionAttributes.PSObject.Properties |
    Where-Object { $_.Value -and $_.Value -ne '' } |
    ForEach-Object { "$($_.Name)=$($_.Value)" }
  Write-Host "  $($d.DisplayName): $($attrs -join ', ')"
}

if ($devicesWithExtAttrs.Count -eq 0) {
  Write-Host "No devices have extension attributes set."
  Write-Host "Extension attributes are populated via Intune custom profiles,"
  Write-Host "PowerShell (Update-MgDevice), or Group Policy for hybrid devices."
  Write-Host "Use them for SAW designation, kiosk tagging, or device tiering."
}

Important limitation: Extension attributes on devices must be set via Intune or the Graph API. They're only available on Intune-managed or hybrid-joined devices. Unregistered devices have null extension attributes: the filter evaluates to false for unregistered devices when using positive operators (-eq, -contains). Use negative operators (-ne) if you want to catch unregistered devices.

Map your endpoint fleet to the CA device trust model. How many managed Windows devices (Intune + hybrid-joined)? How many managed mobile (Intune-enrolled)? How many BYOD (unregistered)? How many admin workstations marked as SAW? Each category gets a different CA treatment: admins require SAW + phishing-resistant, standard users on managed devices get compliant OR MFA, BYOD users get MFA only (no device compliance possible for unregistered devices).

Before moving on, verify your understanding: Run the device compliance inventory. How many of your devices are compliant? How many are managed? If zero are compliant, explain the dependency chain step that's missing and what must happen before device-based CA policies can be deployed. Explain the difference between OR and AND grant control operators for device compliance + MFA. Which is appropriate for standard users and why? Which is appropriate for admins and why?

Reusable script: the commands from this sub assembled for operational use:

Document the device policies in 03-conditional-access/device-policies.md. Include: device compliance inventory results, Intune dependency chain verification (compliance policies exist, device groups assigned, enrollment status), each device-based CA policy's configuration and OR/AND logic, filter-for-devices rules (if used), and the BYOD/unmanaged device strategy.