Android Zero Touch Enrollment: DPC and Account Checks
Verify Android zero-touch enrollment reseller registration, DPC package names, configuration extras and portal account roles before provisioning corporate devices.
Check reseller registration, DPC configuration and portal account roles before rollout.
On first boot, devices check if they have been assigned an enterprise configuration and, if so, initiate fully managed device provisioning and download the device policy controller app. Devices eligible for zero-touch enrollment need to be purchased directly from an enterprise reseller or Google partner and not through a consumer store.
Start your Android zero-touch enrollment verification by confirming reseller device registration, the assigned Device Policy Controller (DPC) configuration, and the portal account permissions. Use the tables below to audit your device records and configuration payload before shipping hardware.
Scroll horizontally to see all columns.
| Verification check | Documented requirement or behavior | Planning action |
|---|---|---|
| Device record creation | Resellers create devices when a customer purchases them for zero-touch enrollment; IT admins cannot create devices. | Confirm reseller claim status before unboxing. |
| Portal Configuration column | If the Configuration column of the portal table is listed as No config, devices without a configuration are not provisioned through zero-touch enrollment and boot unmanaged. | Assign a configuration profile before deployment. |
| Configuration enforcement timing | After you apply a configuration to a device in the zero-touch portal, the device automatically provisions itself on first boot or next factory reset. | Schedule a factory reset when updating existing units. |
| Skipped setup connectivity | If zero-touch enrollment is skipped during setup on a configured device because of missing connectivity, the device resets itself after the first connection to Google servers and warns the user one hour before the reset. | Verify network access during initial setup. |
| API forcedResetTime field | In the zero-touch Customer API Configuration resource, forcedResetTime is the timeout before forcing a factory reset if the device does not go through provisioning in the setup wizard, ranging from 0 to 6 hours with 2 hours as the default if unset. | Record the reset timeout in your configuration spec. |
| Portal onboarding account | To enable a reseller to create a zero-touch enrollment account, you must provide a Google Account associated with your corporate email and must not use a personal Gmail account with the portal. | Provide a corporate-email Google Account to the reseller. |
Check reseller registration and hardware identifiers
In Customer details in the zero-touch portal, you can view the customer name and customer ID and delete the account; once the account is deleted, you must reach out to the reseller to create a new account.
Each row in the reseller CSV file lists the customer ID to assign the device to, and after upload it may take from minutes to 24 hours for the device to be added to the portal.
The largest CSV file accepted by the zero-touch portal is 50 MB, and for ChromeOS devices in the reseller portal the CSV file limit is 30 devices regardless of file size.
Check the hardware identifier rules and CSV controls below when auditing device records:
Scroll horizontally to see all columns.
| Identifier or CSV scope | Zero-touch portal and API rule | Verification step |
|---|---|---|
| API identifier distinction | In the zero-touch enrollment API, a DeviceIdentifier represents a hardware device using hardware IDs, and should not be confused with deviceId, which represents a record in the API. | Match hardware IDs separately from portal record IDs. |
| Serial number registration | When registering a device by serial number in zero-touch, you must also register manufacturer (matching Build.MANUFACTURER) and model (matching Build.MODEL), and the serial number matches Build.getSerial(). | Record exact manufacturer and model strings with serial numbers. |
| Dual-SIM IMEI selection | A dual-SIM device has two discrete modems and two IMEI numbers; if registering just one IMEI, prefer the numerically lowest IMEI number because zero-touch enrollment works more reliably with the lowest IMEI. | Verify the lower IMEI value on dual-SIM fleet sheets. |
| Customer CSV profile removal | In a customer device configuration CSV file, setting profileid to 0 removes the configuration from the device, while replacing the profileid column with owner set to 0 bulk-deregisters devices. | Separate profile removal from bulk deregistration. |
| API device unclaim | Unclaiming a device via customers.devices.unclaim removes the organization's provisioning setup so the device becomes unmanaged after a factory reset, and the IT admin must contact their reseller to register it again. | Confirm reseller re-registration before unclaiming hardware. |
| Reseller CSV removal | In the reseller portal, removing devices via a CSV file requires setting profiletype to ZERO_TOUCH and setting the owner field to 0 (zero). | Review CSV column headers before submitting batch removals. |
Verify the DPC package name and provisioning extras
In Android Enterprise terminology, the DPC installed on fully managed and dedicated devices is referred to as the device owner (DO), while the DPC installed in the work profile is referred to as the profile owner (PO).
In the Android Management API, enrollment tokens expire after one hour by default (or a custom duration up to approximately 10,000 years), and if a device remains offline for 270 consecutive days it must be reprovisioned.
Review these DPC configuration and EMM linking rules before saving a portal profile:
Scroll horizontally to see all columns.
| Configuration topic | Documented requirement | Audit check |
|---|---|---|
| API Dpc fields | In the zero-touch Customer REST API customers.dpcs resource, a Dpc object has name (customers/[CUSTOMER_ID]/dpcs/[DPC_ID]), packageName (the DPC's Android application ID), and dpcName (the title of the DPC app in Google Play). | Look up the DPC resource name via customers.dpcs.list. |
| API dpcExtras JSON payload | Zero-touch enrollment installs the DPC from Google Play, sends the ACTION_PROVISION_MANAGED_DEVICE intent, and sends the values in android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE to the DPC as intent extras. | Format extras as a JSON object for the admin extras bundle. |
| Secrets in dpcExtras | Google cautions not to include account credentials or other secrets in a zero-touch configuration because a masquerading device may be able to use a false IMEI or serial number to read the configuration. | Remove plaintext credentials from configuration JSON. |
| Legacy device admin extras | In zero-touch configurations, Google recommends not including EXTRA_PROVISIONING_DEVICE_ADMIN_COMPONENT_NAME, EXTRA_PROVISIONING_DEVICE_ADMIN_PACKAGE_CHECKSUM, or EXTRA_PROVISIONING_DEVICE_ADMIN_SIGNATURE_CHECKSUM. | Keep the not-recommended device-admin extras (COMPONENT_NAME / PACKAGE_CHECKSUM / SIGNATURE_CHECKSUM) out of zero-touch configuration payloads. |
| Active configuration deletion | You cannot delete a configuration if it is still applied to devices; trying to delete an in-use configuration returns an HTTP 400 Bad Request status code until customers.devices.removeConfiguration removes it. | Clear active device assignments before deleting a configuration. |
| Android Management API iframe dpcId | When rendering the Android Management API zero-touch iframe, the required dpcId URL parameter is the package name of the DPC app, which should always be set to Android Device Policy, com.google.android.apps.work.clouddpc. | Confirm the DPC package name parameter in iframe integrations. |
| Iframe Enterprise default profile | When a zero-touch account is linked via the zero-touch iframe, unconfigured devices receive the unmodifiable Enterprise default profile, and unlinking the account unsets Enterprise default profile from those devices. | Check which devices rely on the linked default profile before unlinking. |
| Microsoft Intune iframe prerequisites | In Microsoft Intune, to enable the zero-touch iframe you must first add the update app sync permission and enable enrollment for corporate-owned, fully managed devices. | Verify Intune permissions before enabling the iframe. |
| Microsoft Intune default profile override | Microsoft Intune cautions that its linked default zero-touch configuration overrules the portal default configuration, so you should not link your account to Intune if creating a configuration for a corporate-owned work profile or dedicated device. | Avoid linking the Intune iframe when targeting work profile or dedicated modes. |
| Microsoft Intune manual portal JSON | When manually creating a zero-touch configuration in the portal for Microsoft Intune, you select Microsoft Intune as the EMM DPC app and pass com.google.android.apps.work.clouddpc.EXTRA_ENROLLMENT_TOKEN inside android.app.extra.PROVISIONING_ADMIN_EXTRAS_BUNDLE. | Inspect the enrollment token key inside the admin extras bundle. |
| Android Management API token rule | In the Android Management API provisioning guide, zero-touch enrollment is supported for company-owned devices with a work profile (Android 8+, allowPersonalUsage set to PERSONAL_USAGE_ALLOWED); company-owned work-only devices (Android 5.1+, PERSONAL_USAGE_DISALLOWED or PERSONAL_USAGE_DISALLOWED_USERLESS); and dedicated devices (allowPersonalUsage set to PERSONAL_USAGE_DISALLOWED_USERLESS). | Set allowPersonalUsage on the enrollment token. |
For ownership mode selection and management layer definitions, review Android Enterprise explained and MDM vs EMM for Android.
Audit portal accounts, user roles and enterprise bindings
In the zero-touch customer portal, portal users can be owners, admins, managers, assigners, or viewers.
In the zero-touch customer portal, you need to be an account owner to edit team members’ roles, and you cannot edit your own user role.
When adding team members in the zero-touch portal, the portal does not notify your team members that they have access, so you must remember to inform them yourself.
For privacy reasons, audit logs are retained for a maximum of one year, and only logs after March 2025 are available in the zero-touch customer portal.
The zero-touch portal can be used in American English, British English, Danish, Dutch, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Spanish, or Swedish.
In the Android Enterprise overview, enterprise bindings are either a Managed Google Play Accounts enterprise (a legacy binding type used for organizations that signed up before 2024) or a Managed Google domain.
Check Android version floors, GMS builds and known device issues
In Android Enterprise Help, zero-touch hardware prerequisites are a mobile or tablet device running Android Pie (9.0) or later, a compatible device running Android Oreo (8.0), or a Pixel phone with Android Nougat (7.0), purchased from a reseller partner.
In the zero-touch EMM integration guide, an EMM solution needs to provision a company-owned Android 8.0+ (Pixel 7.1+) device in fully managed mode, and company-owned Android 10+ devices can be provisioned as fully managed or with a work profile.
The device must be compatible with Google Mobile Services (GMS) and Google Play services must be enabled at all times for zero-touch enrollment to function correctly.
Google provides full support for Android phone and tablet form factors, while support for Android devices with form factors other than phones or tablets is provided on a reasonable-effort basis only.
Verify these documented GMS and model-specific restrictions before approving hardware batches:
- Zero-touch is blocked from working on devices where the factory build includes a GMS Core version code from 12800000 (v19) up to, but not including, 203900000 (2020w39).
- Cellular devices without telephony features, such as data-enabled tablets, can skip zero-touch if preloaded with a Google Play services version between 23.13.12 and 23.39.18 and registered by only their IMEI.
- Registered dual-SIM devices pre-installed with a version of Google Play Services prior to 24.07.12 will undergo a factory reset if not provisioned by zero-touch during initial setup.
- On the zero-touch Known issues table, installing an OTA update resolves the issue on Samsung SM-A205F (Samsung Galaxy A20), Samsung SM-P610 (Galaxy Tab S6 Lite), and Samsung SM-T500 (Samsung Galaxy Tab A7 10.4).
- Due to modifications made in the setup wizard, zero-touch is blocked from working in most Vivo Android 9 and Android 10 models, while Vivo supports zero-touch in Android 11 models.
- Reported models failing zero-touch on the Known issues table include ALLDOCUBE iPlay 7T (T701), Multilaser M10_4G_PRO, OnePlus A6003 (OnePlus 6), Realme 6i, Realme XT, Unihertz Titan, Urovo DT50W, and ZTE T86 (Tough Max 3).
Frequently asked questions
What happens when a Samsung device is configured in both Knox Mobile Enrollment and zero-touch?
If a Samsung device is registered and configured in both Knox Mobile Enrollment and zero-touch, the device enrolls using Knox Mobile Enrollment; to enroll using zero-touch, remove any configuration assigned to the device in the Knox Mobile Enrollment portal.
Compare Samsung console workflows in Samsung Knox Manage vs Android Enterprise enrollment.
Do ChromeOS-only fleets use the Android zero-touch portal?
Customers that only use ChromeOS devices do not need to access the zero-touch portal and configure their provisioning settings in the Google Admin Console instead.
Why does the Zero-touch Customer API return an HTTP 403 TosError?
Users need to accept the latest Terms of Service (ToS) before calling the Customer API; if not accepted, the API call returns an HTTP 403 Forbidden status code and a TosError.
What happens if an Android Management API device is enrolled without a valid policy?
In the Android Management API, if a device is enrolled without a valid policy it is placed into quarantine, and if it is not linked to a policy in five minutes, enrollment fails and the device is factory reset.
Record your zero-touch handoff details
Complete this verification record before assigning profiles or shipping hardware:
- Reseller zero-touch Customer ID: customer name and customer ID for authorized reseller CSV uploads.
- DPC package name: target Android application ID and Google Play DPC name for the configuration.
- Provisioning extras bundle: intended admin extras JSON key-value pairs without account credentials or secrets.
- Hardware identifier sheet: IMEI numbers or serial number, manufacturer and model strings.
- Portal account and role: corporate-email Google Account, portal role assignment and API Terms of Service status.
- Configuration state: assigned configuration name and factory-reset schedule for previously configured devices.
Keep this completed record with your deployment documentation. Browse Device Guides for additional Android hardware and provisioning references.
Sources
- Google Android Enterprise Help — Zero-touch enrollment for IT admins
- Google Developers — Zero-touch Customer API How it works
- Google Developers — Zero-touch Customer REST API customers.configurations
- Google Developers — Zero-touch Identifiers guide
- Google Developers — Zero-touch Reseller portal guide
- Google Developers — Zero-touch Customer REST API customers.dpcs
- Google Developers — Zero-touch EMM integration guide
- Google Developers — Android Management API Zero-touch iframe
- Microsoft Learn — Enroll Android Enterprise devices in Intune
- Google Developers — Android Management API Enroll and provision a device
- Google Developers — Android Enterprise terminology
- Google Developers — Android Enterprise Overview
- Google Developers — Zero-touch Known issues
Related articles
Samsung Knox Manage vs Android Enterprise Enrollment
Compare Samsung Knox Manage, Knox Mobile Enrollment and Android device owner terminology. Choose a management scope and check enrollment, accounts and reset requirements.
Read article
Android Enterprise Explained: Work Profiles, Full Management and Dedicated Devices
Choose an Android Enterprise management model by ownership and work needs. Understand work profiles, company-owned options, policy scope and pilot acceptance.
Read article
Android Kiosk Mode: What It Is and What to Plan Before Deployment
Plan Android kiosk mode as lock task or one KIOSK app on a company-owned dedicated device, and separate that plan from screen pinning before enrollment.
Read article