Zero-touch enrollment should mean a new Android phone enrolls into Intune as soon as it's switched on. When it doesn't, the device either runs the normal consumer setup or stops with a provisioning error. The cause can sit with the reseller, the zero-touch portal, the DPC extras JSON, the Intune token or Conditional Access. In this post I'll walk through each link in that chain, the errors you'll see, and how to prove the fix.
Errors this guide fixes
Couldn't use the admin app due to a checksum errorAndroid setup screenAADSTS53000 (DeviceNotCompliant)Microsoft Entra sign-in log+1 more guideAADSTS53003 (BlockedByConditionalAccess)Microsoft Entra sign-in log+1 more guide
Symptoms#
- A new or factory-reset device runs the normal consumer setup and asks for a Google account, with no company screen.
- Setup shows your organization's details and starts installing the management app, then stops with a provisioning error such as:
Couldn't use the admin app due to a checksum error- The user signs in with their work account during setup and Microsoft blocks the sign-in. The Microsoft Entra sign-in log shows
AADSTS53000 (DeviceNotCompliant)orAADSTS53003 (BlockedByConditionalAccess). - Devices enroll as fully managed when you wanted corporate-owned work profile (COPE) or dedicated.
- A device appears in Intune but never receives policies.
The checksum line is wording reported by admins, not text from Google or Microsoft documentation, and it can vary slightly between Android versions and manufacturers.
Why it happens#
Zero-touch is a chain. The reseller registers each device to your zero-touch customer account. A configuration in the zero-touch portal names Microsoft Intune as the EMM DPC and carries DPC extras with your Intune enrollment token. During first setup, the device checks with Google, downloads Android Device Policy and enrolls in the mode the token defines. For fully managed and COPE devices, the user then signs in to Microsoft Entra ID in a Chrome tab. A break anywhere gives a specific symptom:
| Symptom | Usual cause |
|---|---|
| Consumer setup, no company screen | Device not registered to your account (wrong reseller or customer account), no configuration and no default, device already set up before the configuration was applied, or no internet at first boot |
| Checksum error | Hand-edited DPC extras, typically a signature checksum that no longer matches the value in Microsoft's JSON |
| Fails after the app installs | Token missing its quotes, or taken from a deleted, replaced or expired profile |
| Wrong enrollment mode | The Intune-linked default configuration uses a fully managed token and overrides the portal's default |
AADSTS53000 / AADSTS53003 | A Conditional Access policy requiring a compliant device, or blocking access, covers the Microsoft Intune cloud app |
| Enrolled but unprotected | The device was restarted during enrollment |
How to fix it#
1. Confirm the device is in your zero-touch account#
Microsoft requires devices bought from an authorized zero-touch reseller that support zero-touch enrollment. Sign in to the zero-touch portal with the Google account you gave the reseller and search the Devices list for the IMEI or serial number. If it's missing, send the reseller your customer ID and order details; you can't add devices yourself. If the same Samsung devices are also in Knox Mobile Enrollment, pick one method (see Knox Mobile Enrollment with Intune).
2. Decide where the configuration lives#
The Intune iframe suits fully managed devices only. To use it:
- Give your Intune role the Update app sync permission: Tenant administration › Roles, select the role, Properties › Permissions › Edit › Android Enterprise, set Update app sync to Yes and save. Corporate-owned, fully managed enrollment must also be enabled.
- Go to Devices › By platform › Android › Device onboarding › Enrollment and, under Bulk enrollment methods, select Zero-touch enrollment.
- Sign in with the reseller's Google account, select the zero-touch account and select Link. Add support information and save.
Watch out: Linking creates a default configuration with a fully managed token. It applies to every zero-touch device without a configuration and to future reseller devices, and it overrules the portal's default. For COPE or dedicated devices, don't link; select View devices in the zero-touch portal and build the configuration there.
3. Build the DPC extras correctly#
In the same Enrollment page, open the corporate-owned profile for the mode you need (fully managed, dedicated, or corporate-owned with work profile) and copy its token. In the portal configuration, select Microsoft Intune as the EMM DPC and paste this JSON into DPC extras, replacing YourEnrollmentToken and keeping the double quotes:
{
"android.app.extra.PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME": "com.google.android.apps.work.clouddpc/.receivers.CloudDeviceAdminReceiver",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM": "I5YvS0O5hXY46mb01BlRjq4oJJGs2kuUcHvVkAPEXlg",
"android.app.extra.PROVISIONING_DEVICE_ADMIN_PACKAGE_DOWNLOAD_LOCATION": "https://play.google.com/managed/downloadManagingApp?identifier=setup",
"android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE": {
"com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN": "YourEnrollmentToken"
}
}Never retype the first three values: one wrong character in the signature checksum is the classic cause of the checksum error, and a mistake in the component name or download location stops provisioning too. Validate the file before pasting it, because a stray comma or curly quote breaks the configuration:
Get-Content .\dpc-extras.json -Raw | ConvertFrom-JsonAdd your organization name and support details; users see them during setup.
4. Apply the configuration and reset the device#
Apply the configuration to the device in the portal, or make it the default. Then reset the device so setup runs again, with Wi-Fi or mobile data at first boot. For a device Intune already manages, use an Intune wipe: Microsoft documents that it doesn't trigger factory reset protection, while a reset from Settings or recovery can, depending on your factory reset protection settings.
5. Let the enrollment sign-in through Conditional Access#
Android setup authenticates in a Chrome tab, so Microsoft says to exclude the Microsoft Intune cloud app from policies that require a compliant device or block access for all cloud apps, Android or browsers. Open the failed sign-in, check the Conditional Access tab for the policy that applied, and adjust it. AADSTS53000 vs AADSTS53003 covers the details.
6. Don't restart during enrollment#
Microsoft warns that a restart mid-enrollment can leave a device that looks enrolled but isn't protected. Wipe it and enroll again.
Verify the fix#
- Setup shows your organization name and support details, installs Android Device Policy and goes to the work sign-in without asking for a consumer Google account.
- The Entra sign-in log shows a successful sign-in for the enrollment.
- The device appears in Intune with Corporate ownership and the enrollment profile you expected, then starts receiving apps and policies.
Prevent it next time#
- Own the zero-touch account with a Google account tied to a shared corporate mailbox, not one person's address.
- Record which portal configuration uses which Intune profile token. When you replace or revoke a token, update the DPC extras the same day.
- Don't rename an Android enrollment profile after you assign it; Microsoft notes this can prevent future enrollments. Create a new profile with the new name, assign it, then delete the old one.
- Test one device per configuration after every change.
Related guides: fully managed and COPE enrollment errors, dedicated devices, work profile enrollment failures and the Android error quick reference.

