The Architecture Behind the Blind Spot

Intune's compliance engine for Android work profiles operates on a check-in model, not a continuous telemetry model. The device periodically contacts the Intune service, reports its current state, and receives updated policy. Between those check-ins, Intune has no real-time visibility into what's happening on the device.

The default check-in interval for Android devices is approximately 8 hours under normal conditions. But that interval is not enforced. If the device goes offline—airplane mode, dead battery, a user who simply stops using the device—the check-in doesn't happen. Intune records the last known check-in timestamp and waits.

Here's where the architecture creates the blind spot: Intune does not automatically mark a device non-compliant solely because it hasn't checked in. The compliance state remains at whatever it was during the last successful check-in. A device that was compliant at 9:00 AM on Monday and then goes offline stays in a compliant state in the Intune portal indefinitely—until it checks in again.

The compliance grace period compounds this. When you configure a compliance policy with a grace period (the "Mark device noncompliant" setting, which defaults to 0 days but is commonly set to 1–3 days in enterprise deployments to reduce helpdesk noise), you're adding additional runway before Intune acts on a compliance failure. But the grace period only starts counting when Intune actually detects a compliance failure. If the device never checks in, the grace period never starts.

The "Not Evaluated" compliance state is the specific condition to understand here. When a device hasn't checked in within the compliance policy evaluation window, Intune may assign this state rather than "Non-Compliant." Depending on your Conditional Access policy configuration, "Not Evaluated" devices may retain access to corporate resources—including Exchange Online, SharePoint, and Teams—because the CA policy is scoped to block only explicitly non-compliant devices.

---

How Long Can a Device Stay Dark

The honest answer: longer than your compliance framework allows.

In a default Intune configuration with no custom stale device policies, a work profile device can remain offline and retain its last-known compliant state for 30 days or more before Intune's built-in cleanup mechanisms begin to act. Microsoft's device cleanup rules, which are optional and must be manually configured, can remove devices that haven't checked in after a configurable number of days—but removal from Intune doesn't revoke access tokens already cached on the device.

The practical attack surface looks like this: an employee's Android device with a work profile checks in on a Friday afternoon, passes all compliance checks, and then goes offline. The user is on extended leave, the device is in a drawer, or the work profile has been manually disabled. For the next several days—potentially weeks—that device holds valid authentication tokens, cached credentials, and potentially offline copies of corporate documents synced through OneDrive or SharePoint.

Your SOC 2 Type II audit, your HIPAA risk assessment, your PCI-DSS scope review—all of them assume that your MDM platform enforces continuous compliance. The Intune architecture for Android work profiles does not deliver that by default.

---

What Your Compliance Dashboard Isn't Telling You

The Intune admin center's compliance reporting surfaces devices by their last evaluated compliance state, not by their current reachability. A device that checked in as compliant 12 days ago appears in the same "Compliant" bucket as a device that checked in 12 minutes ago.

To expose the actual gap, you need to query the data directly. The following KQL query, run against Microsoft Defender for Endpoint or Intune Data Warehouse via Azure Monitor / Log Analytics, surfaces Android work profile devices that have not checked in within the last 72 hours but are still marked compliant:

// Intune Device Compliance — Stale Android Work Profile Detection
// Requires: Intune Diagnostic Settings exported to Log Analytics Workspace
IntuneDevices
| where OSFamily == "Android"
| where ManagementAgent == "MDM"  // Work Profile devices
| where ComplianceState == "Compliant"
| extend HoursSinceCheckin = datetime_diff('hour', now(), LastSyncDateTime)
| where HoursSinceCheckin > 72
| project DeviceName, UserPrincipalName, LastSyncDateTime, HoursSinceCheckin, ComplianceState, OSVersion
| order by HoursSinceCheckin desc

This query will likely return results in any enterprise deployment that hasn't explicitly addressed this gap. The number of devices surfaced is the number of devices your compliance framework cannot currently account for.

For environments using Microsoft Sentinel, the following alert rule detects the pattern on a scheduled basis:

// Sentinel Scheduled Alert — Android Work Profile Dark Device Detection
// Schedule: Every 24 hours | Lookback: 96 hours
let StaleThresholdHours = 72;
let StaleDevices = IntuneDevices
    | where OSFamily == "Android"
    | where ComplianceState in ("Compliant", "Not Evaluated")
    | extend HoursSinceCheckin = datetime_diff('hour', now(), LastSyncDateTime)
    | where HoursSinceCheckin > StaleThresholdHours
    | project DeviceName, UserPrincipalName, LastSyncDateTime, HoursSinceCheckin, ComplianceState;
StaleDevices
| join kind=leftouter (
    SigninLogs
    | where TimeGenerated > ago(96h)
    | where AppDisplayName in ("Microsoft Teams", "SharePoint Online", "Exchange Online")
    | project UserPrincipalName, AppDisplayName, TimeGenerated, IPAddress, Location
) on UserPrincipalName
| where isnotempty(AppDisplayName)  // Device dark but user still authenticating
| project DeviceName, UserPrincipalName, LastSyncDateTime, HoursSinceCheckin, AppDisplayName, IPAddress, Location
| order by HoursSinceCheckin desc

