CIS Benchmark & Autopilot Reboot Loops: The Device vs. User Context Fix

CIS Benchmark & Autopilot Reboot Loops: The Device vs. User Context Fix

You deploy CIS Benchmark v2.0.0 to your Intune tenant. Devices ship to users. Autopilot begins. And then—mid-OOBE, the device reboots. Again. And again. You exclude the CIS policy from the Autopilot device group, and the problem vanishes. But now you're stuck: how do you enforce CIS security without breaking Windows Autopilot pre-provisioning?

This is not a CIS problem. It's an assignment context problem. And it's entirely fixable.

The Problem: Why CIS Breaks Autopilot

When you assign a CIS Benchmark policy to a device group, Intune delivers that policy to the device during pre-provisioning. The Intune management agent begins enforcing settings before any user logs in. If a policy setting triggers a reboot—Device Guard enablement, BitLocker requirements, update policies, or UAC changes—the device reboots mid-OOBE and the provisioning flow stalls or loops.

The magic word is context. Device-context policies apply in the system account environment. User-context policies apply only after a user token exists on the device. By the time Autopilot assigns the user, that user-context policy can apply cleanly without interrupting pre-provisioning.

Which CIS Controls Trigger Reboot Loops?

Not every CIS setting causes a reboot. The culprits are settings that:

• Enable security features that require a restart — Device Guard (Virtualization-Based Security), BitLocker, UEFI firmware settings, Credential Guard
• Modify system startup behavior — Boot options, Secure Boot, TPM policies
• Restrict system services before user login — Services that block OOBE progression.
• Require account elevation or UAC changes — Policies that change how administrators are prompted

Based on real-world troubleshooting, these specific OMA-URI policies in CIS v2.0.0 and v3.0 have caused Autopilot reboot loops:

The Solution: Split CIS Into Three Policies

The most effective production strategy—used by several MSPs and enterprises in the community—is to refactor the CIS benchmark into three separate policies:

1. Device-Context OMA-URI Policy (Hardware & Firmware Controls)
2. Device-Context Settings Catalog (System Settings)
3. User-Context Settings Catalog (User Preferences & UI)

This strategy lets you:

• Exclude Autopilot devices from device-context policies until after provisioning
• Apply user-context policies immediately without blocking OOBE
• Use dynamic group membership to auto-enroll devices in the full CIS policy 24 hours post-provisioning

Step-by-Step Implementation

What If Your Device Still Reboots?

If Autopilot still enters a reboot loop after splitting policies, you've hit a setting that is fundamentally incompatible with Autopilot. The options are:

Option: Delay Device-Context Policies by 72 Hours

If a policy is truly critical but incompatible with Autopilot, use a Microsoft Graph API script to add the device to the CIS policy group 72 hours after enrollment:

# PowerShell script using Microsoft.Graph module
# Run this as a scheduled task post-Autopilot

require -Version 7.0
Import-Module Microsoft.Graph.Groups -MinimumVersion 2.0

# Authenticate (use -TenantId for production)
Connect-MgGraph -Scopes "Group.ReadWrite.All"

$groupId = ""
$deviceId = (Get-MgDevice -Filter "displayName eq '$env:COMPUTERNAME'").Id

if ($deviceId) {
    try {
        New-MgGroupMember -GroupId $groupId -DirectoryObjectId $deviceId
        Write-Output "Device added to CIS group after 72-hour delay"
    } catch {
        Write-Error "Failed to add device: $_"
    }
} else {
    Write-Warning "Device not found in Azure AD"
}

Schedule this script via Task Scheduler:

# Create scheduled task for 72-hour delay
$TaskName = "DelayedCISEnrollment"
$ScriptPath = "C:\Scripts\AddDeviceToCISGroup.ps1"
$ScheduledTime = (Get-Date).AddHours(72)

$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File $ScriptPath"
$Trigger = New-ScheduledTaskTrigger -At $ScheduledTime -Once
$Settings = New-ScheduledTaskSettingsSet -RunOnlyIfNetworkAvailable -StartWhenAvailable

Register-ScheduledTask -TaskName $TaskName -Action $Action -Trigger $Trigger -Settings $Settings -RunLevel Highest -Force

Production Checklist

Key Takeaways

• Device-context policies apply during Autopilot pre-provisioning (system account) and can trigger reboots that break OOBE. Hardware and firmware policies (Device Guard, BitLocker, DMA Guard) must stay here but be excluded from Autopilot devices.
• User-context policies apply after user logon and do not interrupt Autopilot. UI, UAC, and service policies can safely move here and apply immediately during provisioning.
• Split CIS into three policies: Device OMA-URI (hardware), Device Settings Catalog (system), and User Settings Catalog (UI/preferences).
• Use dynamic group membership to automatically enroll devices into full CIS enforcement 24 hours after Autopilot completes.
• Test on 3–5 pilot devices before rolling out to production. Monitor MDM diagnostics and event logs for remaining reboot sources.
• If a policy still causes reboots, delay its assignment by 48–72 hours using a scheduled Graph API script or Configuration Manager.