Published 2026-09-06 · LuckyMDM Blog
On Android, how a device was provisioned matters more than what it can do on day one, because it determines what happens on day 400 - when a renter wipes the handset and walks through the setup wizard again. Some enrollment methods bind the device at the reseller level and survive that reset. Others live inside the setup flow and are gone the moment the flow is skipped.
This page is written for operators running Android rental, subscription or DaaS fleets. It sets out the two management modes that matter, the five provisioning paths and the Android version each one requires, the reset test that separates them, the factory reset protection trap, and a six-item acceptance checklist. Version floors are the ones published in Google's Android Enterprise feature list; individual OEMs and carriers vary, so treat the matrix as the starting point and confirm against the specific model.
Android Enterprise offers several management modes. For rental fleets, two are relevant:
There is also dedicated device (single-use / kiosk), which builds on fully managed and locks the device to one app or a small set - useful for point-of-sale or field-service deployments rather than consumer handset rental.
One constraint applies to all fully managed provisioning: it can only be performed during initial device setup. A device already in use has to be factory reset before it can be enrolled. That single fact drives most of the operational planning below.
| Method | Minimum Android | What it requires from you | Survives a factory reset? |
|---|---|---|---|
| Zero-touch enrollment | 8.0+ (Pixel: 7.1+; Samsung: 9.0+) | Devices purchased from an authorised reseller, registered against your zero-touch account | Yes - re-enrols on first boot |
| Samsung Knox Mobile Enrollment | Samsung 9.0+ | KME account; reseller or you register IMEI / serial numbers | Yes - re-enrols on first boot |
| QR code provisioning | 7.0+ (scanner built into the OS from 9.0) | A generated code; someone must scan it during setup | No - the code must be scanned again |
| DPC identifier ("afw#") | 6.0+ for fully managed and dedicated devices | Someone types the identifier into the setup wizard | No - the identifier must be entered again |
| NFC | 5.1+ (not recommended from Android 10 onward) | A programmer device and NFC tags | No - and generally deprecated |
The binding sits with the device identity - serial or IMEI - registered before the device ever reaches the renter. On first boot, or after any factory reset, the device contacts Google's or Samsung's provisioning service, receives the configuration, and installs the device policy controller automatically. No human step, nothing for the renter to skip.
The catch is procurement: zero-touch requires devices bought from an authorised reseller, and the reseller has to register them against your account. Grey-market stock, devices bought retail, and handsets already in the field cannot be converted after the fact. For a fleet operator this is a purchasing decision, not an IT one.
The EMM console generates a QR code carrying provisioning parameters - Wi-Fi, DPC details, configuration extras. During setup the user scans it (below Android 9 the reader has to be downloaded first, by tapping the welcome screen six times). It works on an unusually wide range of hardware and needs no special procurement.
What it does not do is persist. After a factory reset the device returns to a standard consumer setup, and unless someone is standing there with the code, it comes back unmanaged.
Entering afw# plus an EMM-specific code at the account prompt is the widest-coverage method available and needs no optional hardware - no camera, no NFC. Against that, it carries the most manual steps and cannot pass configuration extras, so Wi-Fi and other parameters have to be handled separately. It is a fallback, not a fleet strategy.
Here is the only test that reliably tells you which tier you are actually on. After enrolling a device:
If the device comes back managed without anyone touching it, the binding is at the reseller level and your control survives the single most common evasion step a renter has. If it comes back as an ordinary consumer handset, your enrollment was a setup-flow or manual artefact, and a renter who wants out of management needs only to reset the phone.
For a rental fleet, this test should be part of acceptance for every new device model and every new supplier batch - not something run once at the start. Supplier changes, regional variants and firmware differences all move the answer.
Factory Reset Protection is an anti-theft feature: after a reset, the device asks for credentials of a Google account previously synced on it. In a corporate fleet this is protective. In a rental fleet it is a recurring operational failure.
The scenario: a renter signs into a personal Google account during setup. Later - at end of term, or during a recovery - the device is reset. FRP now locks it behind that renter's credentials. The operator owns a handset it cannot set up, and the renter may be uncontactable or uncooperative. The device is not bricked, but it is unusable without a documented ownership-and-unlock process with the OEM or carrier.
Two controls reduce the exposure. First, provision before handover so the renter never reaches the account prompt in an unmanaged state - which is another argument for Tier 1. Second, where the management API and OEM support it, restrict account addition on fully managed devices so a personal account is never added in the first place. Neither is a substitute for a documented recovery path, and the recovery path should be agreed with the OEM before the first device goes out, not after the tenth one comes back locked.
Operators running mixed fleets should know where the two platforms genuinely diverge, because the same policy cannot be written for both.
On Apple, a supervised device can be configured so that Erase All Content and Settings is blocked, removing the renter's ability to wipe the handset from settings. Combined with Apple Business Manager enrolment - which, like Android zero-touch, survives a wipe and re-attaches the device to the same MDM on reactivation - that produces a device the renter cannot reset out of management.
Android Enterprise has no equivalent universal, cross-OEM control that blocks a factory reset. The Android answer is different and, in daily operation, about as effective: you cannot always prevent the reset, but with Tier 1 enrollment the reset does not free the device - it re-provisions itself on boot. Policies should therefore be written around re-enrollment rather than reset prevention on Android, and around both mechanisms on Apple.
Item 6 is the one that pays for itself. The other five can all be redone if they fail; a device whose identity was never captured before it went into the field is difficult to reconcile later, and reconciliation gaps are where fleets quietly lose units.
Operators running both platforms often find that the harder problem is not any single control but holding two different playbooks in one operation. On the LuckyMDM (Sichuan Starlight Network LLC) device management platform, enrollment tier, device-owner state and last check-in time are exposed as first-class fields for both Android and Apple devices, so the reset test above and its Apple equivalent can be run and tracked from one console instead of two.
No. Zero-touch registration happens at purchase through an authorised reseller and is tied to the device identity before first boot. Fully managed provisioning in general also requires a factory reset. Plan the tier at procurement, not at deployment.
It works, but it changes your operating model: every reset becomes a manual event requiring someone with the code. For low-volume or attended deployments that may be fine. For distributed consumer rental, the reset test result - unmanaged after reset - is usually disqualifying.
Because legacy documentation still recommends it and some older fleets were built on it. Google advises against NFC provisioning from Android 10 onward following the deprecation of NFC Beam. It is included here so operators reading older guides know to skip it.
Yes, for application distribution. Fully managed devices use managed Google Play to push and update apps without a per-device consumer account. It does not change the enrollment tier, but it is part of what makes an unattended fleet operable.
The share of devices whose last successful check-in is older than 24 hours. Enrollment state tells you what happened once; check-in recency tells you what is happening now - and a rising share usually indicates either connectivity problems or devices that have been reset out of management.