The second query is the one that matters for incident response: it identifies devices that have gone dark in Intune but whose associated user accounts are still actively authenticating to corporate services. That combination—dark device, active authentication—is the specific pattern that compliance auditors flag and that threat actors exploit.

---

Conditional Access Configuration That Actually Closes the Gap

The default Conditional Access posture in most Intune deployments does not block "Not Evaluated" devices. Fixing this requires a deliberate policy change, and it comes with operational tradeoffs you need to plan for before you flip the switch.

Step one: Audit your current CA policy scope. In the Entra ID admin center, review every Conditional Access policy that references device compliance. Check whether "Require device to be marked as compliant" is the grant control, and verify whether your policy explicitly handles the "Not Evaluated" state.

Step two: Create a dedicated CA policy for stale Android devices. Rather than modifying your existing compliance-required policy (which risks breaking production access for legitimate users), create a new policy scoped specifically to Android platforms with a compliance state filter.

The following PowerShell block uses the Microsoft Graph PowerShell SDK to report on existing CA policies and their device compliance grant controls—use this to audit before making changes:

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

$CAPolicies = Get-MgIdentityConditionalAccessPolicy -All

foreach ($Policy in $CAPolicies) {
    $GrantControls = $Policy.GrantControls
    if ($GrantControls -and $GrantControls.BuiltInControls -contains "compliantDevice") {
        [PSCustomObject]@{
            PolicyName        = $Policy.DisplayName
            PolicyState       = $Policy.State
            IncludedPlatforms = ($Policy.Conditions.Platforms.IncludePlatforms -join ", ")
            ExcludedPlatforms = ($Policy.Conditions.Platforms.ExcludePlatforms -join ", ")
            GrantControls     = ($GrantControls.BuiltInControls -join ", ")
            Operator          = $GrantControls.Operator
        }
    }
}

Run this before any CA policy changes. Document the output. Your compliance auditor will ask for it.

Step three: Configure Intune device cleanup rules. Navigate to Intune > Devices > Device cleanup rules and set the cleanup threshold to match your compliance framework's maximum acceptable offline period. For SOC 2 and HIPAA environments, 30 days is the common outer boundary, but 14 days is more defensible. Removing the device record forces re-enrollment and re-evaluation before access is restored.

Step four: Set compliance policy actions for non-contact. Within each Android compliance policy, configure the "Send email to end user" action to trigger after 3 days of non-compliance and the "Retire the device" action after your framework's maximum threshold. The retire action revokes corporate data access even if the device is offline when the action fires—it queues and executes on next check-in.

---

Governance Considerations for Audit Readiness

If your organization is under SOC 2 Type II, HIPAA, or PCI-DSS scope, the Android work profile blind spot is not a theoretical risk—it's a control gap that auditors can identify through log review.

SOC 2 CC6.1 requires that logical access controls restrict access to authorized users. A device that has been offline for 10 days but retains valid cached tokens and offline document access does not satisfy that control as written. The auditor's question will be: "How does your MDM platform enforce continuous compliance?" The answer "it evaluates at check-in" requires a follow-up control to be defensible.

HIPAA's Technical Safeguard requirement under 45 CFR §164.312(a)(1) mandates procedures for access control. If a device containing PHI in a work profile container goes dark for an extended period, and your organization cannot demonstrate that access was revoked or monitored during that window, you have a documentation gap at minimum and a reportable incident risk at worst.

PCI-DSS Requirement 8.6 addresses the management of system and application accounts. Mobile devices with access to cardholder data environments fall within scope, and the inability to demonstrate continuous compliance monitoring is a finding.

The remediation posture for all three frameworks is the same: implement the KQL-based detection queries as scheduled alerts, configure device cleanup rules, enforce CA policies that treat "Not Evaluated" as equivalent to "Non-Compliant" for high-sensitivity resource access, and document the control chain in your risk register.

---

Operational Recommendations Before You Change Anything

Before modifying CA policies or compliance policy actions, run the stale device KQL query and quantify the current exposure. In most enterprise deployments, the first run surfaces a non-trivial number of devices. Communicate that number to your security and compliance stakeholders before making changes—not after.

Pilot the "Not Evaluated = Block" CA policy change against a test group of Android work profile users for a minimum of two weeks. The most common operational failure mode is legitimate devices that check in infrequently due to network restrictions (corporate proxy configurations, split-tunnel VPN policies, or geographic restrictions) being incorrectly blocked. Identify those edge cases in the pilot before broad rollout.

Configure the Intune device cleanup rule at a threshold that aligns with your compliance framework but does not create excessive re-enrollment burden. A 14-day cleanup threshold in an organization where field employees routinely go offline for 10-day periods will generate significant helpdesk volume. The right threshold is the one your compliance framework requires, implemented with a user communication plan that sets expectations before the policy fires.

Finally, add the stale Android device count to your monthly security metrics dashboard. This is not a one-time remediation—it's an ongoing operational indicator. Devices go dark for legitimate reasons (employee leave, device replacement, role changes), and the metric should trend toward zero over time as your cleanup and CA policies take effect.

---