A thread spun up internally around unexpected reboots happening during Autopilot. A suggestion to the person who opened the thread was to remove their Windows Update Ring in Intune and see if the behavior goes away. It did.
Windows Update Rings and ManagePreviewBuilds
This was surprising because we had fixed this issue back in the 2111 Intune release. The issue that was fixed was related to setting the CSP ./Device/Vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds. If this policy is set, a reboot is required to opt-in the device to the Windows Insider program, and executed during Autopilot. Note that the device isn't actually opted into the Insider Preview program. This policy tells the OS that MDM policy is managing the preview builds. It's still up to you to select the preview ring (Dev, Canary, etc) that you want to be in. If you don't select anything, you're just on the General Availability Channel. This causes a "double sign-in" issue during AP where the user signs in at OOBE, then the reboot happens, then another sign in happens at logon. New Windows Update Rings created after the 2111 Intune service release should not have this issue.
The reason this happens is due to the businessReadyUpdatesOnly property in the graph API. If this property is set to anything other than userDefined, then ManagePreviewBuilds gets set as well, so an unexpected reboot happens. Rings created prior to 2111 were set to businessReadyOnly.
To fix this, open your Windows Update Ring and toggle Enable pre-release builds to enable. Save it. Then change it back to Not Configured. That setting controls the businessReadyUpdatesOnly property. You can also adjust this via the graph API if you wish. Any future Autopilot deployments shouldn't have the reboot due to this.
Other Causes of Reboots
There are other reasons why you may get unexpected reboots. The above is the most common. The other reasons tend to lie in the HKLM\Software\Microsoft\Provisioning\SyncML\RebootRequiredURIs registry key.
If any of the below are set, a reboot will be required by Windows.
./Device/Vendor/MSFT/Accounts/Domain/ComputerName
./Device/Vendor/MSFT/Policy/Config/Connectivity/AllowUSBConnection
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/ConfigureSystemGuardLaunch
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/EnableVirtualizationBasedSecurity
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/LsaCfgFlags
./Device/Vendor/MSFT/Policy/Config/DeviceGuard/RequirePlatformSecurityFeatures
./Device/Vendor/MSFT/Policy/Config/DmaGuard/DeviceEnumerationPolicy
./Device/Vendor/MSFT/Policy/Config/ExploitGuard/ExploitProtectionSettings
./Device/Vendor/MSFT/Policy/Config/MixedReality/HeadTrackingMode
./Device/Vendor/MSFT/Policy/Config/Notifications/DisallowCloudNotification
./Device/Vendor/MSFT/Policy/Config/Notifications/DisallowTileNotification
./Device/Vendor/MSFT/Policy/Config/Notifications/WnsEndpoint
./Device/Vendor/MSFT/Policy/Config/ServiceControlManager/SvchostProcessMitigation
./Device/Vendor/MSFT/Policy/Config/Start/HideChangeAccountSettings
./Device/Vendor/MSFT/Policy/Config/Start/HideHibernate
./Device/Vendor/MSFT/Policy/Config/Start/HideLock
./Device/Vendor/MSFT/Policy/Config/Start/HidePowerButton
./Device/Vendor/MSFT/Policy/Config/Start/HideRestart
./Device/Vendor/MSFT/Policy/Config/Start/HideShutDown
./Device/Vendor/MSFT/Policy/Config/Start/HideSignOut
./Device/Vendor/MSFT/Policy/Config/Start/HideSleep
./Device/Vendor/MSFT/Policy/Config/Start/HideSwitchAccount
./Device/Vendor/MSFT/Policy/Config/Start/HideUserTile
./Device/Vendor/MSFT/Policy/Config/Start/ImportEdgeAssets
./Device/Vendor/MSFT/Policy/Config/Update/ManagePreviewBuilds
./Device/Vendor/MSFT/Uefi/Identity/Apply
./Device/Vendor/MSFT/Uefi/Identity2/Apply
./Device/Vendor/MSFT/Uefi/Permissions/Apply
./Device/Vendor/MSFT/Uefi/Permissions2/Apply
./Device/Vendor/MSFT/Uefi/Settings/Apply
./Device/Vendor/MSFT/Uefi/Settings2/Apply
./Device/Vendor/MSFT/WindowsDefenderApplicationGuard/InstallWindowsDefenderApplicationGuard
./Device/Vendor/MSFT/WindowsLicensing/UpgradeEditionWithProductKey
If you have any policies that you're deploying via configuration profiles (Settings Catalog, Device Restrictions, custom-OMA URIs) that are in this list, then you're also going to get a reboot. Windows will combine the reboots if you have multiple required reboots due to policies in this list. So if you fix the Windows Update thing, but still have a reboot, check your policies and see if they are in this list.
Surface and DFCI
If you're using Surface devices with Autopilot and you have fixed the Windows Update problem, you could also be seeing a reboot due to Device Firmware Configuration Interface (DFCI). This is because when your devices are enrolled by Microsoft or your OEM, these are considered High Trust enrollments. In order to use DFCI, the devices must be enrolled by a partner or OEM in order for a trust-relationship to be created. If you upload a hash to AP, that's considered a low-trust enrollment, and DFCI doesn't work in that scenario.
When a high-trust enrollment happens, the ./Device/Vendor/MSFT/UEFI CSP gets invoked and your device will reboot, even if you don't have DFCI configured. This reboot is something you can't do much about. You'll see the reboot request in the device management event log.
And lastly, if you still have reboots, check PowerShell scripts, Apps, etc.