What is Android zero-touch enrollment ?

Android zero-touch enrollment registers a device to your company before it ships, so it enrolls in your MDM during the setup wizard instead of on someone's desk. No QR code to scan, no afw# token to type, nobody in IT unboxing anything.

Google launched the program in 2017 for Pixel phones running Android 8.0 and it now covers most business Android hardware. The mechanics have barely changed in nine years, which is good news: the setup you do today will still work next year. What trips teams up isn't the technology, it's the purchase channel, the portal permissions, and the assumption that zero-touch does things it doesn't do.

What zero-touch is, and what it isn't

Zero-touch is a trigger, not a configuration system. The only thing the program stores about a device is: this serial number belongs to Acme, and Acme's MDM is the one that should manage it. When the device boots for the first time and reaches the network, it asks Google who owns it, gets pointed at your MDM, downloads the device policy controller, and hands itself over. Everything after that (apps, Wi-Fi profiles, passcode rules, kiosk lockdown) comes from your MDM, not from the zero-touch record.

So a badly configured MDM policy will deploy just as fast and just as silently as a good one. Zero-touch removes the human step, which means it removes the human who used to catch mistakes.

Three things it is not:

• It isn't a management mode. Zero-touch provisions a device as fully managed or, since Android 11, as a company-owned device with a work profile. The mode is decided by your MDM configuration, not by the portal.
• Nothing retroactive about it. A phone you bought last year from a high street shop will never appear in the portal. Android has no equivalent of Apple Configurator for adding existing hardware, and that gap is permanent for now.
• And it doesn't replace the other enrollment routes. Most fleets run zero-touch alongside QR code enrollment, because there's always a batch of devices that came from somewhere else. Our glossary entry on device enrollment lays out the full set of routes per platform.

What you need before you start

The prerequisites are short, and every one of them has caught someone out.

• Devices running Android 9.0 or later, from a manufacturer that participates in the program. Android 8.0 devices can support it optionally, Pixel phones go back to Android 7.0, but for anything you're buying in 2026 the version is a non-issue.
• GMS certified hardware with Google Play services enabled. A device sold without Google Mobile Services, or a bare AOSP build on a cheap tablet, can't enroll. Check the Android Enterprise Recommended list before you sign a purchase order, not after the first pallet lands.
• Purchase through an authorized zero-touch reseller. This is the real constraint. The reseller uploads device IDs to your portal account: IMEI for cellular devices, serial number paired with model name for Wi-Fi only tablets.
• A zero-touch portal account, created by that reseller. You can't self-register. Ask for it on your first order and give the reseller a Google account on your corporate domain, not someone's personal Gmail. Google documents the flow in its zero-touch enrollment guide for IT admins.
• An MDM that's registered as a zero-touch EMM and can give you the DPC extras JSON for its device policy controller.

One detail worth settling early: who in your team gets portal access. The portal has separate roles (Manager, Assigner, Viewer) and an audit log. A Manager can change the default configuration for every future device, which is exactly the sort of permission you don't hand to the person who places orders.

Setting it up, portal side then MDM side

In the zero-touch portal

You create a configuration, then assign devices to it. The configuration asks for five things:

• Configuration name, which only you see. Make it say something: "FR field techs, fully managed" beats "Config 2".
• EMM DPC, the device policy controller app. For most MDMs this is Android Device Policy, Google's own DPC.
• DPC extras, a JSON blob you copy from your MDM console. This is what tells the DPC which tenant and which policy group the device belongs to.
• Company name, shown to the user on the "this device is managed by" screen during setup. Users read it, so spell it properly.
• Support contact, an email and a phone number, plus an optional one or two sentence message. Point it at your helpdesk queue, never at an individual.

Then you assign. Either device by device, or by marking a configuration as the default so every new serial the reseller uploads inherits it. The default is how you avoid a daily chore, but there's a catch: once your zero-touch account is linked to an EMM, the enterprise default profile overrides a default configuration you set by hand in the portal. If you've linked your MDM, set the default on the MDM side and stop fiddling with the portal one.

For fleets above a few hundred devices a year, the portal UI stops being the right tool. Google exposes a zero-touch customer API that lets you list unassigned devices and apply configurations programmatically, which is how you stop someone forgetting the Tuesday batch.

In your MDM

Two steps, in this order. First, link your Android Enterprise organization to the zero-touch account so the MDM can see the devices. Second, decide what a zero-touch device becomes on arrival: which policy group, which apps, which restrictions, and whether it lands as fully managed or as a company-owned work profile.

Then test on one device. Not two, not a pilot group of twenty. One device, reset, booted on the same Wi-Fi your users will have, watched from the lock screen to the home screen. You'll learn more in those ten minutes than from any documentation, including this page.

Zero-touch vs Knox Mobile Enrollment vs QR code vs NFC

Four ways to provision a company-owned Android device. They're not interchangeable, and the choice is usually made for you by what you bought and where.

The honest comparison between zero-touch and Knox Mobile Enrollment: they do the same job, KME only does it on Galaxy hardware, and since 2021 Samsung lets you register a device in both portals. Pick one per device, not both, or you'll spend an afternoon working out which program claimed a handset. If your fleet is entirely Samsung, KME is marginally more flexible because a Samsung reseller who isn't a zero-touch partner can still add devices. Everything else being equal, we'd default to zero-touch for mixed fleets and keep KME for the Knox-specific pieces described in our Samsung Knox entry.

