I bought Android phones but they don't show in zero-touch — now what?

You cannot add an Android device to Google's zero-touch portal yourself — only an authorised reseller can, and most admins discover this after the phones have arrived. Here is how to work out which trap you have hit, what to demand from your supplier, and the enrolment routes that still work when the reseller path is closed.

The problem

You have a box of new Android handsets, an EMM configuration ready in the zero-touch portal, and the devices simply are not there. There is no Add device button for you to use, no IMEI upload form, and nothing in the portal explains why. When you power a handset on, it walks straight through the consumer setup wizard as if your organisation did not exist — no enrolment prompt, no error, nothing to troubleshoot.

If you come from the Microsoft or Apple side, this is genuinely surprising. Windows Autopilot lets you harvest a hardware hash from any device and upload it yourself; Apple Business Manager lets you add devices with Apple Configurator. Google zero-touch offers no self-service equivalent: registration is a reseller-only operation, and the customer's role in the portal is limited to mapping already-registered devices to provisioning configurations.

Admins typically hit this in one of three ways:

• The devices were bought from a consumer or non-partner channel — a marketplace listing, a high-street retailer, or a distributor that is not an authorised zero-touch reseller. Those units were never registered and cannot be added retroactively by you.
• The reseller is a partner but never registered the units — nobody asked them to, or they registered the devices against the wrong customer account.
• Dual-SIM devices were registered with the wrong IMEI. A dual-SIM handset has two IMEIs; if the wrong one was registered, zero-touch silently never triggers even though the device appears (to the reseller) to be registered.

Why it happens

Zero-touch registration is a supply-chain trust model. Google deliberately restricts registration to authorised resellers so that a device identifier cannot be claimed into an arbitrary organisation's tenant by whoever types the IMEI in first. Google's documentation is explicit: "Devices eligible for zero-touch enrollment need to be purchased directly from an enterprise reseller or Google partner and not through a consumer store." The reseller registers each unit's identifier against your zero-touch customer account at (or after) the point of sale; there is no customer-side registration path.

Mechanically, when an eligible device first connects to the internet during setup, it checks in against Google's registration database, keyed on the device identifier — the IMEI for cellular devices, the serial number and manufacturer for Wi-Fi-only devices. A match pulls down your enrolment configuration; a miss does nothing at all. There is no client-side log entry or user-visible error for a miss, which is why an unregistered or wrongly registered device looks identical to a plain consumer handset.

The dual-SIM trap

A dual-SIM device has two discrete modems and therefore two IMEIs. Google's guidance to resellers is to register the numerically lowest IMEI. If the reseller registers the higher IMEI — easy to do when scanning barcodes off the carton — the check-in lookup misses and provisioning never triggers, silently. This is the nastiest variant of the problem because the portal shows the device as registered, so both sides believe everything is in order.

Device eligibility

Even correctly registered devices must meet Google's baseline: Android 9.0 or later on any GMS-certified device, some compatible Android 8.0 devices, or Pixel phones from Android 7.0. The device must carry Google Mobile Services — uncertified or GMS-free units will never zero-touch enrol regardless of registration.

The fix

1. Diagnose which failure you have

1. Confirm your zero-touch customer account exists and note the customer ID (Portal → Resellers). Your reseller needs this — or the Google account email on the portal — to register devices to you.
2. Ask the supplier whether they are an authorised zero-touch reseller. Check them against Google's published reseller directory rather than taking the word of a sales rep. If they are not on it, the reseller route is closed for these units — skip to the fallbacks below.
3. If they are a partner, ask them to register the units now against your customer ID and to confirm in writing which identifiers were uploaded. Registration after purchase is fine; it is the seller that matters, not the timing.
4. For dual-SIM devices, compare IMEIs. Dial *#06# on the handset (or read the carton label), identify the numerically lowest IMEI, and check that this is the one in the portal. If the higher IMEI was registered, have the reseller correct it, then factory-reset the device and let it check in again.
5. Check eligibility: GMS-certified, Android 9+ (or a compatible 8.0 device / Pixel on 7.0+). Wi-Fi-only devices register by serial number and manufacturer, not IMEI.

2. If the reseller route is closed: fallback enrolment paths

Unregistered units can still be enrolled as corporate-owned devices — you just lose the zero-touch part. Every fallback is a per-device, hands-on step, so factor the labour into the decision to keep or return the stock.

3. For the next order: put registration in the purchase order

• Buy only from resellers listed in Google's zero-touch reseller directory, and say in the PO that zero-touch registration is a condition of the order.
• Give the reseller your zero-touch customer ID up front.
• Require written proof before delivery: the list of IMEIs/serials registered and the customer account they were registered to.
• For dual-SIM models, require written confirmation that the numerically lowest IMEI was registered for each unit.
• Verify the devices appear in your portal before rollout day — a quick check that prevents this entire article.

How Decolla handles it

Straight answer: Decolla does not solve this one. Decolla provisions Windows devices over your own Microsoft Intune and Windows Autopilot tenant; it does not manage Android devices, and it cannot register handsets into Google's zero-touch portal — no product can, because Google restricts registration to authorised resellers by design.

What Decolla does do is institutionalise the discipline this article recommends. Before anything runs, Decolla's wizard produces a written, itemised plan — every item with its delivery method and reversibility class stated — which you approve up front. The whole point of that plan-first model is that provisioning decisions get made before execution starts, not discovered after the boxes arrive; the Android procurement lesson above is the same principle applied to purchasing. It is also worth noting the platform contrast: on Windows, Autopilot lets you self-register a device's hardware hash, so a machine bought from the "wrong" channel is recoverable into zero-touch provisioning in a way a non-partner Android purchase is not.

Decolla is currently pre-launch and waitlist-only.

Sources

• Google — Zero-touch enrolment portal guide (reseller and customer roles)
• Google — Zero-touch enrolment for IT admins (eligibility, reseller purchase requirement, dual-SIM IMEI guidance)
• Google — Android Enterprise partner directory (authorised zero-touch resellers)
• SMB to the Cloud — Get started with Android zero-touch and Intune
• Bayton — Android Enterprise zero-touch console device guide