Intune and Conditional Access Integration

Microsoft Intune is a cloud-based endpoint management service that enforces device compliance and app protection policies. Conditional Access (CA) is a policy engine that evaluates signals such as user identity, device state, location, and risk to grant or block access to cloud apps. The integration means that CA can use Intune's device compliance status as a signal. For example, a CA policy can require that a device be marked as compliant by Intune before granting access to Exchange Online. Without this integration, CA would have no native understanding of whether a device has the latest security patches or is jailbroken. Intune provides that context.

The integration relies on Azure AD device registration and the Microsoft Intune service. When a device is enrolled in Intune, it receives a certificate from Intune's Certificate Authority (CA). The device periodically reports its compliance status to Intune based on compliance policies. These policies check conditions like:

Intune evaluates the device against each policy. If all conditions are met, the device is marked as compliant. This compliance status is stored in Azure AD as a property of the device object. The property is compliant (boolean). Conditional Access policies can reference this property via the grant control "Require device to be marked as compliant."

When a user attempts to access a cloud app, the following flow occurs: 1. User authenticates to Azure AD. 2. Azure AD evaluates the CA policy and checks the device compliance status stored in the device object. 3. If the device is compliant, access is granted (subject to other controls like MFA). 4. If the device is not compliant, access is blocked, or the user is redirected to Intune for remediation (if the CA policy allows it).

To configure Intune compliance policies via Microsoft Graph (useful for automation):

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "DeviceManagementConfiguration.ReadWrite.All"

# Create a compliance policy for Windows 10/11
$params = @{
    "@odata.type" = "#microsoft.graph.windows10CompliancePolicy"
    "displayName" = "Windows Compliance Policy"
    "passwordRequired" = $true
    "passwordMinimumLength" = 6
    "passwordRequiredType" = "deviceDefault"
    "osMinimumVersion" = "10.0.19042.0"
    "requireBitLocker" = $true
    "requireAntivirus" = $true
}
New-MgDeviceManagementCompliancePolicy -BodyParameter $params

To create a Conditional Access policy requiring compliant device:

$params = @{
    "displayName" = "Require Compliant Device"
    "state" = "enabled"
    "conditions" = @{
        "applications" = @{
            "includeApplications" = @("All")
        }
        "users" = @{
            "includeUsers" = @("All")
        }
    }
    "grantControls" = @{
        "operator" = "AND"
        "builtInControls" = @("compliantDevice")
    }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

Common wrong answers on the exam: - "Compliance status is evaluated in real-time." Reality: It is evaluated at check-in intervals (every 8 hours by default). - "Conditional Access can enforce compliance policies." Reality: CA only checks compliance status; it does not enforce the policies themselves. Intune enforces compliance policies. - "A non-compliant device is immediately blocked." Reality: There is a grace period (default 30 days) before the device is marked non-compliant. - "Device compliance is the only signal for CA." Reality: CA uses many signals (user risk, location, app sensitivity, etc.).

A bank with 10,000 employees uses Exchange Online. They have a zero-trust policy: email access only from managed, compliant devices. They deploy Intune to manage Windows 10 laptops and iOS phones. Compliance policies require Windows 10 22H2 or later, BitLocker enabled, Windows Defender active, and a password of at least 8 characters. For iOS, they require iOS 16+, passcode of 6 digits, and no jailbreak. A CA policy is created that blocks access for non-compliant devices. In production, they found that users would sometimes delay OS updates, causing non-compliance. They set a grace period of 14 days to allow time for updates. The helpdesk receives calls from users who see the block message. They guide users to the Company Portal to see the specific issue. The bank also uses Defender for Endpoint risk scores: if a device has a high-severity alert, Intune marks it non-compliant, and CA blocks email access until the threat is remediated.

A hospital allows nurses to use personal iPhones to access patient records via a mobile app. They cannot enroll personal devices in Intune due to privacy concerns. Instead, they use Intune App Protection Policies (MAM) to control app behavior. They create a CA policy that requires approved client apps and app protection policies. The CA grant control 'Require app protection policy' checks if the app (e.g., Microsoft Outlook) has the MAM policy applied. If the app is not protected, access is blocked. The hospital also uses CA to require MFA for all access. This scenario shows the alternative integration: CA uses app protection status instead of device compliance.

A common mistake is setting the grace period too long (e.g., 90 days) or forgetting to configure it at all (default 30 days). In a high-security environment, this can leave non-compliant devices with access for too long. Another mistake is not enabling the 'Require device to be marked as compliant' grant control in the CA policy, thinking that enrolling in Intune alone is enough. Enrollment alone does not enforce access control; the CA policy must explicitly require compliance. Also, admins often forget that compliance status is not real-time; a device that was recently compromised may still show as compliant until the next check-in.