QR code enrollment gets unfairly dismissed. It's manual, but it works on any device from any source, and every fleet needs it as a fallback. The Apple side of this story works the same way, with Apple Business Manager playing the role of the zero-touch portal; we covered it in the guide to Apple mobile device management.

First boot, and what happens after a reset

What the user actually sees: the normal setup wizard, shorter. Language, Wi-Fi, then a screen saying your organization manages this device, sometimes a login, then the home screen with apps installing behind it. Five to ten minutes, most of it unattended. The device policy controller becomes device owner before the wizard ends, and that's the part that matters, because Android grants device owner only once and only at that moment.

A factory reset sends the device straight back through the same flow. It checks in with Google, finds itself still registered, and re-enrolls. That's the property that makes zero-touch a security control and not just a time saver: an employee who leaves and wipes their phone hands back a device that's still yours.

Unless you've left Factory Reset Protection unconfigured, in which case you've got a gap. FRP has been in Android since 5.1 and on a managed device the MDM decides which Google accounts may unlock the device after a wipe. Register a corporate account, document where its credentials live, and you close the loop. Skip it and you'll eventually meet the other failure mode: twenty devices back from a subsidiary, half of them asking for the password of an ex-employee's personal account.

One more reset detail. Removing a device from the zero-touch portal doesn't unenroll it. It only stops the next reset from re-enrolling it. If you're selling or donating hardware, unassign it in the portal first, then wipe it, in that order.

Where zero-touch deployments go wrong

Six failure patterns, in rough order of how often they show up.

• The reseller never uploaded the devices. You're staring at an empty portal and blaming your MDM. Ask the reseller for confirmation that the IMEIs are in your customer ID, with a date, before the shipment leaves.
• Devices are in the portal but no configuration is assigned. Adding a serial does nothing on its own. If no default configuration applies, the device boots like a consumer phone and the user sails through the wizard with a personal account. Now it needs a reset.
• The guest Wi-Fi blocks Google. Provisioning needs Google Play services and your MDM's endpoints reachable. Captive portals are the classic killer: the device can't accept terms of use during the setup wizard. Have an open or pre-shared SSID for provisioning, or let people use their mobile data.
• Somebody set up the device before you were ready. A warehouse manager opens a box to "check it works", completes the wizard, and the provisioning window is gone. The fix is procedural, not technical: sealed boxes go to the user, or they go nowhere.
• Mistyped manufacturer or model data. Wi-Fi only tablets are identified by serial plus model name, so a model string entered loosely by the reseller means the match fails silently. This one is invisible until you test a device from the batch.
• Stale DPC extras. You rotated an enrollment token or migrated MDM tenant and forgot the portal still holds the old JSON. Devices provision and then fail to enroll, which looks like an MDM bug and isn't.

A pattern across all six: the portal and the MDM are two systems that have to agree, and nothing warns you when they stop agreeing. Reset one device from every batch. It's fifteen minutes and it catches almost everything above.

How Appaloosa handles it

Appaloosa is registered as an EMM in the Android zero-touch portal, so the setup is the one described above: link your zero-touch account, copy the DPC extras from the console into your configuration, and map zero-touch arrivals to a policy group. Devices land fully managed or as company-owned work profiles, with their apps from Managed Google Play or your private APKs, passcode and restriction rules, OEMConfig settings for Samsung, Zebra or Honeywell hardware, and FRP accounts set per policy. Enrollment by QR code is there for everything bought outside the channel.

Devices that need to stay on one app, like scanners or check-in tablets, get kiosk mode applied from the same policy, so a zero-touch boot ends on the app and nothing else. The Android specifics live on our Android MDM page, and the cross-platform view, including Apple and Windows automated enrollment, sits on the mobile device management page. If you want the whole automated enrollment picture across vendors, start from the zero-touch feature page.

Zero-touch pays for itself on the first decent-sized order: fifteen minutes of manual setup times three hundred devices is close to two working weeks of someone's time, and that's before counting the mistakes. Get the reseller relationship and the portal roles right, test one device per batch, and the rest is your MDM policy doing what it would have done anyway.

FAQ

Can I use zero-touch on Android devices we already own?

No, and there's no workaround. A device has to be registered by an authorized reseller at purchase. Samsung hardware is the partial exception: Knox Mobile Enrollment can take Galaxy devices bought through a Knox reseller even when they weren't registered for zero-touch. For everything else, QR code enrollment after a factory reset gets you to the same fully managed state, it just needs a person and a screen.

What happens if the user skips Wi-Fi during setup?

Provisioning waits. On a cellular device with a SIM the enrollment usually proceeds over mobile data, and on a Wi-Fi only device the wizard can't complete the zero-touch step without a connection. The device doesn't silently fall back to an unmanaged state: it resumes when the network appears. Tell users in the welcome email to connect to a normal network, and keep captive portals out of the path.

Does zero-touch still matter now that Android provisioning has been simplified?

Yes. Android 16 shipped in June 2025 with a shorter enterprise setup flow, and Google's release cadence now puts behavior changes in one major release a year, so the wizard keeps getting tighter. But every other method still needs a human holding the device. Zero-touch is the only one where the box goes from the reseller to the employee and IT never touches it.